Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
Peter Alfke wrote: > Bob Perlman wrote: > > > Hi - > > <snip> > > > > > 22V10s and most other > > PLDs are based on AND/OR planes, which are bound to be glitchy if the > > designer hasn't (a) added product terms to mask the effects of > > transition or (b) synchronized asynchronous inputs. > > > > The Xilinx FPGA implementation is completely different. Each 4-input > > LUT consists of 16 SRAM cells (latches, actually) followed by a 16:1 > > mux built with transmission gates. The construction is such that, if > > you switch a single LUT input, the mux switches between the outputs of > > > > two latches, and no others. <snip> If the > > two latches we're transitioning between have the same state, you get a > > > > glitchless transition. There's no RAM decode glitch because there's > > no decoder. > > Bob is right, but the reason that there is no glitch, even when the > multiplexer acts like a break-before-make switch ( it undoubtably does, > either in one direction or the other ) is more subtle., There is no > glitch even with break-before-make because the stray capacitance between > these pass transistors holds the old value for the fractional nanosecond > in question. > > Having answered this question many times... yes, this has come up several times - and note that xilinx is not alone with this design for glitchless switching - quicklogic does the same sort of thing. rkArticle: 13826
rk wrote in message <36880CFA.B829591@NOSPAMerols.com>... > >you should, it's correct and exactly what i said. I'm glad you agree with me. Jeff StoutArticle: 13827
Daniel Sears wrote: > > Dan, > > in principle, there isn't a big difference between finding nice > numbers near the original cosine values and truncating them at > a certain precision. Both of these are approximations. > > When I looked at this stuff, the shift and add approaches were > for minimizing hardware. If the hardware is given, and you > are minimizing software instructions, I don't think it is profitable. > > Multiplication free DCTs are a subset of multiplication free filters > which are well published in the various research magazines. > > You might look at: > > SPIE Proceedings Vol. 2419 > Digital Video Compression: Algorithms and Technologies 1995 > Multiplication free scaled 8 x 8 DCT algorithm with 530 additions there is discussion about developing multiplier-free DCt in the book Image and Video Compression Standards: Algorithms and Architectures (see www.best.com/~bhaskara). The problem with mult. free DCTs is that they don't pass the IEEE DCT accuracy test (which may or may not be okay depending on your application). As for smallest DCT - if you mean code size, it depends on processor for which you implement the DCT, if you mean fastest DCT that too depends on processor. most of mult. free DCT implementations as was done for HP's MPEG playback on PARISC CPUs, was motivated by the fact that such CPUs did not have a multiplier unit in the integer ALU. On the other hand, if you had a multiply-accumulate architecture based CPU (Pentium MMX has such a thing), then a Chen DCT instead of Feig-Winograd DCT may be a better choice since it needs only 416 multiply accumulate operations. - Bhaskaran Vasudev Epson Palo Alto LaboratoryArticle: 13828
The only Flex8000 parts that were available in the 192 PGA was (and is) the EPF8820 and the EPF8636. The 8820 has some 16000 gates and 820 Flipflops The 8636 has 12000 gates and 636 flipflops *** Posted from RemarQ - http://www.remarq.com - Discussions Start Here (tm) ***Article: 13829
bhaskaran vasudev <bhaskara@best.com> writes: > The problem with mult. free DCTs is that they don't pass the IEEE > DCT accuracy test (which may or may not be okay depending on your > application). Huh? Take an IEEE-1180 compliant fixed-point DCT, expand its multiplies by constants to shifts and adds, and voila. Perhaps we have different ideas of what is meant by a "mult-free DCT"? regards, tom laneArticle: 13830
George wrote: > Hi, I am now trying to combine Mentor VHDL synthesize tool with Xilinx FPGA > Foundation software. > I using the Mentor Leonardo software to generate the EDIF file, which is > says to be netlist > file synthesized, but how can I import them into Xilinx software? Have > anybody do this before? > Thank you very much for your help! > Also, can somebody give me a more detailed description about what is EDIF > files? > Thanks a lot! Hi, you need the Xilinx Alliance tool, called M1.5 too. (this is not Foundation Express). You will just do a "new project" and define your edif file as the input file and precise the target. Basically, an edif file define the inputs and outputs of basic components (or, and, flip-flop...). Depending of the options used with Leonardo, basic components can be link to CLBs or not. Michel. Michel Le Mer Gerpi sa 3, rue du Bosphore Alma city 35000 Rennes France.Article: 13831
In article <768o2i$egq@sjx-ixn9.ix.netcom.com>, "Daniel Sears" <dbsears@ix.netcom.com> wrote: > You might look at: > > SPIE Proceedings Vol. 2419 > Digital Video Compression: Algorithms and Technologies 1995 > Multiplication free scaled 8 x 8 DCT algorithm with 530 additions > I don't see how this could be a 2-D DCT w/ 530 adds. An 8-point DCT requires 7*8=56 adds, which makes 56*8=448 adds for a row or column transform. So they are using another 82 adds to perform the "multiplies". For something like the single chip MPEG encoder ASICs, are they using multiply-free structures, or something w/ multiplies and adds? I would assume that throughput requirements would necessitate fairly parallel designs, but that the multipliers may be quite large. Dan -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your OwnArticle: 13832
Please visit and comment on my Electronics and Electrical Engineering pages located at: http://www.users.globalnet.co.uk/~metad/eee.htm Containing: Introduction to EEE Resources (over 100 web links) Employment Statistics and newspaper excerpts Engineering Poems, Quotations and Jokes EEE at Glasgow University In addition my homepage (http://www.users.globalnet.co.uk/~metad/) contains: A section about me My CV A James Bond Section A guestbook Humour 500+ cool links in the "new look" bookpage Cool background MIDI and graphics Literary quotations Photo Album Student Resources Awards Page Poems... Basically, something for everyone! PLEASE VISIT VIA MY MAIN HOMEPAGE ADDRESS! Please send you comments via the guestbook or by Email (containing your full name and Email and webpage addresses) and visit via http://www.users.globalnet.co.uk/~metad/. Thanks Scott Johnston metad@globalnet.co.ukArticle: 13833
I've completed two different Async FIFO designs in HDL. One in VHDL for an Actel device, and one in Verilog for an ASIC. Never trivial, but It can be done. rk wrote in message <3687A3AF.26248781@NOSPAMerols.com>... >Edward Moore wrote: > >> then Ray Andraka <randraka@ids.net> wrote: >> >> >It is very difficult to get this kind of performance in a synthesized design >> >(especially with the async clocks). In cases like this it is much faster and >> >easier to just to do it in schematic the way you know it needs to be implemented >> >and be done with it. >> NOTE: Ray did not say that it could not be done in an HDL, only that it is much faster and easier to do it in a schematic IHOP (In His Honest Opinion). I see this simply as opinion and a not a statement of fact that it can't be done in HDL. Every designer should work in the the design flow he/she is most comfortable with and which allows them to get the design completed on time and functional. >> IMO one of the reasons why the schematic entry vs. HDL debate keeps >> cropping up is statements like the above, which are originated by people >> who either: >> >> a) might have a vested interest in persuading people that they won't be >> able to use a HDL for their designs >> >> b) havn't tried using a HDL >> >> c) have tried a HDL, but didn't do it properly >> >> d) work for FPGA manufacurers and should perhaps know better. >> Not sure I understand d)??? I work for an FPGA manufacturer (Actel). It appears to be some sort of jab, but it didn't catch any flesh. >> At it's heart, the 'cant do it in a HDL' arguement seems to stem from a >> confusion between inferred and instantiated HDL. No one is claiming that >> a synthesiser can infer a a complete async fifo. But using instantited >> components is a direct textual equivalant to schematic entry, so there >> is no design element that can be placed on a schematic that can't be >> included in a HDL design. Period. (as you Americans say). > >i would strongly disagree that instantiated components in a hdl is a direct >equivalent to schematic entry. now, if you draw schematics such that there is just a >group of black blox symbols on the sheet, with a textual label on them as a reference >designator indentifying the function, and no interconnection between components with >lines, just labels for a small net attached to each pin, and the symbols for each >component positioned linearly on the page, without respect for data flow or time, >then you would have an equivalence. while some engineers do draw schematics that >way, it loses a lot of information. > But functionally they still are equivalent, assuming the synthesis tool treats instantiated components as black boxes and does not attempt to re-optimize. Aesthetically they are very different, put that's just a matter of style. I've seen schematics that would take days, weeks, or months to determine the intended function intended by the original designer, similarly I've seen HDL code that would take just as long. Early in my career there was a senior designer that thought that if no one else could decipher his schematics it would give him some measure of job security. He actually stated this to me when I asked him why the 50 odd sheets in his design used no hierarchy nor flow. Later in my career I picked up a ASIC design implemented in Verilog (75% structural and 25% RTL), which had exactly ZERO comments. It had a good use of hierarchy, but required a lot of time with the Fujitsu cell library book. It took several months with the simulator and print outs before I got a solid grip on the design. In contrast to the above two ASICs designs, I've seen schematics with beautiful use of hierarchy, flow, truth tables, etc... AND I've seen HDL designs with the same that were quite easy to pick-up and take over. When drawing schematics or writing HDL code, one should always taken into consideration the following possibility: The designer of the next iteration of the design or the continuation engineer may be A CRAZED LUNATIC WHO KNOWS WHERE YOU LIVE! The main point here is that either Schematics or HDLs can get the job done and it is simply a matter of choice. HDL (IMHO) is more portable, but in a previous job we drew Viewlogic schematics which had ASIC cell mappings such that we could take the same design to Toshiba, LSI, VLSI, etc.. depending on which foundry our end customer selected. For the last design I worked on with this employer, the choice wasn't made until one week before the target PNR netlist release date, no problem with the system we had in place. The biggest disadvantage I see with schematics is the dependency on the EDA supplier, as moving a design from one schematic environment to another is not as easy as changing synthesis vendors; while neither is completely free of pain, I'd choose the synthesis route. One company I worked for still uses the Vanguard Schematic capture system, years after Terradyne sold it off and Sofia Systems stopped supporting it in the US, but re-drawing the schematic database in another package never quite fit into the schedule (especially with the amount of re-use we were able to employ). We simply chose to stay with the package we knew and it's known bugs and limited set of seats we had (usually sufficient if the stars aligned properly), putting off the inevitable transition till tomorrow. If someone had asked me my opinion on this subject during my transition period from schematic entry to HDL you'd definitely have received a much different response. But after the transition period, in 8 years of Verilog HDL design, I have yet to find the design that forced me back to schematics (structural instantiation: yes; schematics: no). Now as a Field Applications Engineer I've picked up VHDL as well. It was kind of like learning PALASM after knowing ABEL, then later picking up CUPL, each new language just gets easier. But I have a good mix of customers that refuse to go down the learning curve of HDLs and stick with the schematic tools and methods they know. The still get the job done, so I'd find it very difficult in most cases to disagree with there decision. The biggest problem I see with HDLs today is that younger designers who've never drawn a schematic in there career are at a distinct disadvantage from those that have, and are very much at the mercy of the synthesis tool. Some form of schematic capture still has to be taught at the pre-grad level to ensure these engineers understand the underlying gates. >======================================================= > >> I believe that the mixed inferred/instantiated method is used by most >> experienced HDL designers. A designer might predominately infer logic, >> but a some point will say to themselves 'it will be easier to just >> instantiate this element and have done with it'. > >or hook a mixture of components, schematic, macro, and hdl on a top level roadmap or >dare i say, schematic. a large amount of instantiated logic is good for 'puters, in >my opinion, not for humanoids. > >======================================================== > >rk >Article: 13834
>22V10s and most other >PLDs are based on AND/OR planes, which are bound to be glitchy if the >designer hasn't (a) added product terms to mask the effects of >transition or (b) synchronized asynchronous inputs. I do not agree with this. Let's say you are using a 22V10 as a simple decoder. If what you say is true, it would be virtually impossible to make a decoder which does not generate a glitch before settling down. No, a GAL "must" be designed so that the skew between the true and complement versions of an input, plus any other skews generated by the layout of the product matrix, is **less than** the switching time of the gate implementing the product matrix. The situation is made more complex by the different implementation of the product matrix in a conventional GAL (a load of wire-ORed signals with pullups, feeding sense amplifiers, AIUI, which is why they draw so much static current) versus a "zero power" GAL like the P3Z22V10 which uses a chain of gates to form a mux. On top of that you get the weird "semi" zero power GALs which use input transition sensing to power the product array up/down, to somehow achieve good data sheet specs... Without withing to make this thread even longer, and despite what has been said here, I cannot see the problem in *sampling* a *single* async input, with a *Gray-code* state machine. In such a state machine, only *one* D-type at any one time can potentially act on that input, so either a) the input change is just sampled (and you go to the next state) or b) the input change is just missed (and you remain in the present state). The only risk (which truly cannot be avoided) is with *metastability*, and that comes down purely to whether the D-type settles down before the next clock comes along. -- Peter. Return address is invalid to help stop junk mail. E-mail replies to zX80@digiYserve.com but remove the X and the Y.Article: 13835
Here's another 2 centi-euros(?) worth. At the risk of annoying a lot of people, there seem to be a number of red herrings here (doubtless I'll be severely kicked if I've misunderstood): 1) Static hazards. This is irrelevant, since we're talking about a synchro: it doesn't matter whether the output settles to 1 or 0, and so it doesn't matter whether there are any glitches on the combinatorial logic feeding the synchro f/f, or when these glitches are sampled. 2) differential delays on a signal and its inverse in an AND-OR array: doesn't matter, for exactly the same reason. 3) Metastability: not, per se, a problem. There's no problem incorporating a synchro into a state machine, as long as you can guarantee that only one register bit samples the asynchronous signal (pretty much what Peter Alfke (among others?) said, although in passing). In this case, both EQ2 and EQ0 sample ENC_IN. This will eventually fail since EQ2 and EQ0 will occasionally disagree on the value of ENC_IN. You don't need a Gray-coded machine - you just have to make sure that only one f/f samples the input. The only way that this can fail is if the f/fs output still hasn't stabilised after one cycle, which is astronomically unlikely in this case. In this case, to explain the 100 -> 101 -> 001 sequence you may have to invoke a hazard, or whatever (I can't explain it just by assuming that EQ2 and EQ0 have sampled different values), but I find it hard to believe that you could eventually make this machine work by removing all hazards - you'll still have two registers sampling ENC_IN. It would be nice to see your original state transition diagram. Presumably the root of the problem is that you're looking at ENC_IN at two different points on the diagram. If you were only looking at one point, then the interesting question is why ENC_IN isn't optimised out of the other two register bits. EvanArticle: 13836
ems@riverside-machines.com.NOSPAM writes:
> Here's another 2 centi-euros(?) worth. At the risk of annoying a lot
> of people, there seem to be a number of red herrings here (doubtless
> I'll be severely kicked if I've misunderstood):
Where do you want to be kicked? :-)
> 1) Static hazards. This is irrelevant, since we're talking about a
> synchro: it doesn't matter whether the output settles to 1 or 0, and
> so it doesn't matter whether there are any glitches on the
> combinatorial logic feeding the synchro f/f, or when these glitches
> are sampled.
What do you mean by a "synchro"? Never heard that term before. Indeed
tht logic hazards do matter, because they can (and do) occur just as
the the DFF is sampled. Whether it's one or more DFFs, doesn't matter.
[...]
> In this case, both EQ2 and EQ0 sample
> ENC_IN. This will eventually fail since EQ2 and EQ0 will occasionally
> disagree on the value of ENC_IN. You don't need a Gray-coded machine -
> you just have to make sure that only one f/f samples the input.
That wouldn't have helped. The logic hazards would still be there. In
fact, if you look at the equations, you do see that EQ0 and EQ2
samples ENC_IN at *differeent states*. They will never care what
the value of ENC_IN has at the same transition. The other terms in the
product take care of that.
> In this case, to explain the 100 -> 101 -> 001 sequence you may have
> to invoke a hazard, or whatever (I can't explain it just by assuming
> that EQ2 and EQ0 have sampled different values), but I find it hard to
> believe that you could eventually make this machine work by removing
> all hazards - you'll still have two registers sampling ENC_IN.
But not at the same time. I wish Peter would try the solution I
suggested, and see how it works.
> It would be nice to see your original state transition diagram.
> Presumably the root of the problem is that you're looking at ENC_IN at
> two different points on the diagram.
Actually, he is looking four times for the value of ENC_IN. Twice for
each EQ0/EQ2. That is the problem.
Hope this clarifies it.
Homann
--
Magnus Homann Email: d0asta@dtek.chalmers.se
URL : http://www.dtek.chalmers.se/DCIG/d0asta.html
The Climbing Archive!: http://www.dtek.chalmers.se/Climbing/index.html
Article: 13837
Daniel K. Elftmann wrote:
> >i would strongly disagree that instantiated components in a hdl is a direct
> >equivalent to schematic entry. now, if you draw schematics such that there
> is just a
> >group of black blox symbols on the sheet, with a textual label on them as a
> reference
> >designator indentifying the function, and no interconnection between
> components with
> >lines, just labels for a small net attached to each pin, and the symbols for
> each
> >component positioned linearly on the page, without respect for data flow or
> time,
> >then you would have an equivalence. while some engineers do draw schematics
> that
> >way, it loses a lot of information.
>
> But functionally they still are equivalent, assuming the synthesis tool
> treats instantiated components as black boxes and does not attempt to
> re-optimize.
functionally equivalent yes; direct equivalent nope. this is always a nice
religious argument to get into, but the edif netlist produced by actmap, for
example, is functionally equivalent to say its structural vhdl input which is,
according to some, equal to a schematic. well, if we only have computers
reading and writing these things i would agree [and at my day job we have a nice
little project where we do have computers writing the vhdl so i don't care what
it looks like or how awful it is to write, since it's generated algorithmically
by a HLL]. however, if we have humanoids writing, reading, and maintaining the
code, then they are most definitely not directly equivalent. i have seen too
many schematics drawn w/ just isolated symbols with short unconnected nets that
are labelled. that is the direct equivalent of a vhdl structural source file.
of course, one can avoid specifying the reference designators or labels for each
of them, making them both the direct equivalent mess when you gotta go in and
troubleshoot the thing.
======================================================
> Aesthetically they are very different, put
> that's just a
> matter of style. I've seen schematics that would take days, weeks, or
> months to determine the intended function intended by the original designer,
yes, as i described above. i've spent more than enough time redrawing
schematics so that i can understand what's going on. and back in the '80s, when
we actually had draftsman and a drafting department, some of them would take the
nice hand drawn schematic and enter it into the machine, making the most
efficient use of the space on the paper, never sure why, probably some
government standard. :-)
=======================================================
> similarly I've seen HDL code that would take just as long.
yes, and at day job i had purchased "VHDL cores" that were, in a large part, a
structural vhdl netlist [friendly shot across the bow, sorry, couldn't resist
:-)].
========================================================
>
> Early in my
> career there was a senior designer that thought that if no one else could
> decipher his schematics it would give him some measure of job security. He
> actually stated this to me when I asked him why the 50 odd sheets in his
> design used no hierarchy nor flow.
interesting. i remember one engineer who was less than happy with the fact that
the employer "owned" all of his notebooks, notes, etc. troubled him a lot. so
he kept all of his notebooks in chinese and happily turned them in when he left.
=========================================================
> Later in my career I
> picked up a ASIC
> design implemented in Verilog (75% structural and 25% RTL), which had
> exactly ZERO comments. It had a good use of hierarchy, but required a lot
> of time with the Fujitsu cell library book. It took several months with the
> simulator and print outs before I got a solid grip on the design.
and more recently, at day job, i received a "design" for a certain
manufacturer's device, with 8,000 gate capacity, that was 99% structural vhdl.
it seems that a contractor gave the design to a subcontractor who gave the
design to a sub-sub-contractor who took the original schematics and
hand-converted it into a structural vhdl description before tossing it into the
synthesis tool. don't ask me why, perhaps a cost-plus contract? the design had
timing problems and to figure out what was going on, i had to start drawing
schematics from the vhdl, as for some still unspecified reason, the schematics
were not available. what a mess!
=======================================================
>
> In
> contrast to the above two ASICs designs, I've seen schematics with beautiful
> use of hierarchy, flow, truth tables, etc... AND I've seen HDL designs with
> the same that were quite easy to pick-up and take over.
agreed, 100%. i used to hate drawing schematics on the machine, very time
consuming, much prefer the berol's 1/4 size template and a drafting table.
seemed to work well and was much quicker (circa '84, approx 4-5 seconds to call
up an AND gate). it takes time to make a good schematic, but it's something
that you gotta live with for a long time, so it's worth it. same with vhdl, i
take quite a bit of time in lining up columns and stuff [old habits from 20+
years of coding pascal no doubt].
=======================================================
> When drawing schematics or writing HDL code, one should always taken into
> consideration the following possibility:
>
> The designer of the next iteration of the design or the continuation
> engineer may be A CRAZED LUNATIC WHO KNOWS WHERE YOU LIVE!
a good point. but i'm from NY and just don't care. :-)
==========================================================
> The main point here is that either Schematics or HDLs can get the job done
> and it is simply a matter of choice. HDL (IMHO) is more portable,
i would agree, unless it's coded in structural vhdl.
===========================================================
>
> but in a
> previous job we drew Viewlogic schematics which had ASIC cell mappings such
> that we could take the same design to Toshiba, LSI, VLSI, etc.. depending on
> which foundry our end customer selected. For the last design I worked on
> with this employer, the choice wasn't made until one week before the target
> PNR netlist release date, no problem with the system we had in place.
i've done similar things, using actel tools and libraries, since that's what's
available here at home, and then after logic simulation re-mapping primitives
onto chip express asic primitives, etc., and then a final sim on a machine with
a more power viewlogic license it works rather nicely.
===========================================================
>
> The
> biggest disadvantage I see with schematics is the dependency on the EDA
> supplier, as moving a design from one schematic environment to another is
> not as easy as changing synthesis vendors; while neither is completely free
> of pain, I'd choose the synthesis route.
i agree with this to a certain degree. i have found that writing code for
multiple simulators/synthesizers takes some work, far too much in my opinion,
and that this really hurts the industry as a whole. go ahead, write portable c
code, for instance; when i was doing it (late '80s) it was a mess, not sure if
it's really any better now. it looks like the eda industry is determined to
screw themselves the same way. ada was very strict about this sort of thing,
but was so strict about no subsets, for instance, that that killed the market.
vhdl is too much do your own thing - just look at all the notes here about
converting types, which libraries to use (since common functions are not part of
the language), etc., etc.
now, it is easier to port vhdl code from tool to tool than schematics. on one
job i'm on [day job], multiple schematic tools were used for different boards.
seemed like a big mistake early on but, hey, the managers are always right. no
attention was paid to partitioning and now, for the final product, several
boards done in different tool environments need to be merged. so, what is
happenning? we're paying engineers to re-type in schematics and we all have to
proof read them again, getting all of his new typographical errors out. a total
pain. and a waste of time and $. now, i don't have any experience with it, but
does the edif system work well for transferring schematics between systems? i
don't have the licenses for it for my viewlogic system so i was never able to
give it a try.
on the other hand, when you read a schematic you know exactly what has been
designed. when reading hdl code, you can get an idea of what has been
designed. however, the actual design will be a function of:
- synthesizer used
- version of the synthesizer used (can be updated day by day, apparrently)
- constraint files for synthesizers
- phase of the moon (aka random seed)
- directives to synthesizers (i.e., state encoding method)
- etc., etc.
so, one can make a good case that schematics have poor portability but vhdl is
even weaker, since the hdl files do not fully capture the design at all.
=========================================================
> One company I
> worked for still
> uses the Vanguard Schematic capture system, years after Terradyne sold it
> off and Sofia Systems stopped supporting it in the US, but re-drawing the
> schematic database in another package never quite fit into the schedule
> (especially with the amount of re-use we were able to employ). We simply
> chose to stay with the package we knew and it's known bugs and limited set
> of seats we had (usually sufficient if the stars aligned properly), putting
> off the inevitable transition till tomorrow.
i feel your pain. and i feel it hard. and i will be feeling it harder in the
near future, i am sure. one of the things that i'm evaluating now is whether to
keep the current design environment or upgrade to a newer, more modern one.
perhaps it's a question of long term gain vs. short term pain. either way i
know i will suffer.
=========================================================
> If someone had asked me my opinion on this subject during my transition
> period from schematic entry to HDL you'd definitely have received a much
> different response. But after the transition period, in 8 years of Verilog
> HDL design, I have yet to find the design that forced me back to schematics
> (structural instantiation: yes; schematics: no).
one class of circuits that i like much better in schematics is synchronizers.
another is ripple counters. of course, for ripple counters, it's easiest to
simply use programs like actgen and have it automagically generate a nice
symbol. then i can take the symbol and just drop it down onto my higher level
schematic. less work and more readable than having to type in the component
definition and then the named association on parameters, or making sure that you
get the order right for positional parameters, or doing generate statements,
etc., etc. of course, with a schematic and a symbol, it's easy to hook up and
verify, with no declarations needed.
another class of circuits that i like schematics better for is multipliers.
typing in Y = A*B just doesn't seem to make it for me. especially if i decide
to control the pipelining myself and perhaps use signed magnitude numbers, which
have certain advantages. high-speed, low-power accumulators also fit into this
area. where i can optimize it far easier in a schematic (perhaps with a vhdl or
actgen subcomponents included) than i could in vhdl, which would be rather
clunky.
another nice example is the simple adder. let's say i type Y = A+B and i'm
trying to minimize for area. and let's say i do this with, for example, the
actmap synthesizer (so you can try this at home). i find that actmap, when
configured for area optimization, calls actgen to do the heavy lifting, with a
medium speed adder called out. is there a way to tell actmap to tell actgen to
give me a ripple carry adder? there is a substantial difference in the number
of modules used, approximately 50%. this is not just a function of actmap, but
i've tried some substantially more expensive tools which produced the same
result. synopsys design compiler, with proper constraints, did do as well as
actgen.
i could go on and on, but there's enough cases where i find schematics easier to
get the answer that i want that i jump up and down everytime people say they're
not needed or won't be available. it takes a lot of work, sometimes, to get the
answer that you want with HDLs.
=============================================================
>
> Now as a Field
> Applications Engineer I've picked up VHDL as well. It was kind of like
> learning PALASM after knowing ABEL, then later picking up CUPL, each new
> language just gets easier. But I have a good mix of customers that refuse
> to go down the learning curve of HDLs and stick with the schematic tools and
> methods they know. The still get the job done, so I'd find it very
> difficult in most cases to disagree with there decision.
>
> The biggest problem I see with HDLs today is that younger designers who've
> never drawn a schematic in there career are at a distinct disadvantage from
> those that have, and are very much at the mercy of the synthesis tool. Some
> form of schematic capture still has to be taught at the pre-grad level to
> ensure these engineers understand the underlying gates.
i'm not sure where this is to be taught, and perhaps i'm just a bit of a geezer,
but i think that schematics are important (currently my design mix is split
between vhdl, macro's, and schematics), especially at higher levels. i much
prefer the schematic "roadmap" then structural vhdl, which does not show the
flow of data or timing for pipelined designs at all.
of course, some products in the marketplace do not support schematics! an
example is, er, gatefield (friendly elbow to the ribs). i called them up [well,
actually e-mailed them] and verified what i found on their www site, HDL entry
only. same is true for the cx2001 and cx3001 series from chipx and we recently
had a nice, long, heated thread about the xilinx virtex situation.
==========================================================
well, i guess time to get a little work done,
rk
Article: 13838Peter - On Tue, 29 Dec 1998 15:06:40 GMT, z80@ds2.com (Peter) wrote: > (I wrote:) >>22V10s and most other >>PLDs are based on AND/OR planes, which are bound to be glitchy if the >>designer hasn't (a) added product terms to mask the effects of >>transition or (b) synchronized asynchronous inputs. > >I do not agree with this. > >Let's say you are using a 22V10 as a simple decoder. If what you say >is true, it would be virtually impossible to make a decoder which does >not generate a glitch before settling down. > >No, a GAL "must" be designed so that the skew between the true and >complement versions of an input, plus any other skews generated by the >layout of the product matrix, is **less than** the switching time of >the gate implementing the product matrix. Sorry to say, they generally aren't designed to be glitchless. Nor do they have to be. An address decoder *will* glitch, unless you do something to keep it from glitching, like disabling a common decode enable until the decode input lines settle (and it helps to have some idea of how the common enable is implemented, to ensure it really is gating off the outputs glitchlessly). The way I deal with these glitches is to make them a don't-care by doing synchronous design. For example, if I use address decodes to drive the (synchronous) clock enables of flip-flops, the glitch is a don't-care as long as I meet the setup and hold times of the clock enable. This is an old, old problem, by the way. Many of us old, old engineers first encountered it when we watched someone try to use the combinatorial terminal count output of a 74161 binary counter to clock a flip-flop. These terminal counts ORed the outputs of the four synchronous counter bits (and a count enable input, too, if I remember correctly). Some of them would output narrow glitches at various count transitions, such as 0111->1000. I remember one designer commenting that, although he knew his design was malfunctioning, he couldn't see glitches on the terminal count when he put a scope probe on it. I commented that the design was probably OK as long as he shipped it with the scope probe attached (probes were more capacitve in those days, and I was more sarcastic). Regards, Bob Perlman Cambrian Design WorksArticle: 13839
Bob Perlman wrote: > This is an old, old problem, by the way. Many of us old, old > engineers first encountered it when we watched someone try to use the > combinatorial terminal count output of a 74161 binary counter to clock > a flip-flop. These terminal counts ORed the outputs of the four > synchronous counter bits (and a count enable input, too, if I remember > correctly). for this series the RCO was ANDed with the ENT input and not the ENP. didn't even have to look it up. guess that makes me a geezer. some of the other TTL counters were a bit friendlier with their RCO, but not the 160-163 series. ========================================== rkArticle: 13840
Peter wrote:
< snip bunch of stuff on PAL internals >
> Without withing to make this thread even longer, and despite what has
> been said here, I cannot see the problem in *sampling* a *single*
> async input, with a *Gray-code* state machine. In such a state
> machine, only *one* D-type at any one time can potentially act on that
> input, so either a) the input change is just sampled (and you go to
> the next state) or b) the input change is just missed (and you remain
> in the present state).
i agree, 100%, there is no problem, that's why the gray code is popular.
the gray code can be generated by a mechanical device, or perhaps an
electro-mechanical one for things like shaft encoders, or the gray code
can be generated electronically. for the latter, i typically have an
asynchronous input clock a gray code counter, which i can sample whenever
i feel like it, and never have an error more than one count. in the
original topology, the output of a register is fed back into a logic
"cloud" along with an asynchronous input. in this case, the logic must be
designed so that only 1 output can change at a time, which implies that
there are no static hazards, or this can be violated.
===================================================
> The only risk (which truly cannot be avoided) is with *metastability*,
> and that comes down purely to whether the D-type settles down before
> the next clock comes along.
the failure rate is calculated and can be made small enough to be
negligible for most applications.
====================================================
rk
Article: 13841
--------------65EA94FA3AA6AE7F15D8131E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
ems@riverside-machines.com.NOSPAM wrote:
> Here's another 2 centi-euros(?) worth. At the risk of annoying a lot
> of people, there seem to be a number of red herrings here (doubtless
> I'll be severely kicked if I've misunderstood):
>
> 1) Static hazards. This is irrelevant, since we're talking about a
> synchro: it doesn't matter whether the output settles to 1 or 0, and
> so it doesn't matter whether there are any glitches on the
> combinatorial logic feeding the synchro f/f, or when these glitches
> are sampled.
sorry. <rk puts on his boots> it does matter that the combinational logic
glitches. if the output of the combinational circuit is supposed to be:
Input Y2 Y1 Y0
0 1 0 0
1 1 0 1
but there is a glitch or a static hazard, you can get:
Input Y2 Y1 Y0
0 1 0 0
1 0 0 1 <- an "oh, sh*t" state
1 1 0 1
and you are unfortunate that your slow and easy 1 MHz clock edge samples
on the "OS" state, you will have a bad transition.
now, in the first case, suppose the 1 MHz edge arrives as Y0 is changing.
this can cause the f-f that samples it, Q0, to "go metastable" for a
certain amount of time. the design needs to take this into account and
let the flip-flop settle (to whatever level or reliability is desired)
before sampling its output.
=================================================================
> 2) differential delays on a signal and its inverse in an AND-OR array:
> doesn't matter, for exactly the same reason.
i agree with this, provided the logic block doesn't have any glitches in
it, and provided that the sampling isn't ridiculously fast.
==========================================================
> 3) Metastability: not, per se, a problem.
as long as a reasonable amout of settling time is given. with modern
high-speed flip-flops, this time is getting to be quite small.
===========================================================
> There's no problem incorporating a synchro into a state machine, as
> long as you can guarantee that only one register bit samples the
> asynchronous signal (pretty much what Peter Alfke (among others?)
> said, although in passing).
exactly, but in the original problem, it appeared that one input to the
logic block made perhaps two inputs to the register change.
=============================================================
> In this case, both EQ2
> and EQ0 sample
> ENC_IN. This will eventually fail since EQ2 and EQ0 will occasionally
> disagree on the value of ENC_IN. You don't need a Gray-coded machine -
> you just have to make sure that only one f/f samples the input. The
> only way that this can fail is if the f/fs output still hasn't
> stabilised after one cycle, which is astronomically unlikely in this
> case.
agreed, and a f-f synchronizing the asynchronous input before it enters
the logic block would do the trick. [i think i understood all of what you
wrote, if not, then my fault, scrolling back through these messages gets a
tad confusing]. but without the synchronizer on the asycn input, a gray
code output from the logic block is needed. if the logic block glitches,
it's not gray code, be definition.
==============================================================
> In this case, to explain the 100 -> 101 -> 001 sequence you may have
> to invoke a hazard, or whatever (I can't explain it just by assuming
> that EQ2 and EQ0 have sampled different values), but I find it hard to
> believe that you could eventually make this machine work by removing
> all hazards - you'll still have two registers sampling ENC_IN.
again, trying to put multiple posts together, even if all of the outputs
of the logic block are a function of the asynchronous input, as long as
the unchanging outputs don't glitch (i.e., no static hazard), the machine
will work fine and the output of the logic block will be a gray code. one
way to do that is to have the asynch input clock a gray coded state
machine. not practical here, since the 22v10 doesn't have enough f-f's.
but you can eliminate static hazards and get the same effect. the classic
example is the 2:1 mux. if both inputs to the mux are a '1', then when
the select changes from a '1' to a '0', then it is possible that both
product terms will be off. by adding in the extra term, the product of
the two inputs, you can be assured that the function will not glitch. the
best explanation of this that i have seen is in DIGITAL CIRCUITS by
chirlian, 1976. i think the new horowitz and hill has a good explanation
too, but the commander in chief stole it. or, as peter a. explained,
sneak in some extra memory - xilinx and quicklogic do this by relying on
capacitance, which serves as a latch, one that will be stable for a short
period of time only, but enough time to get the job done.
==========================================================
just my $0.02 [don't know what a euro is worth],
rk
--------------65EA94FA3AA6AE7F15D8131E
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<HTML>
ems@riverside-machines.com.NOSPAM wrote:
<BLOCKQUOTE TYPE=CITE>Here's another 2 centi-euros(?) worth. At the risk
of annoying a lot
<BR>of people, there seem to be a number of red herrings here (doubtless
<BR>I'll be severely kicked if I've misunderstood):
<P>1) Static hazards. This is irrelevant, since we're talking about a
<BR>synchro: it doesn't matter whether the output settles to 1 or 0, and
<BR>so it doesn't matter whether there are any glitches on the
<BR>combinatorial logic feeding the synchro f/f, or when these glitches
<BR>are sampled.</BLOCKQUOTE>
<TT>sorry. <rk puts on his boots> it does matter that the combinational
logic glitches. if the output of the combinational circuit is supposed
to be:</TT><TT></TT>
<P><TT> Input
Y2 Y1 Y0</TT>
<BR><TT> 0
1 0 0</TT>
<BR><TT> 1
1 0 1</TT><TT></TT>
<P><TT>but there is a glitch or a static hazard, you can get:</TT><TT></TT>
<P><TT> Input
Y2 Y1 Y0</TT>
<BR><TT> 0
1 0 0</TT>
<BR><TT> 1
0 0 1 <- an "oh, sh*t" state</TT>
<BR><TT> 1
1 0 1</TT><TT></TT>
<P><TT>and you are unfortunate that your slow and easy 1 MHz clock edge
samples on the "OS" state, you will have a bad transition.</TT><TT></TT>
<P><TT>now, in the first case, suppose the 1 MHz edge arrives as Y0 is
changing. this can cause the f-f that samples it, Q0, to "go metastable"
for a certain amount of time. the design needs to take this into
account and let the flip-flop settle (to whatever level or reliability
is desired) before sampling its output.</TT><TT></TT>
<P><TT>=================================================================</TT>
<BLOCKQUOTE TYPE=CITE>2) differential delays on a signal and its inverse
in an AND-OR array:
<BR>doesn't matter, for exactly the same reason.</BLOCKQUOTE>
i agree with this, provided the logic block doesn't have any glitches in
it, and provided that the sampling isn't ridiculously fast.
<P>==========================================================
<BLOCKQUOTE TYPE=CITE>3) Metastability: not, per se, a problem.</BLOCKQUOTE>
as long as a reasonable amout of settling time is given. with modern
high-speed flip-flops, this time is getting to be quite small.
<P>===========================================================
<BLOCKQUOTE TYPE=CITE>There's no problem incorporating a synchro into a
state machine, as
<BR>long as you can guarantee that only one register bit samples the
<BR>asynchronous signal (pretty much what Peter Alfke (among others?)
<BR>said, although in passing).</BLOCKQUOTE>
exactly, but in the original problem, it appeared that one input to the
logic block made perhaps two inputs to the register change.
<P>=============================================================
<BLOCKQUOTE TYPE=CITE>
In this case, both EQ2 and EQ0 sample
<BR>ENC_IN. This will eventually fail since EQ2 and EQ0 will occasionally
<BR>disagree on the value of ENC_IN. You don't need a Gray-coded machine
-
<BR>you just have to make sure that only one f/f samples the input. The
<BR>only way that this can fail is if the f/fs output still hasn't
<BR>stabilised after one cycle, which is astronomically unlikely in this
<BR>case.</BLOCKQUOTE>
agreed, and a f-f synchronizing the asynchronous input before it enters
the logic block would do the trick. [i think i understood all of
what you wrote, if not, then my fault, scrolling back through these messages
gets a tad confusing]. but without the synchronizer on the asycn
input, a gray code output from the logic block is needed. if the
logic block glitches, it's not gray code, be definition.
<P>==============================================================
<BLOCKQUOTE TYPE=CITE>In this case, to explain the 100 -> 101 -> 001 sequence
you may have
<BR>to invoke a hazard, or whatever (I can't explain it just by assuming
<BR>that EQ2 and EQ0 have sampled different values), but I find it hard
to
<BR>believe that you could eventually make this machine work by removing
<BR>all hazards - you'll still have two registers sampling ENC_IN.</BLOCKQUOTE>
again, trying to put multiple posts together, even if all of the outputs
of the logic block are a function of the asynchronous input, as long as
the unchanging outputs don't glitch (i.e., no static hazard), the machine
will work fine and the output of the logic block will be a gray code.
one way to do that is to have the asynch input clock a gray coded state
machine. not practical here, since the 22v10 doesn't have enough
f-f's. but you can eliminate static hazards and get the same effect.
the classic example is the 2:1 mux. if both inputs to the mux are
a '1', then when the select changes from a '1' to a '0', then it is possible
that both product terms will be off. by adding in the extra term,
the product of the two inputs, you can be assured that the function will
not glitch. the best explanation of this that i have seen is in DIGITAL
CIRCUITS by chirlian, 1976. i think the new horowitz and hill has
a good explanation too, but the commander in chief stole it. or,
as peter a. explained, sneak in some extra memory - xilinx and quicklogic
do this by relying on capacitance, which serves as a latch, one that will
be stable for a short period of time only, but enough time to get the job
done.
<P>==========================================================
<P>just my $0.02 [don't know what a euro is worth],
<P>rk</HTML>
--------------65EA94FA3AA6AE7F15D8131E--
Article: 13842Hal Murray wrote: > Wow! I haven't seen anything like that from Peter Alfke before. > > <snip> > > I claim the problem isn't under control until metatstbility > data gets published in data sheets rather than ApNotes. There is a problem: The numbers printed in the data sheet are supposed to be 100% production tested, or at least be derived from 100% production testing. And that's what we do, 100% production testing at elevated temperature and low Vcc.This is just not possible with metastability numbers. They can only be sample-tested in a specialized jig. > > > Note that the Xilinx ApNote that Peter referenced is over > a year old. What if I want to use a chip released since then? Anything we have designed and introduced recently is just plain better, i.e. it resolves the metastable situation even faster. I did not publish recent results because they were so much better than the previous ones that I started to doubt their ( and my ) sanity. > > > What was the temp and Vcc during those tests? Can I assume it > is worst case? No. But that's a suggestion for the next series of test. Before I get accused of ignorance let me "make one point perfectly clear": Metastability is a nasty problem because it can cause a normally well-behaved synchronous flip-flop to change state at a completely uncontrolled moment. That's ugly. Modern CMOS flip-flops, however, have such a high gain-bandwidth product in their feedback path that they recover extremely fast, usually in a matter of fractional or a few nanoseconds. The XC4005E-3 CLB flip-flop of 2 years ago, when synchronizing a 1 MHz asynchr. event with a 10 MHz clock, would stay metastable for 2 ns once in a million years. At 20 MHz and a 50 MHz clock, those 2 ns would statistically occur once per 10,000 years. And the newer devices are much better. That's what I meant when calling metastability an overrated problem. It will never be eliminated, but progress in IC processing has dramatically reduced its significance. The XC3042-70 of 1988 would have the unpredictable 2 ns delay not once per million years, but once every second ! That means, the frequency of occurence ( for given clock rates and delays ) has been reduced by 14 decimal orders of magnitude, more than one order of magnitude every year, while average digital system speed has only been doubling every four-to-five years. I would call that progress. Peter Alfke, Xilinx ApplicationsArticle: 13843
rk <stellare@NOSPAMerols.com> writes:
> Peter wrote:
>
> < snip bunch of stuff on PAL internals >
>
> > Without withing to make this thread even longer, and despite what has
> > been said here, I cannot see the problem in *sampling* a *single*
> > async input, with a *Gray-code* state machine. In such a state
> > machine, only *one* D-type at any one time can potentially act on that
> > input, so either a) the input change is just sampled (and you go to
> > the next state) or b) the input change is just missed (and you remain
> > in the present state).
>
> i agree, 100%, there is no problem, that's why the gray code is popular.
I disagree. In fact, here's an example.
Consider a SM where from state "00" you go to "01" on IN = '1' or to
"10" on IN = '0'. If the signals change within, say, x ps skew,
there's still a chance to get to state "11". I don't think you can
design a PAL to reliably handle this situation. Non-glitching LUTs
wont help you either.
It's a bit forced example, but not entirely unlikely to happen.
Homann
--
Magnus Homann Email: d0asta@dtek.chalmers.se
URL : http://www.dtek.chalmers.se/DCIG/d0asta.html
The Climbing Archive!: http://www.dtek.chalmers.se/Climbing/index.html
Article: 13844Couldn't resist the chance to rename this thread, and put in my 2 cents along with all of the illustrious respondents. We have a long ways to go to be the longest thread. 1. Glitchless logic - To summarize what most people are saying, even if the logic in front of a gray coded state machine is glitchless, it can still cause illegal transitions if more than 1 D input changes at the same time. The logic must be designed not only glitchless, but also such that only 1 D input can change at one time. That's been covered very well, and was enlightening to me. 2. Metastability - seems not to be the problem here, and can burn you if you do stupid things, such as use the output of a synchronizer to drive a clock input, or depend on 2 synchronizers to make the same decision. Nobody has really said much about metastability here, so I'd like to share what I think is a real good example (a simplification) of exactly how metastability can occur if a flip-flop. There are two conditions that can easily cause metastability. Race conditions and runt pulses. Race Conditions: Picture an ordinary cross coupled latch made of 2 nand-gates with exactly identical finite prop delays. Connect both inputs together, and ground them. Both outputs are high. Now, connect both inputs to logic 1. You now have an oscillator that will never stop. Runt Pulse: Take the same cross coupled latch and start with a stable initial condition, both inputs high and the top gate with its output low. Apply a low going pulse that is less than the prop delay to the top gate. You now have another oscillator. Now, as a mental exercise, notice what happens in the race example if the prop delays are not balanced, or in either example if there are imbalanced finite rise and fall times. Either of these conditions occurring inside a synchronizer will cause strange results. I'm not saying that these are the *only* conditions that occur, but they are two fine examples of how unpredictable behavior can occur when setup and/or hold times are violated, and illustrate how metastable effects can be of infinite duration. BruceArticle: 13845
Magnus Homann wrote: > ....In fact, here's an example. > > Consider a SM where from state "00" you go to "01" on IN = '1' or to > "10" on IN = '0'. If the signals change within, say, x ps skew, > there's still a chance to get to state "11". I don't think you can > design a PAL to reliably handle this situation. Non-glitching LUTs > wont help you either. > That's exactly what I tried to explain earlier. Thanks, Magnus, for the simple example. Grey code doesn't help, neither does the non-glitching LUT. It is more fundamental: NEVER synchronize an asynchronous control input in more than a single flip-flop. All the other dozen responses make for interesting reading, but I am pretty sure that this example here explains the real root cause. Peter Alfke, Xilinx ApplicationsArticle: 13846
Bruce Nepple wrote: > snip > Nobody has really said much about metastability here, so I'd like to > share what I think is a real good example (a simplification) of > exactly how > metastability can occur if a flip-flop. There are two conditions that > can > easily cause metastability. Race conditions and runt pulses. > > Race Conditions: > Picture an ordinary cross coupled latch made of 2 nand-gates with > exactly > identical finite prop delays. Connect both inputs together, and > ground > them. Both outputs are high. Now, connect both inputs to logic 1. > You now > have an oscillator that will never stop. Try it: You have a latch that is stable in either state. No way does it oscillate ! > > > Runt Pulse: > > Take the same cross coupled latch and start with a stable initial > condition, > both inputs high and the top gate with its output low. Apply a low > going > pulse that is less than the prop delay to the top gate. You now have > another oscillator. No way again. > > > Now, as a mental exercise, notice what happens in the race example if > the > prop delays are not balanced, or in either example if there are > imbalanced > finite rise and fall times. > > Either of these conditions occurring inside a synchronizer will cause > strange results. I'm not saying that these are the *only* conditions > that > occur, but they are two fine examples of how unpredictable behavior > can > occur when setup and/or hold times are violated, and illustrate how > metastable effects can be of infinite duration. "Infinite duration". You mean a continuously running oscillator?Please, this is engineering, not speculation. Go to the lab.Try it out, and you will see that your explanation is completely wrong. Two cross-coupled NAND gates will never oscillate. Many of us understand metastability fairly well. Let's not confuse the issue with bogus theories. Peter Alfke, Xilinx Applications >Article: 13847
Bruce Nepple (brucen@imagenation.extra.com) wrote: .. : Nobody has really said much about metastability here, so I'd like to share : what I think is a real good example (a simplification) of exactly how : metastability can occur if a flip-flop. There are two conditions that can : easily cause metastability. Race conditions and runt pulses. (Tried to email to Bruce, but "imagenation" wasn't recognized...) Anyone have any info on the current "state of the art" with regard to metastability in D flipflops? I'm interested in using a 74AC74 at 3.3V supply in a situation where metastability is very likely to be excited if it exists. In this particular circuit, if the output isn't stable, that's not really a problem, but if metastability exists and causes unusual stresses to the 'AC74, or causes nasty power supply current spikes, that wouldn't be very nice. Any insights anyone can offer would be most welcome. -- Cheers, Tom tom_bruhns@hp.comArticle: 13848
On Thu, 24 Dec 1998 13:28:46 -0800, "George" <gazhao@ece.ucsd.edu> wrote: >Hi, Can anyone help me to solve this problems? >I start to use xilinx and VHDL now, but my xilinx foundation basic software >donot support >VHDL synthesis, what a pity. >Now I am thinking of using mentor leonardo to synthesis it, and function >simulate it, and then generate EDIF file. Export it to xilinx foundation, >and then do programming and timing verify. >But, how to do timing verify just with a EDIF file? >And, can I do the whole thing with mentor? with timing simulation and back >annotation? The third party flow is well defined for many vendors, not just Mentor (MGC). 1 - Design Entry Text Editor + Renoir (MGC) 2 - Verification / Simulation ModelSim (MGC) 3 - Synthesis Leonardo Spectrum (MGC) 4 - FPGA P&R and static timing Alliance Series from Xilinx (and Spectrum) 5 - Post P&R Simulation ModelSim (MGC) All you need is the place and route side of the Xilinx tools. This can then produce an EDIF netlist, VHDL (or Verilog) netlist and an SDF. The EDIF & SDF can go back into Spectrum for additional static timing analysis, while the VHDL and SDF are used in ModelSim for timing simulation. The Xilinx "trace" tool will do your static timing fine as part of the flow. Happy New Year. Stuart An employee of Saros Technology, The HDL Solutions Company: Renoir Model Technology Exemplar Logic TransEDA www.saros.co.uk (I sell these products, so paint me biased)Article: 13849
On Fri, 25 Dec 1998 19:23:18 +0200, "Ido Kleinman" <kleinn@REMOVETHIS.mail.biu.ac.il> wrote: >I am using Aldec Active-VHDL 3.2 and Foundation M1.4 (haven't upgraded yet). My sympathies :-) >I need to know how to add xilinx libraries to Active-VHDL so I will be able >to instanciate and simulate components such as TBUFs, IBUFs, BUFGs and so >on. >Foundation Library file-type isn't compatible to Aldec's. You should just need the Vital libraries and map them to the various libraries appropriately. Look in the VHDL directory of your Xilinx installation and check xilinx www for the right way specifically for Aldec. >Also I want to be able to export my design from Active-VHDL to Foundation >implementation and get it back for timing-simulation into Active-VHDL - I >know it's possible and I saw the tutorial in Aldec's Site but it wasn't >helpful since it referenced me to non-existant files. Select the appropriate back-annotation for writing VHDL and SDF from the Design Manager, and then just compile the time_sim.vhd output like it was regular VHDL (it's just a structural netlist). Then you should just simulate, applying the sdf to the appropriate unit under test. This is what I do for ModelSim, and I'm sure that Aldec is fairly similar. Cheers Stuart An employee of Saros Technology, The HDL Solutions Company: Renoir Model Technology Exemplar Logic TransEDA www.saros.co.uk (I sell these products, so paint me biased)
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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