Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 14425

Article: 14425
Subject: Re: The development of a free FPGA synthesis tool
From: Jamie Lokier <spamfilter.jan1999@tantalophile.demon.co.uk>
Date: 29 Jan 1999 15:28:51 +0000
Links: << >>  << T >>  << A >>
Zoltan Kocsi writes:
> In a free-standing environment main() is just a function like any other.
> There's nothing special about it.

Be careful with this.  GCC treats main() specially even for a
free-standing target.  Your function main() does not compile to a
function called main(), but is instead renamed __main() by the compiler.

libgcc.a supplies a function called main() which calls your __main(),
after calling any static constructors it can find.  Often there aren't
any in C.  libgcc.a's main() also calls atexit() on some targets before
calling your __main().

What I'm saying here is that unless you make special arrangements, even
in a free-standing environment, a standalone GCC-compiled program will
do stuff before reaching what you thought was called main().

-- Jamie
Article: 14426
Subject: Re: C to Hardware translators [was: The development of a free FPGA synthesis tool]
From: Jonathan Bromley <jsebromley@brookes.ac.uk>
Date: Fri, 29 Jan 1999 15:29:45 +0000
Links: << >>  << T >>  << A >>
ems@riverside-machines.com.NOSPAM wrote:

> i hadn't realised that you could actually *do* anything with Handel-C.
> is there a practical mechanism for targetting xilinx? does it work,
> how do you do it, how much??

1) yes, Xilinx and nothing else AFAIK
2) yes
3) there's a good user manual, you just write the code and
   submit it to the compiler :-) and get ?XNF out of it;
   not sure about that last bit, but in any case you need the
   Xilinx P&R tools to do the physical stuff
4) about UKP 2K, but see the website, I think there is a demo version

Handel-C website: http://www.embedded-solutions.ltd.uk/

I have no commercial/financial interest in the company

Jonathan Bromley
Article: 14427
Subject: Re: C to Hardware translators [was: The development of a free FPGA synthesis tool]
From: Jamie Lokier <spamfilter.jan1999@tantalophile.demon.co.uk>
Date: 29 Jan 1999 15:32:57 +0000
Links: << >>  << T >>  << A >>
ems  writes:
[About Occam, quoting Jonathan Bromley]
>> | 1) it was technically competent
>> | 2) it was at least a decade ahead of its time
>> | 3) it originated in Britain :-)

> and, of course:

> 4) somebody (a) forgot to patent it, or (b) patented it, and then sold
> off the patent without noticing.

5) somebody forgot to (a) promote it properly, (b) develop the language
   in a useful direction.  Unless you count Handel-C of course:-)

> i hadn't realised that you could actually *do* anything with Handel-C.
> is there a practical mechanism for targetting xilinx? does it work,
> how do you do it, how much??

It's very Xilinx oriented -- almost all the demos run on Xilinx chips.

In some ways its a problem -- I'm doing exclusively Altera stuff, and
the compiler isn't entirely happy with it.  It works though.

-- Jamie
Article: 14428
Subject: Re: C to Hardware translators [was: The development of a free FPGA synthesis tool]
From: Jamie Lokier <spamfilter.jan1999@tantalophile.demon.co.uk>
Date: 29 Jan 1999 16:12:56 +0000
Links: << >>  << T >>  << A >>
Jonathan Bromley writes:
> Mainly, the way in which the present release of Handel-C is something
> of a Xilinx bigot, and uses all sorts of weird constructs/pragmas
> that are outside the language proper to control exploitation of
> device features.

I do exclusively Altera stuff, and I totally agree with you.  It's not
all that friendly to anyone/thing outside its own narrow vision.  Which
is currently much Xilinx + a little Altera and nothing else.

> Not a criticism of the language itself, of course.
> If I were being cynical I could suggest that it reflects 
> commercialisation of the language at rather too early a stage....

Commercialisation _per se_ is not a problem.  It's just selling what you
have.  But I do think that the way it's being done is unfortunately
narrowly focussed.  (Does this mean we agree?)

> My most serious concern about the *language* is the irrevocable 
> one-to-one relationship between assignments and clock cycles.  I know
> why this was done, and I know it is often convenient, but there are 
> occasions when a "non-clocking assignment" would make for much clearer
> expression of certain problems.  VHDL deals with this issue by
> distinguishing between signals and variables.

The timing thing as really handy.  Surprisingly so.  At first I didn't
like it because of its apparent inflexibility.  But since it was pointed
out as a _feature_, I've really found ways to use it.  A lot of stuff,
including I/O interfacing and internal dataflow stuff is so much more
_succinct_ because of the implied timing relationships.

The 1-1 relationship is not irrevocable.  I know there are ways to
remove it and remain compatible.  Retiming optimisations can be very
effective, more so with relaxed timing constraints on "untimed"
variables and channels.  Imagine treating a channel as a FIFO where the
compiler determines the optimal low & high water marks (often the same)
and optimal forwarding paths.  Imaging analysing data flow through timed
and/or untimed variables to get the real flow relationship, and
optimising that.  That's _way_ better than you'll ever get with VHDL.

I have heard there is some research on the clever retiming stuff, but
I'm not sure I believe it.

> There is also a practical problem about the semantics of channels
> in a clocked (as opposed to asynchronous) environment.  One
> Handel-C guru (names withheld to protect the guilty :-) ) has told me
> that he tends to use shared variables in preference to channels
> to avoid the extra clock cycle overheads.  If he had a grave, I
> suspect Tony Hoare would be turning in it...

I suspect I know who you mean :-) The irony is that _assigning_ shared
variables introduces the same clock cycle overheads.  (Communication and
assignment as very similar in Handel-C).  And it totally destroys any
semblance of modularity.

To really remove those cycle overheads, you have to expose and pass
_internal expressions_ from one module to another.  That is very messy
indeed.  And it doesn't always work do to mutual recursion problems.
Well, unless you treat Handel-C as a way to write a netlist :-)

You can think of me as the "Handel-C channel guru".  I know how to make
channels do lots of things, and the deep magic of `prialt' which nobody
else uses.  They are good for modularity, and something easily missed:
they enforce scalability of your synthesised program.

See it this way: Handel-C forces you to write pipelined data flows.  You
connect lots of pipelines together and the overall logic depth stays the
same.  In theory (<ahem> ;-), no slowdown.

> As a secondary point, I could raise the limitations of Handel-C when
> addressing asynchronous design (for which Occam offers great potential 
> benefits, as you are aware I'm sure!) and/or multiple clock domains
> on the same device.  And I haven't yet understood how it deals with
> design/library maintenance issues in the way that VHDL does, although
> this may be because I haven't got to grips with the details yet.

Let's see :-)

My current program runs on an Altera Flex10K50GC403-3, has two clock
domains and a variety of fascinating asynchronous signals with awkward
timing constraints.  The two clocks run at 33MHz and 16.5MHz, locked
together.  It does various kinds of packet multiplexing, rewriting and
prioritising, has lots of internal pipelines, loosly coupled (random
bubbles flowing through), talks to PCI via an AMCC chip and to two
100Mbit DS-Link interfaces.  The AMCC and DS-Link chips are connected
directly to the FPGA, and the I/O interfacing is written in Handel-C.

My previous program had _three_ clock domains, at 33MHz, 16.5MHz and
~10MHz (variable, PLLed to Ethernet data).  It used asynchronous FIFOs
written in Handel-C (well sort of, not the sort of Handel-C they want me
to scare newbies with :-).  The Handel-C code interfaced directly with
an Ethernet 10Mbit physical layer chip (Handel-C implemented the MAC
layer -- framing, retransmissions, CRC etc.), and the AMCC chip for a
PCI interface.

{ Consultancy charges on request ;-) }

The library issues do suck, but you can work around the problems by
being organised with namespaces, good use of header files etc.  CPP is a
saviour here.  It is said that the libraries issues will be addressed
for the next major release.

>> I find Handel-C's limitations very frustrating, but with experience
>> I've found ways of doing things that turn out nicely in the end.

> I defer to your experience.  I haven't yet used Handel-C on a "live"
> project.  Certainly I've been very impressed with some of the stuff
> that your hardware-compilation group has done with it.

-- Jamie
Article: 14429
Subject: RAM/ROM compilers
From: Romanovsky Sergey <thesys@carrier.kiev.ua>
Date: Fri, 29 Jan 1999 18:32:38 +0200
Links: << >>  << T >>  << A >>
Does anybody know about memory compilers?
Any info will be high appreciated.
-- 
Romanovsky Sergey    phone : 38044 241 7115
Design Manager       fax   : 38044 241 7031
                     email : thesys@carrier.kiev.ua

WWW entry : http://www.ln.com.ua/~thesys
Address   : JV "THESYS-Mikropribor"
            Polytekhnicheskaya Str.33
            252056 Kiev,Ukraine
Article: 14430
Subject: Re: Hazard
From: "Wade D. Peterson" <peter299@maroon.tc.umn.edu>
Date: Fri, 29 Jan 1999 11:17:05 -0600
Links: << >>  << T >>  << A >>

Duck Foot wrote in message <36B16A5A.5110E9F2@hotmail.com>...
>    Textbooks tell how to get rid of static hazards inherent in a sum
of
>products network. They say the hazard comes from transitions between
>neighboring product terms, and can be eliminated by adding redundant
>implicants.
>
>    Do we also call the transitions between two apart product terms,
>e.g. diagonally positioned ones, hazard? How can I eliminate glitches
>born of this kind of network? - In this case circling 0's to
eliminate
>0-hazard also results in diagonal configuration.
>


Are you using synchronous logic?  If so, then the hazard conditions
probably
don't matter anyway.  If you're using the output of your circuit to
clock
a flip-flop or something, then the hazards are important.  In these
cases
the redundant implicants work really great.

If you're using the redundant implicants technique, then you have to
check that the inputs will change as expected.  All that they're
saying is
that certain transitions on the input will generate momentary glitches
on the output of the circuit.

If I understand what you're saying about 'diagonal' terms, then you
have to
check to see if your inputs will every change under the 'diagonal'
conditions.
If so, then you have to add a product term to eliminate them.

Wade Peterson
Silicore Corporation
http://www.silicore.net/






Article: 14431
Subject: Re: The development of a free FPGA synthesis tool
From: "BuckSavage" <wbuckley@transdyn.com>
Date: Fri, 29 Jan 1999 09:20:17 -0800
Links: << >>  << T >>  << A >>

Hrvoje Niksic wrote in message <87socun7jr.fsf@pc-hrvoje.srce.hr>...
>"BuckSavage" <wbuckley@transdyn.com> writes:
>
>> I do not have a problem with the use of the given construction, just
>> a problem with programmers who think that such a construction is an
>> absolute must.  The fact that I can compile and successfully execute
>> a program which uses the construction "void main()" is sufficient
>> reason for me to do so.
>
>If you compile and successfully execute a program that passes a
>different number of arguments to qsort(), will it be the sufficient
>reason to do so?
>
>Just like qsort(), int main() is an interface.  By not abiding to the
>rules, you are opening a possibility of your program breaking.

If the consequence is that data is processed in a manner to which
I am agreeable, then, by all means, it will be sufficient reason to use
qsort() in a non-standard way.

Gaby, you are correct.

Also, the int main() motif was in K&R a default condition.

William R. Buckley


Article: 14432
Subject: Re: ALTERA: Configuration problem of 10K50VRC240-3 + EPC1PC8
From: Brian Boorman <XZY.bboorman@harris.com>
Date: Fri, 29 Jan 1999 12:26:19 -0500
Links: << >>  << T >>  << A >>
Emmanuel JOLLY wrote:
> 
<snip>
> 
> Sometimes, my design doesn't download from the EPC1 to the ALTERA. If
> I look at the signals with an oscilloscope I can see that CONF_DONE is
> low and nSTATUS is low also. According to AN59 nSTATUS should be high
> to enable the EPC1. As nSTATUS is low, the download process cannot
> take place.
> 
> This problem is correlated with the temperature of the device. When
> the environnement is warm, the download process takes place but when I
> cool down the chip (with a cooling spray) it doesn't download.
> 
> Any ideas??

I have experienced the same (relatively) problem. Our issue was that
device operation was not reliable below -20 C. Granted, we were using
commerical grade parts and our application requires Industrial temp. I
believe that cooling spray (at least the type we use) cools down to ~
-45 C, so that is probably what you are seeing.

Unfortunately we were forced into our situation because Altera out and
out lied to us about offering the EPF8282 in a 3.3V Industrial version.
Two years later in the middle of our final prototype run I had to do 3
masked-gate array conversions (3 designs in one product) just so that we
could meet the Indutrial temp requirements of our (military) customer.

That incident is also why we don't do any new designs in Altera devices.


-- 
Brian C. Boorman
Harris RF Communications
Rochester, NY 14610
XYZ.bboorman@harris.com
<Remove the XYZ. for valid address>
Article: 14433
Subject: Re: The development of a free FPGA synthesis tool
From: Hrvoje Niksic <hniksic@srce.hr>
Date: 29 Jan 1999 19:09:32 +0100
Links: << >>  << T >>  << A >>
"BuckSavage" <wbuckley@transdyn.com> writes:

> >Just like qsort(), int main() is an interface.  By not abiding to the
> >rules, you are opening a possibility of your program breaking.
> 
> If the consequence is that data is processed in a manner to which I
> am agreeable, then, by all means, it will be sufficient reason to
> use qsort() in a non-standard way.

Ah, an interesting argument.  So, have you actually tried it, or is
that reserved for void main()?
Article: 14434
Subject: Re: C to Hardware translators [was: The development of a free FPGA synthesis tool]
From: Jonathan Bromley <jsebromley@brookes.ac.uk>
Date: Fri, 29 Jan 1999 18:13:24 +0000
Links: << >>  << T >>  << A >>
Jamie Lokier wrote:
< detailed and expert response to many of my concerns about Handel-C > 

<me speaking>
> > My most serious concern about the *language* is the irrevocable
> > one-to-one relationship between assignments and clock cycles.  I know
> > why this was done, and I know it is often convenient, but there are
> > occasions when a "non-clocking assignment" would make for much clearer
> > expression of certain problems.  VHDL deals with this issue by
> > distinguishing between signals and variables.
> 
> The timing thing as really handy.  Surprisingly so.  At first I didn't
> like it because of its apparent inflexibility.  But since it was pointed
> out as a _feature_, I've really found ways to use it.  A lot of stuff,
> including I/O interfacing and internal dataflow stuff is so much more
> _succinct_ because of the implied timing relationships.

I think you are reading more into my comment than I put there :-)
All I meant was that it is sometimes handy to be able to express 
certain types of logic as a sequence of intermediate calculations
even though the result will NOT be pipelined.  Particularly true of 
certain kinds of bit-bashing operations.  Without a zero-time assignment
statement and intermediate non-physical variables, this is impossible 
and you must either pipeline or else dream up a combinatorial expression
of the problem.  I know that this sort of thing is open to abuse and
can give the synthesis tool a serious headache, but I still think it
would be a nice extension for those who needed it.

I am 100% in favour of Handel-C's basic timing model which, as you
say, has all sorts of attractive spin-offs.

>You can think of me as the "Handel-C channel guru".

OK, I'll take you up on that.  Can you please show me some kind of timing
diagram which would allow me to check that I am right in my beliefs about
what happens when you communicate over a Handel-C channel?  For the
three different scenarios:  sender gets there first, target gets there
first, both arrive in the same clock cycle.  This is something that 
is rather skated-over in the published documentation.

>  I know how to make
>channels do lots of things, and the deep magic of `prialt' which nobody
>else uses.  They are good for modularity, and something easily missed:
>they enforce scalability of your synthesised program.

What's so deep or so magic about prialt?  It just sounds sensible to me.
I 100% concur with your comment about modularity and scalability.

Regards
Jonathan Bromley
Article: 14435
Subject: Re: Hazard
From: phil_jackson@my-dejanews.com
Date: Fri, 29 Jan 1999 18:23:50 GMT
Links: << >>  << T >>  << A >>
In article <36B16A5A.5110E9F2@hotmail.com>,
  Duck Foot <duckfoot11@hotmail.com> wrote:
>     Textbooks tell how to get rid of static hazards inherent in a sum of
> products network. They say the hazard comes from transitions between
> neighboring product terms, and can be eliminated by adding redundant
> implicants.
>     Do we also call the transitions between two apart product terms,
> e.g. diagonally positioned ones, hazard? How can I eliminate glitches
> born of this kind of network? - In this case circling 0's to eliminate
> 0-hazard also results in diagonal configuration.
>
>
Register it, i.e. use synchronous design methods, if you can.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    
Article: 14436
Subject: Re: Hazard
From: Ray Andraka <randraka@ids.net>
Date: Fri, 29 Jan 1999 14:27:41 -0500
Links: << >>  << T >>  << A >>
If you can use synchronous design, then this won't matter.

For the record, if you have two terms that are not adjacent, at least two
inputs must change state to get from the first state to the end state.
Depending on the order those states change, you will have a different path
through your state map.  Unless all the states in any traverse path are the
same, AND each possible state transition pair is covered by a common
minterm, you can have a hazard.

For an asynch state machine, you want all state transitions to be to
adjacent states so that you can avoid this type of hazard.  It can make it
challenging to assign the states.

Duck Foot wrote:

>     Textbooks tell how to get rid of static hazards inherent in a sum of
> products network. They say the hazard comes from transitions between
> neighboring product terms, and can be eliminated by adding redundant
> implicants.
>     Do we also call the transitions between two apart product terms,
> e.g. diagonally positioned ones, hazard? How can I eliminate glitches
> born of this kind of network? - In this case circling 0's to eliminate
> 0-hazard also results in diagonal configuration.



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 14437
Subject: Re: The development of a free FPGA synthesis tool
From: "BuckSavage" <wbuckley@transdyn.com>
Date: Fri, 29 Jan 1999 13:30:41 -0800
Links: << >>  << T >>  << A >>

Hrvoje Niksic wrote in message <87socuj6hv.fsf@pc-hrvoje.srce.hr>...
>"BuckSavage" <wbuckley@transdyn.com> writes:
>
>> >Just like qsort(), int main() is an interface.  By not abiding to the
>> >rules, you are opening a possibility of your program breaking.
>>
>> If the consequence is that data is processed in a manner to which I
>> am agreeable, then, by all means, it will be sufficient reason to
>> use qsort() in a non-standard way.
>
>Ah, an interesting argument.  So, have you actually tried it, or is
>that reserved for void main()?

I have not actually tried a non-standard application of qsort() but, my
argument is speculative.  That is, if I had a reason to do so, and if
I knew that the result was desireable, I would use the routine in some
non-standard (unexpected) way.

My view is that a programmer should have the ultimate choice in the
use of software, instead of having to "toe-the-line" in some fashion
expected by some other programmer.  Software is a tool, and if it
can be used to solve some problem, then by all means use it so.

It is my observation that those who began this thread of discussion
are far too caught up in the formalities of software practice, and that
while such formalities can be valid, they are not absolute.  It is
agility that we should strive for, above all else.

William R. Buckley


Article: 14438
Subject: Benchmarks: Schematic vs Synthesis (Exemplar vs Synplicity)
From: husby@fnal.gov (Don Husby)
Date: Fri, 29 Jan 1999 22:05:42 GMT
Links: << >>  << T >>  << A >>

I ported a small schematic-based design to VHDL in order to benchmark
two synthesizers.  Here is a summary of the results:

                  Area (PFU)     Speed (MHz)
Schematic          21            95.2
Exemplar           30            75.6
Synplicity(1)      33            57.4
Synplicity(2)      32            67.2

The circuit is a serial link transmitter macro that transmits 33-bit
data words.  It has an 8-word input FIFO, 4B/5B encoder, shifter,
and frame synchronizer.

The circuit was targeted for a Lucent Orca 2T04A-3.  This is their
"medium" speed grade.  It was designed to run at 50MHz (12.5 MHz
serial bit rate).

The VHDL code was simulated using Aldec Active-VHDL before sythesis.
The schematic was entered using Workview Office with my custom "xfunc"
extensions.

You can get Schematic (.pdf), VHDL code, and disassembled (and annotated)
chip files (*.eqn) at
  http://www-ese.fnal.gov/eseproj/trigger/synth_ben.zip

Some notes:
(1)(2) One of the strong points of HDL coding is the ability to use
higher-level constructs, and leave the optimization to the software.
This was tested by implementing the FIFO word counter in two different
ways.  This is a 3-bit up/down counter that saturates at Count==7.
A 4th bit is used to indicate an overflow- one count past saturation. 

Expressed as "high level" concepts this is:
  if (Write = '1') then                  
    if (Wc(2 downto 0) < 7) then         
      Wc(2 downto 0) <= Wc(2 downto 0) + 1;
    end if;
  else Wc(2 downto 0) <= Wc(2 downto 0) - 1;
  end if;
  Wc(3) <= Write and Wc(2) and Wc(1) and Wc(0);

Expressed as logic equations this is:
Wc(0) <= (Write and Wc(2) and Wc(1)) or not Wc(0);
Wc(1) <= (Write and Wc(2) and Wc(1)) 
          or (not Write xor Wc(1) xor Wc(0));
Wc(2) <= (Write and Wc(1) and Wc(0)) 
          or (Wc(2) and(Write or Wc(1) or Wc(0)));
Wc(3) <= Write and Wc(2) and Wc(1) and Wc(0);

This should fit in a single Orca PFU and run very fast.
Both Synplicity and Exemplar attempted to implement the high-level
version using Orca carry logic, and this turned out to be the speed
bottleneck for the circuit.  Exemplar had a switch to turn off this
"optimization" and produced a pretty good implementation for the circuit.

Synplicity had no such switch.  In addition to using the carry logic,
it put the flip-flops in a separate PFU, increasing the delay as well
as size of the circuit.  Using the re-coded equations resulted in the
faster time for Synplicity(2).

(3) Synplicity extracted some clock-enables correctly, and extracted
some synchronous set/reset signals, but did this poorly, resulting
in some related functions being spread across multiple PFU when they
should have been grouped together.  It did not attempt to use the
Orca FE-Mux feature, which would have made a significant improvement.

(4) Exemplar used the FE-mux feature well, but in some cases it
substituted it for clock-enable, resulting in some extra routing
resources being used, but no measurable size or performance penalty.
It also used CE correctly most of the time, however it botched it
where several signals should have used the same CE, but the signals
were aliased, causing related functions to not be mapped to the
same PFU.

(5) Both synthesizers inferred memory, however, Synplicity
put useless tristate buffers between the memory outputs and
flip-flops resulting in 5 extra PFUs and extra delay.  This
was the timing bottleneck for the faster synplicity version.

(6) Exemplar preserved many signal names.  On others it added
some extra postfixes like "_int" or "_dup".  Synplicity also
preservered some signal names, but added "Z0Z" to most signal
names.  This made many signal names difficult to recognize.

See the disassembled chip files for examples.


Article: 14439
Subject: Help for the scientifically-challenged
From: Dave Fuhriman <dpf6@email.byu.edu>
Date: Fri, 29 Jan 1999 16:08:21 -0600
Links: << >>  << T >>  << A >>
Hi, I've been researching reconfigurable computing for an article, and I
have found some good explanations of how it works. What I lack is a
solid analogy to give to other people to help them understand how it
works and how it's an improvement over what we had before. Something
like general purpose computing is like a Yugo, and reconfigurable
computing like a 'Vette -- something that explains why it's better. Has
anyone heard such an analogy that explains this concept to people like
me who use computers but don't know how to make them? Any help would be
appreciated. Thanks!

Article: 14440
Subject: Re: Ratings for Synplicity Synplify
From: Rick <rick@algor.co.uk>
Date: Fri, 29 Jan 1999 22:49:01 +0000
Links: << >>  << T >>  << A >>
An update on the  timing front: The results below were a fake comparison
since I'd  set the
PAR_NOGENRAMBLOCK for Synplify while tryiing to find another problem &
forgot to turn it backlon
for the  trial run.


> o Final results  +/-: After running the respective EDIF files through
> the Xilinx tools with no    timing constraints Synplify had these
> differences:
>      Avg Conn delay : +4%.
>       Max pin delay: -25%.
>       Avg delay on 10 worst: -10%.

With this flag unset Synplify came out 1-2% ahead.

I got the same 30-50% differences between the predicted & actual timngs  on
a constrained P&R run.
Looking at it more closely  it turns out that due the very, very large
fanouts in my trial design  Routing delays were dominating to a huge extent
and the Synplify route timings didn't allow for designs as stupid as this!
Interestingly those nice Synplicity people have put the timing stuff in
text files so that I could, in theory, modify the routing delay multiplier
function(s).

With regards to the Verilog & VHDL comments: Sure you CAN get VHDL with
Spectrum but you have to pay a lot extra, I think another  3K UK Pounds.
Not being able to use both in the same design with Synplify is not a
problem since I can compile my Verilog  & VHDL separately and get NGDBUILD
to merge them.



Article: 14441
Subject: Re: Ratings for Synplicity Synplify
From: Rick <rick@algor.co.uk>
Date: Fri, 29 Jan 1999 22:49:58 +0000
Links: << >>  << T >>  << A >>
An update on the  timing front: The results below were a fake comparison
since I'd  set the
PAR_NOGENRAMBLOCK for Synplify while tryiing to find another problem &
forgot to turn it backlon
for the  trial run.


> o Final results  +/-: After running the respective EDIF files through
> the Xilinx tools with no    timing constraints Synplify had these
> differences:
>      Avg Conn delay : +4%.
>       Max pin delay: -25%.
>       Avg delay on 10 worst: -10%.

With this flag unset Synplify came out 1-2% ahead.

I got the same 30-50% differences between the predicted & actual timngs  on
a constrained P&R run.
Looking at it more closely  it turns out that due the very, very large
fanouts in my trial design  Routing delays were dominating to a huge extent
and the Synplify route timings didn't allow for designs as stupid as this!
Interestingly those nice Synplicity people have put the timing stuff in
text files so that I could, in theory, modify the routing delay multiplier
function(s).

With regards to the Verilog & VHDL comments: Sure you CAN get VHDL with
Spectrum but you have to pay a lot extra, I think another  3K UK Pounds.
Not being able to use both in the same design with Synplify is not a
problem since I can compile my Verilog  & VHDL separately and get NGDBUILD
to merge them.



Article: 14442
Subject: Re: Ratings for Synplicity Synplify
From: Rick <rick@algor.co.uk>
Date: Fri, 29 Jan 1999 22:50:22 +0000
Links: << >>  << T >>  << A >>
An update on the  timing front: The results below were a fake comparison
since I'd  set the
PAR_NOGENRAMBLOCK for Synplify while tryiing to find another problem &
forgot to turn it backlon
for the  trial run.


> o Final results  +/-: After running the respective EDIF files through
> the Xilinx tools with no    timing constraints Synplify had these
> differences:
>      Avg Conn delay : +4%.
>       Max pin delay: -25%.
>       Avg delay on 10 worst: -10%.

With this flag unset Synplify came out 1-2% ahead.

I got the same 30-50% differences between the predicted & actual timngs  on
a constrained P&R run.
Looking at it more closely  it turns out that due the very, very large
fanouts in my trial design  Routing delays were dominating to a huge extent
and the Synplify route timings didn't allow for designs as stupid as this!
Interestingly those nice Synplicity people have put the timing stuff in
text files so that I could, in theory, modify the routing delay multiplier
function(s).

With regards to the Verilog & VHDL comments: Sure you CAN get VHDL with
Spectrum but you have to pay a lot extra, I think another  3K UK Pounds.
Not being able to use both in the same design with Synplify is not a
problem since I can compile my Verilog  & VHDL separately and get NGDBUILD
to merge them.



Article: 14443
Subject: Re: Benchmarks: Schematic vs Synthesis (Exemplar vs Synplicity)
From: thor@sm.luth.se (Jonas Thor)
Date: Fri, 29 Jan 1999 22:51:54 GMT
Links: << >>  << T >>  << A >>
On Fri, 29 Jan 1999 22:05:42 GMT, husby@fnal.gov (Don Husby) wrote:

<snip>

>                                In addition to using the carry logic,
>it put the flip-flops in a separate PFU, increasing the delay as well
>as size of the circuit.  Using the re-coded equations resulted in the
>faster time for Synplicity(2).

Does really the synthesizer provide any information about where to
place the flip-flops? From my experience the synthesizer only produces
a netlist with primitives or macros. Then it is up to the placer to
place the primitives/macros. 

I might be wrong... it has happened before :)

/ Jonas Thor

Article: 14444
Subject: Re: Ratings for Synplicity Synplify
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Fri, 29 Jan 1999 22:52:40 +0000
Links: << >>  << T >>  << A >>
An update on the  timing front: The results below were a fake comparison
since I'd  set the
PAR_NOGENRAMBLOCK for Synplify while tryiing to find another problem &
forgot to turn it backlon
for the  trial run.


> o Final results  +/-: After running the respective EDIF files through
> the Xilinx tools with no    timing constraints Synplify had these
> differences:
>      Avg Conn delay : +4%.
>       Max pin delay: -25%.
>       Avg delay on 10 worst: -10%.

With this flag unset Synplify came out 1-2% ahead.

I got the same 30-50% differences between the predicted & actual timngs 
on
a constrained P&R run.
Looking at it more closely  it turns out that due the very, very large
fanouts in my trial design  Routing delays were dominating to a huge
extent
and the Synplify route timings didn't allow for designs as stupid as
this!
Interestingly those nice Synplicity people have put the timing stuff in
text files so that I could, in theory, modify the routing delay
multiplier
function(s).

With regards to the Verilog & VHDL comments: Sure you CAN get VHDL with
Spectrum but you have to pay a lot extra, I think another  3K UK Pounds.
Not being able to use both in the same design with Synplify is not a
problem since I can compile my Verilog  & VHDL separately and get
NGDBUILD
to merge them.
Article: 14445
Subject: Re: Off topic....
From: "Austin Franklin" <aus3tin@darkroom.com>
Date: 30 Jan 1999 00:00:24 GMT
Links: << >>  << T >>  << A >>
> I was going to say humility and compliments generally work wonders
> in receiving off-beat replies, but it seems you are responding to your
> post more than anyone else!

Thanks for the tip...

I was adding new information that I discovered in my researching the
problem.  I thought that was kind of obvious ;-)

Anyway, thanks to those who gave 'helpful' answers, I believe I've
identified what the SIMMs really are.  They still don't work in my system,
and I don't know why, but at least I do know what they are...

Austin

Article: 14446
Subject: Re: Help for the scientifically-challenged
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 29 Jan 1999 16:37:27 -0800
Links: << >>  << T >>  << A >>
Dave Fuhriman wrote:

> Hi, I've been researching reconfigurable computing for an
> article, and I
> have found some good explanations of how it works. What I
> lack is a
> solid analogy to give to other people to help them
> understand how it
> works and how it's an improvement over what we had before.
> Something
> like general purpose computing is like a Yugo, and
> reconfigurable
> computing like a 'Vette -- something that explains why
> it's better. Has
> anyone heard such an analogy that explains this concept to
> people like
> me who use computers but don't know how to make them? Any
> help would be
> appreciated. Thanks!

Dave, you started the car analogy...It's like opening the
garage and saying:
It's sunny and warm today, and I'm going to see my
girlfriend: Be a convertible!
Next day: I have to take stuff to the dump: Be a station
wagon!
Next day, when stuck in the muck: Have 4-wheel drive!
Next day trying to park: Be a foot shorter!
Late at night: Have reclining seats. The rest is only
limited by your imagination...

Peter Alfke, Xilinx Applications

  

Article: 14447
Subject: Re: FPGA/core PCI interface system
From: John Schewel <jas@vcc.com>
Date: Fri, 29 Jan 1999 16:55:38 -0800
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------74D4A789F211F38FE5728856
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

hello rick....

the restricted license comes with the price of the HOT2 Development
System  $695

the full LogiCORE PCI32 license from Xilinx is $8895 w/ Design Kit

-- 

Best Regards,
John Schewel, VP Marketing & Sales
Virtual Computer Corp.
http://www.vcc.com
--------------74D4A789F211F38FE5728856
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for John Schewel
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             John Schewel
n:              Schewel;John
org:            Virtual Computer Corporation
adr:            6925 Canby Ave. #103;;;Reseda;CA;91335;USA
email;internet: jas@vcc.com
title:          VP Marketing & Sales
tel;work:       +1 (818) 342-8294
tel;fax:        +1 (818) 342-0240
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard


--------------74D4A789F211F38FE5728856--

Article: 14448
Subject: Re: Hold Time Violation
From: kebm@flash.net
Date: Sat, 30 Jan 1999 01:30:29 GMT
Links: << >>  << T >>  << A >>
Duckfoot,

No shortcuts come to mind but what I usually do in a case like this is start
with the first one.  It is often due to simulation vectors that are
carelessly placed, such as a signal changing at the same time as a clock. 
Also, the first several dozen (or several hundred) can all be cause by the
same event -- reset. Therefore, sometimes jogging your asynchronous reset
signal a few nanoseconds forward or backward in time can eliminate many of
these errors and make it a more manageable list to find any that matter. Good
Luck --- Keb'm

In article <36B16663.92B16DB3@hotmail.com>,
  Duck Foot <duckfoot11@hotmail.com> wrote:
> Hi everyone,
>     I'm confronting many hold time violations and glitches while
> post-synthesis simulation. Since I built the logic with quite high level
>
> description and the logic is very massive, it looks impossible to debug
> them one by one.
>     Is there any canonical strategy applied to these kind of problems,
> or can I ask you for some refernces?
>
>

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    
Article: 14449
Subject: Re: Worst service in India by Xilinx
From: kebm@flash.net
Date: Sat, 30 Jan 1999 02:05:06 GMT
Links: << >>  << T >>  << A >>
While I agree that it does sound like satish is whining or trying to lay
blame for why he hasn't gotten started on his project yet, it really is the
responsibility of the local reps to keep the customer happy.  If they can't
help this guy out before he gets frustrated enough to post a message like
this, perhaps one of their competitors can...

In article <78im3s$q0c$1@noao.tuc.noao.edu>,
  "Andy Peters" <apeters@noao.edu.NOSPAM> wrote:
> satish_me@hotmail.com wrote in message <78bt35$eql$1@nnrp1.dejanews.com>...
> >Hello  I am a customer from India to Xilinx. I purchased the Xilinx Express
> >foundation series long almost 1 month ago. Till now either for installation
> >or to tell how to start was not guided by any of the Indian representative.
> >Hence it shows the poor service of the Xilinx company in INDIA. Hence I
> >appeal to people of India not to go for purchsing the Xilinx products,
> which
> >suffer from lack of service in Indian region.
>
> Instead of blaming Xilinx and their reps for lack of support, have you tried
> READING THE MANUALS THAT COME WITH THE SOFTWARE?
>
> ------------------------------------------
> Andy Peters
> Sr. Electrical Engineer
> National Optical Astronomy Observatories
> 950 N Cherry Ave
> Tucson, AZ 85719
> apeters@noao.edu
>
> "In the beginning, there was darkness.  And it was without form, and void.
> And there was also me!"
> -- Bomb #20, John Carpenter's "Dark Star"
>
>

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    


Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search