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 wrote: > > I will simply put an HC74 on the async input :) Let us know if your 1 : 1 million error rate then goes away. Also, look at Fairchilds website, they have just released 6 pin SOT23 single registers - if you just want a single FF, a very PCB frugal solution. > Even if I could fix this 8-state state machine, I have another 16-state one in the same > 22V10 which will be a good deal harder to fix, and that uses a similar > async input as well. The ATMEL ATFV750C is due out early Q1 99 :-) ( Its on our programmer menu now ) This is 3.3V, is 22V10 compatible, and has 10 more FF's, for a lot more 'elbow room' on syncronisers, or one-hot-bit state machines... If the system can be split, and usefully work with one state machine, you can do a 'test PLD', that uses the now-spare 22V10 registers to pre-sample, and also see if the problem goes away... We have used this approach, on curly problems like this, with good results. I have seen, and used, a trick that GATE-Latches the Async IN, with the CLOCK, so that it cannot change in the half clock prior to the active edge. This avoids nasty 'aperture effects' of a signal that straddles the CLOCK edge. It also introduces only a half cycle of pre-sample delay.. CUPL also has a MIN keyword, that allows override of the LOGIC MIN used, within CUPL. ( MIN Counta.d = 4; /* level 4 reduction */ ) etc It is possible that fiddling with this, on your state engine, could produce equations that both FIT inside the 22V10, and meet the requirement of a single term -> State transistion - jgArticle: 13876
Actually, there is the Design Manager executable bundled with Foundation. You
just need to do
Start->Programs->Xilinx Foundation Series-> Accessories-> then Design Manager.
Alliance isn't required- you just need to bypass the front end tools.
Mike Peattie
Le mer Michel wrote:
> 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: 13877Jonathan Bromley wrote: > <snip> > I've had no end of > trouble with students' apparently simple, bulletproof sequential > designs in small GAL devices making apparently ridiculous state > transitions, almost always caused by ground bounce. The output > structures on fast CMOS GALs are so fast and brutal that the > dI/dt in the device's ground lead can disturb input thresholds > enough to make another, false clock pulse appear to occur; > since this false pulse is very short indeed, it may fail to > trigger some of the f/fs in the device and so you can get > completely inexplicable activity. This is a real problem, and why I lobby for Hysteresis on PLD lines. It is not getting better, with 'newer' parts :: - the shrinks on devices decrease the aperture times - 'Zero power' devices are mostly Power Wakeup, fastest spec devices - Suppliers can ship fastest spec devices, labeled as slowest As an example, consider a ~50nS risetime ( 10nS / Volt ), and add 200mV of ground noise to this. This produces a 'tolerance aperture' of 2nS - the signal has not arrived at an output pin inside this time, but is well on it's way through the internals. ASIC internal Gate delays of under 100pS are typical of modern processes 50nS Tr is 'good' for a 4000 CMOS device, or a digital Optocoupler or analog comparitor To be reliable, the clock edge must have slewed past the threshold, by more than the ground 'bounces', when they arrive. In a real device, multiple currents contribute to the ground noise. Quickest is the input buffers - with low injected currents, but soonest arrivals. Then the internal AND/OR/FF logics current injections appear, and lastly, the output currents, and any load C they drive. Most vendors 'Z' PLDs achieve the low Icc, by fast wakeup of a 50-100mA 'core', so have inbuilt ground bounce generators (!), and are the most intolerant of slower edges. I have also seen erratic effects, on PLDs where the CLOCK line is very fast/clean, but other ( non dependant ) inputs are slower ( eg optocouplers ). As there is no logic coupling, this effect is due to buffer Oscillations, within the device. These can, in theory, be > 1GHz, and only need enough energy to disturb the GND metalisation voltage... Hysteresis eliminates the transistion oscillation effect, and if the Vh > ground bounce, can allow any rise times to be tolerated, while also reducing the overall current drain. -jgArticle: 13878
No guarantees, but it should be possible with the XC4000 device in 'slave serial' mode. The EPC2 has an on-chip oscillator as the Altera Flex10K devices have no oscillator and therefore no 'master serial' mode. The serial config mode of the Altera Flex10K is similar to the XC4000 slave serial mode. Marc Levy Carl R. Poirier wrote in message <75ato5$g0q$1@news.kodak.com>... >I looking into loading an Altera EPC2 with configuration data for a Xilinx >XC40xx. Does anyone know if this is possible? > >I'm interested in the ISP capability of Altera's EPC2 using the JTAG bus, >but I'm using Xilinx XC40xx devices. I need the ability to reload the >configuration EPROM using only the JTAG port. > >Thanks, Carl Poirier >Eastman Kodak >Electronic Products >Design for Testability > >Article: 13879
No, because its effect will be blocked by the other logic. Only one D-type at any one time will see it. >But if the same input can do this in more than one place in the >sequence of states then it may still be controlling more than one >state ff -- 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: 13880
>Let us know if your 1 : 1 million error rate then goes away. No errors yet, after some 40-50 hours. Looks like the *AMD* 22V10 was very dodgy. Anyway as I said I will sync it for good measure, esp. as my i/p Tr is 50ns and the spec on the Philips P3Z22V10 is 20ns max. >The ATMEL ATFV750C is due out early Q1 99 :-) >( Its on our programmer menu now ) Which programmer? >This is 3.3V, is 22V10 compatible, and has 10 more FF's, >for a lot more 'elbow room' on syncronisers, or one-hot-bit state >machines... Well, if Lattice ever did a full-*CMOS* version of their ancient 39V18, a.k.a. GAL6001, none of this would be needed. Every half-good PLD compiler of the past 10 years supports the 6001. The 22V10 pin compatibility is handy though. >I have seen, and used, a trick that GATE-Latches the Async IN, with the >CLOCK, so that it cannot change in the half clock prior to the active edge. >This avoids nasty 'aperture effects' of a signal that straddles the >CLOCK edge. >It also introduces only a half cycle of pre-sample delay.. I think you are referring to the ability to build a S-R latch within the product matrix, but I think this still uses up at least one output pin. Details please? I once learnt a wonderful trick, involving the creation of a "clock-enable" function, which almost gives you separate clocks - something badly missing in most GALs. >CUPL also has a MIN keyword, that allows override of the LOGIC MIN used, >within CUPL. >( MIN Counta.d = 4; /* level 4 reduction */ ) etc >It is possible that fiddling with this, on your state engine, could >produce equations that both FIT inside the 22V10, and meet the >requirement of a single term -> State transistion Yes, I discovered this too. Unfortunately it doesn't do it, because a "zero level" minimisation chucks in a load of zero (empty) terms, and these overflow the product term limit. Stupid program. The next smallest minimisation is what I already use. Obviously there is a way around this, either typing it all in by hand, or hacking the CUPL-generated .doc file to edit the dodgy terms. But my problem is that I am in a "long term" business and often have to revisit designs after some years. (Being my own business I don't have the option of walking away from everything I have done every year or two). So I try really hard to make very project so it is fully automated so I just change to the relevant directory and type MAKE. -- 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: 13881
> I developed assembly code for a micro controller to prototype a design. I >also have the program flow chart for the design. How do I go from the program >flowchart to a state diagram so that I can implement the design in an FPGA ? You will get many replies, but basically you need to draw your state diagram, then enter it in the language of some program which can convert it into an FPGA netlist, then compile it into the FPGA vendor's netlist format. How much money do you want to spend? I have done this with CUPL, outputting PALASM format, then used PDS2XNF.EXE, then XNFOPT.EXE to convert to Xilinx XNF netlist format. One could simulate, etc, in Viewlogic. This is a very old way to do it though. Today, a much more popular way to do this would be to use VHDL. I don't know if there is a really cheap route from VHDL to XNF; certainly there never used to be in the past. I know Cypress do a cheap VHDL kit for *their* CPLDs but those devices covered by that kit might not be big enough for what you want. Once you have the XNF netlist then you can use Xilinx's place & route tools to generate the config stream for the chosen Xilinx device. Alternatively, if the state machine is simple, you could design it by hand as a schematic, or even (if you are a masochist) as a netlist directly. Xilinx now offer some cheap starter kits. > Also, in my micro controller prototype, I used analog peak detectors(have >capacitors in them) as sensors. When I move the design to an FPGA, I would >like the entire design to be digital so that it can be easily integrated into >an ASIC. Does any one have any experience with designing digital peak >detectors ? (ie. No capacitors). I have some ideas, but would like to hear >about some proven designs. I don' think this is possible. You would need an A-D converter, then some logic to sample the values, compare with previous highest and retain the value if higher than previous. Not a big deal but not completely trivial either. -- 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: 13882
So why did xilinx say us we needed Xilinx Foundation and Xilinx Alliance and asked us to PAY for both? Michel. Mike Peattie wrote: > Actually, there is the Design Manager executable bundled with Foundation. You > just need to do > Start->Programs->Xilinx Foundation Series-> Accessories-> then Design Manager. > Alliance isn't required- you just need to bypass the front end tools. > > Mike Peattie > > Le mer Michel wrote: > > > 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: 13883
"Bruce Nepple" <brucen@imagenation.extra.com> writes:
> Yes Yes Yes. You got it! I challenge anyone here to come up with a gray
> code state machine that can reside in state A and conditionally branch to
> either state B or State C based on an async. input.
I can't think of one. But you added yet another requirement to Peter's
list. With thse requirements, one should be safe.
> "Having spent untold hours at analyzing and measuring metastable
> behavior, I can assure you that it is (today) a highly overrated
> problem. You can almost ignore it."
> Peter Alfke
> 12/28/98
Are you going to hold it to him? :-)
--
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: 13884
ems@riverside-machines.com.NOSPAM writes:
> On 29 Dec 1998 17:23:25 +0100, Magnus Homann
> <d0asta@mis.dtek.chalmers.se> wrote:
> > 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.
>
> Sure, but my point is that a problem can only occur when the async
> input is changing. If the input is changing, then it doesn't matter
> whether the f/f decides to settle to 1 or to 0 - either the f/f gives
> us the new value of the input, or the old value. Both are ok, and so
> hazards on the input don't matter *when you've only got one f/f*.
The problem in Peter's SM was, that the old value was the same as the
new value. The same value should come out of the comb logic,
regardless of the async input. In that case, it is not true that both
values were OK. Getting a glitch seriously disrupts the SM.
[ alot snipped]
> Ok, I'm sure you're right when you say that you can make this case
> work by removing the hazards, but I don't think that this is a
> practical solution in general (and what if your machine has more than
> one state exiting from the sample state?
I agree completely. I would have synchronized the input as the very
first step.
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: 13885
rk <stellare@NOSPAMerols.com> writes:
> sorry, bit of a disagreement here in definitions. i actually went
> back and re-read a bunch of my logic books. gray codes, as it turns
> out, are not tied to flip-flops, but to a sequence of numbers.
Yes, you are right abot this. It's not tied to any sort of
implementation.
> again, let me repeat, if you sample something that has more than one
> bit changing at a time you are not sampling a gray code sequence and
> it's a bad circuit.
[...]
> now, of course it is common to think of a sequencer using a gray
> coded sequence (which is what you are referring to).
Yes, gray coded state machines has been the subject of this thread.
> these can be
> very handy and i use them all of the time. they have the very nice
> property that you can sample them any old time you want to,
> asynchronously, and only have small errors (where 1 is considered
> small).
Wait a second. You make the assumption that 'any old time' is more
often than the cray coded sequence change. What if it changes each
second, but you sample every 10 seconds. Is it still a gray code? I
think you make he hidden assumption, that only one bit changes
_between sampling_.
> i don't care if it's the output of a shaft encoder, an ADC, a
> combinational logic network, or a set of flip-flops. if the outputs
> when viewed with inifite time resolution do not glitch and only
> change one bit at a time in a gray code sequence you are in good
> shape (as long as you don't do anything really stupid).
With infininte time resolution? I challenged anyone to build a comb
logic that changes more than 1 bit per ps. You do mean change 1 bit
per samlping, donät you? That's what you say elsewhere in your post.
The glitch, on the other hand is more important. Even gray coded SM
can have glitches in their comb. logic.
> if multiple
> bits are changing, you are not sampling a gray code sequence and you
> have a bad circuit. which is why the original posters circuit most
> probably failed.
> > > these are safe to sample asynchronously assuming that after
> > > sampling the flip-flop outputs are allowed to settle to avoid metastability
> > > problems before being used in the next stage of logic. further, at most one
> > > of the flip-flops doing the same can go metastable, since by definition of a
> > > gray code, all the other bits are constant.
> >
> > Only one bit of the state registers change at the same time, but
> > which? Both 00 to 01 and 00 to 10 are legal transitions in a gray coded
> > SM, but logic hazard can make you take the 00 to 11 transition, which
> > is illegal. Ergo, your SM isn't fool proof for asynch inputs.
>
> sorry, you can't have it both ways. if you have a logic hazard in
> the combinational network, then the input to the registers isn't
> guaranteed to have only 1 input changing at a time,
There is no such thing as simultaneous changes. No two bits in a
comb. logic can change at the same time. What is your implied
timing ref. here?
> so you are not
> sampling a gray coded sequence, so the circuit will fail. you are
> not describing my SM, but a poorly designed one.
On the example above, the comb logic is a gray coded sequence. First
it's "00", then it is "01", then 100 ps later it is "11", then 100ps
later it is "10". A gray coded sequence. Unfortunately, the SM clock
decides to sample this gray coded sequence, at the time it's "11". So
it takes an illegal jump.
That the SM is gray coded doesn't necessarily mean that the comb logic
in front of it is free from glitches. See Peter's example.
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: 13886On 31 Dec 1998 12:21:34 +0100, Magnus Homann <d0asta@mis.dtek.chalmers.se> wrote: >> Sure, but my point is that a problem can only occur when the async >> input is changing. If the input is changing, then it doesn't matter >> whether the f/f decides to settle to 1 or to 0 - either the f/f gives >> us the new value of the input, or the old value. Both are ok, and so >> hazards on the input don't matter *when you've only got one f/f*. > >The problem in Peter's SM was, that the old value was the same as the >new value. The same value should come out of the comb logic, >regardless of the async input. In that case, it is not true that both >values were OK. Getting a glitch seriously disrupts the SM. good point - agreed. evanArticle: 13887
On Wed, 30 Dec 1998 11:38:48 GMT, ems@riverside-machines.com.NOSPAM wrote: >does mentor own exemplar?? MGC's website describes exemplar as 'an >independent company'. Exemplar Logic's products, just like Model Technology's are available through the direct Mentor Channel to their direct customer base. For those unaware of recent movements within the EDA industry, this may help to draw some dots: http://www.mentor.com/press_releases/nov98/curtisvp_pr.html Cheers Stuart For Email remove "NOSPAM" from the addressArticle: 13888
z80@ds2.com (Peter) wrote: >No, because its effect will be blocked by the other logic. Only one >D-type at any one time will see it. Unless that 'other logic' creates a static hazard which is what I said the problem was? >>But if the same input can do this in more than one place in the >>sequence of states then it may still be controlling more than one >>state ff Cheers Terry...Article: 13889
I suggest to contact with israeli company called sumit-design they build a program that convert from state machine bubble diagram into vhdl code and backwards. best regards Peter wrote: > > I developed assembly code for a micro controller to prototype a design. I > >also have the program flow chart for the design. How do I go from the program > >flowchart to a state diagram so that I can implement the design in an FPGA ? > > You will get many replies, but basically you need to draw your state > diagram, then enter it in the language of some program which can > convert it into an FPGA netlist, then compile it into the FPGA > vendor's netlist format. > > How much money do you want to spend? > > I have done this with CUPL, outputting PALASM format, then used > PDS2XNF.EXE, then XNFOPT.EXE to convert to Xilinx XNF netlist format. > One could simulate, etc, in Viewlogic. This is a very old way to do it > though. > > Today, a much more popular way to do this would be to use VHDL. I > don't know if there is a really cheap route from VHDL to XNF; > certainly there never used to be in the past. I know Cypress do a > cheap VHDL kit for *their* CPLDs but those devices covered by that kit > might not be big enough for what you want. > > Once you have the XNF netlist then you can use Xilinx's place & route > tools to generate the config stream for the chosen Xilinx device. > > Alternatively, if the state machine is simple, you could design it by > hand as a schematic, or even (if you are a masochist) as a netlist > directly. Xilinx now offer some cheap starter kits. > > > Also, in my micro controller prototype, I used analog peak detectors(have > >capacitors in them) as sensors. When I move the design to an FPGA, I would > >like the entire design to be digital so that it can be easily integrated into > >an ASIC. Does any one have any experience with designing digital peak > >detectors ? (ie. No capacitors). I have some ideas, but would like to hear > >about some proven designs. > > I don' think this is possible. You would need an A-D converter, then > some logic to sample the values, compare with previous highest and > retain the value if higher than previous. Not a big deal but not > completely trivial either. > > -- > 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: 13890
Tharas Systems in San Jose, CA. is a well funded start-up developing a verilog simulator with an RTL hardware engine that will deliver 1000x the performance of current software verilog simulators. We have developed an innovative, patent pending hardware/software architecture to achieve this goal. Please see our website at http://www.tharas.com and the job description below: Principal Engineer – FPGA/Board/Systems Design Skills Required: MSEE or equivalent with 5+ years of experience designing Multiple Board / System Designs. High speed digital design and strong FPGA design background are essential. Must have experience using signal integrity analysis tools. Must have worked a design process from start to finish. Skills Desired: PCI experience and Chassis based systems design experience a plus. EDA background. Duties: Need individual contributor with very strong system design skills to design from start to finish a high speed chassis based multiple board digital system. You will work with the design process flow including schematic capture, timing analysis, BOM generation, fab and assembly. You will use your good problem solving skills and communication skills and work independently or with a small team. Thanks for any interest you may have and Happy New Year. Please contact: Margie Way Tharas Systems, Inc. 408-557-5324 408-557-5460 fax margie@tharas.com or hr@tharas.comArticle: 13891
Peter Alfke wrote in message <3689409A.9126686@xilinx.com>... >> 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 ! > So if a cross coupled latch with an input race condition can not oscillate, then it is a metastable free synchronizer and all the years of research and Xilinx app notes were wasted. Peter, I think you need to rethink a few things. Bruce "Having spent untold hours at analyzing and measuring metastable behavior, I can assure you that it is (today) a highly overrated problem. You can almost ignore it." Peter Alfke 12/28/98 "Having spend untold hours debugging digital designs, I can assure you that metastable behavior is a real problem, and every digital designer had better understand it" Bruce Nepple 12/31/98Article: 13892
happy new year! well, it'll be new year when the ball drops in times square, NY. now back to our favorite program ... rk ========================================== Magnus Homann wrote: > rk <stellare@NOSPAMerols.com> writes: > > > sorry, bit of a disagreement here in definitions. i actually went > > back and re-read a bunch of my logic books. gray codes, as it turns > > out, are not tied to flip-flops, but to a sequence of numbers. > > Yes, you are right abot this. It's not tied to any sort of > implementation. no problem - i think most internet disagreements are mostly over definitions and stuff like that. ------------------------------------------------------------------- > > again, let me repeat, if you sample something that has more than one > > bit changing at a time you are not sampling a gray code sequence and > > it's a bad circuit. > > [...] > > > now, of course it is common to think of a sequencer using a gray > > coded sequence (which is what you are referring to). > > Yes, gray coded state machines has been the subject of this thread. yes, although i had talked directly about gray codes and their use in asynchronous sampling. a very important destinction. a gray code sequencer is one whose state assignment results in a transition of states where the vectors form a gray code sequence. this is handy if the output of this machine is to be sampled asynchronously. on the other hand, if you have a state machine with gray code outputs whose input is asynchronous causing the next state equations to glitch, have logic hazards, etc., etc., then you just have a state machine that is poorly designed and will be error-prone. ============================================== > > > these can be > > very handy and i use them all of the time. they have the very nice > > property that you can sample them any old time you want to, > > asynchronously, and only have small errors (where 1 is considered > > small). > > Wait a second. You make the assumption that 'any old time' is more > often than the cray coded sequence change. What if it changes each > second, but you sample every 10 seconds. Is it still a gray code? I > think you make he hidden assumption, that only one bit changes > _between sampling_. no, multiple bits can change between sampling of a gray code as multiple states are passed through. in fact, this type of circuit makes very good use of the gray code. here are two examples, perhaps repeating myself from earlier posts, but hopefully we can get this down in one place and keep confusion to a minimum. assume that you have a rotating shaft with a position encoder. the shaft rotates at the rate of once per second and the position encoder has a resolution of 1024 positions. furthermore, electical contacts convert position into a binary word. as the shaft rotates, the output vector changes, well, 1024 times per second. now let us say that we attach an electrical detector of some sort to the shaft, which has an angular field of view of, say, 360/1024 degrees. let the shaft rotate around for hours if you wish, then when the big radar signal comes in, from one of our friends around the world, the detector puts out a nice big fat logic pulse. since these friends may, in fact, wish to send you a little ol' package, you may wish to know where they are. so, you take your nice logic pulse and then latch the output of the position encoder into a register. fortunately, your angular encoder puts out a gray code, so you know just about where they are, with respect to angle. "just about" means that your error is at most one unit of your resolution, in this case 1024th of a resolution. here's another case, a real one, although the numbers and scenario's are changed to make things simple. suppose you are up in space, just for kicks, and you shoot a laser beam straight down. well, as the laser hits stuff, you can get some light reflected back. in fact, if you put say a photomultiplier on your detector and appropriate pulse shaping electronics, you can get, say, a nicely formed pulse 20 nsec wide. furthermore, let's say that your detector+pulse shaping electronics has a pulse-pair resolution of 1 usec, so that you don't have to worry about insufficient clock low time, causing your flip-flops to go metastable. now, your friend, the guy who pays your salary, asks you to count the number of output pulses every 1 msec of clock time. you can then, if you know your altitude, convert your counts into a measure of what's in the atmosphere at different altitudes. this is important for a bunch of scientific reasons but you gotta get the right answer. well, take the output of the pulse detector and put it into the clock of a counter that goes through a gray code sequence. of course, this will not be a regular clock at all, but will be quite irregular, depending on what's at what altitude in the atmosphere, and within a band, will have arrival times that appear random, which is a separate topic. anyways, we know that the photomultiplier tube pulses will by asynchronous to your other counter, which counts off 1 msec intervals. but, since your counter (or state machine if you like) is going in a gray code sequence, you can simply latch the output of the counter (state machine) and have a very small error and shove the values into a fifo. no dead time on your detector, everybody's happy. later, you can do a gray => binary conversion and figure out what it all means. so no, there is no hidden assumption there of the kind you mentioned. =================================================== > > i don't care if it's the output of a shaft encoder, an ADC, a > > combinational logic network, or a set of flip-flops. if the outputs > > when viewed with inifite time resolution do not glitch and only > > change one bit at a time in a gray code sequence you are in good > > shape (as long as you don't do anything really stupid). > > With infininte time resolution? I challenged anyone to build a comb > logic that changes more than 1 bit per ps. You do mean change 1 bit > per samlping, donät you? That's what you say elsewhere in your post. yes, infinite time resolution means no glitches. some engineers take the approach that delays in these sort of devices should match reasonably well and that logic gates act as low pass filters. this statement was simply saying that i would not count on those things saving your hide. note earlier brief discussion about the modelling of delays in vhdl, which can either be transport or inertial, with inertial delays being the default. ================================================== > The glitch, on the other hand is more important. Even gray coded SM > can have glitches in their comb. logic. yes, but if you use the asynchronous input as the clock of the gray coded state machine, it's a don't care, as long as you don't do anything stupid. here, not stupid means that the pulse-pair resolution is greater than it takes for your glitchy logic to settle down. basic synchronous design practices, really, nothing special. if you choose to have a clock asynchronous to the input and then have the inputs go into the combinational logic, then you must ensure that your logic does not glitch and that it presents a gray code to the inputs of the d flip-flops, which samples them, which must be a gray code (or some code with similar properties like the output of a johnson ring counter) with only 1 bit changing per change in state. =================================================== > > > if multiple > > bits are changing, you are not sampling a gray code sequence and you > > have a bad circuit. which is why the original posters circuit most > > probably failed. > > > > > these are safe to sample asynchronously assuming that after > > > > sampling the flip-flop outputs are allowed to settle to avoid metastability > > > > problems before being used in the next stage of logic. further, at most one > > > > of the flip-flops doing the same can go metastable, since by definition of a > > > > gray code, all the other bits are constant. > > > > > > Only one bit of the state registers change at the same time, but > > > which? Both 00 to 01 and 00 to 10 are legal transitions in a gray coded > > > SM, but logic hazard can make you take the 00 to 11 transition, which > > > is illegal. Ergo, your SM isn't fool proof for asynch inputs. > > > > sorry, you can't have it both ways. if you have a logic hazard in > > the combinational network, then the input to the registers isn't > > guaranteed to have only 1 input changing at a time, > > There is no such thing as simultaneous changes. No two bits in a > comb. logic can change at the same time. What is your implied > timing ref. here? the timing reference for a state machine is the clock. the probability of two events occurring at exactly the same time is 0. but if you have multiple bits changing to the input of a real circuit, then you are, well, screwed, for this class of circuit. and that's why the static hazard must be eliminated. ============================================================ > > so you > are not > > sampling a gray coded sequence, so the circuit will fail. you are > > not describing my SM, but a poorly designed one. > > On the example above, the comb logic is a gray coded sequence. First > it's "00", then it is "01", then 100 ps later it is "11", then 100ps > later it is "10". A gray coded sequence. Unfortunately, the SM clock > decides to sample this gray coded sequence, at the time it's "11". So > it takes an illegal jump. no, this is not a gray coded sequence. this is simply a lousy circuit, most probably. if the circuit is glitching, through the sequence at 100 psec/glitch, "00" => "10" => "11" with a single state transition, you have a mess, not a gray code. for a gray code, you should change one bit per step. you are changing two bit, going from "00" to "11" and the circuit will fail. that's why they have gray codes which don't do that. if your transitions are really moving that fast, with 100 psec between transitions, then the circuit, using available PAL or FPGA logic will fail, as 100 psec is simply too fast. ====================================================== > That the SM is gray coded doesn't necessarily mean that the comb logic > in front of it is free from glitches. See Peter's example. a gray coded state machine is designed so that another register, run off a clock asynchronous to the gray coded state machine, can sample it asynchronously. the logic in a gray coded state machine can glitch as much as it wants, it's a don't care, as it only cares about what happens at the clock edge. if you choose to insert an asynchronous input into the combinational logic of a state machine, any state machine, then you can have problems, irregardless of what the coding is. using a state machine whose sequence of states is a gray code (or any other code that you happen to choose) does not provide relief from the requirement that inputs obey the setup and hold times. standard logic design. =========================================================== > Homann rkArticle: 13893
Magnus Homann wrote: > > "Bruce Nepple" <brucen@imagenation.extra.com> writes: > > > Yes Yes Yes. You got it! I challenge anyone here to come up with a gray > > code state machine that can reside in state A and conditionally branch to > > either state B or State C based on an async. input. > > I can't think of one. But you added yet another requirement to Peter's > list. With thse requirements, one should be safe. > > > "Having spent untold hours at analyzing and measuring metastable > > behavior, I can assure you that it is (today) a highly overrated > > problem. You can almost ignore it." > > Peter Alfke > > 12/28/98 > > Are you going to hold it to him? :-) Hey! He did say "almost"!!! >:^) -- Rick Collins redsp@XYusa.net remove the XY to email me.Article: 13894
Bruce Nepple wrote: > Peter Alfke wrote in message <3689409A.9126686@xilinx.com>... > > So if a cross coupled latch with an input race condition can not oscillate, > then it is a metastable free synchronizer and all the years of research and > Xilinx app notes were wasted. > Peter, I think you need to rethink a few things. > > Bruce > > "Having spend untold hours debugging digital designs, I can assure you that > metastable behavior is a real problem, and every digital designer had better > understand it" > Bruce Nepple > 12/31/98 The year comes to an end, but this thread goes on. I never said that metastability does not exist. I have measured it. It does exist, but the recovery delay from the metastable (=balanced) condition to the ultimately stable state is so short in modern CMOS latches and flip-flops, that the problem has lost most of its impact. I have published numbers that have never been challenged, and these numbers prove my point. The contentious question here is not metastable recovery, but oscillations. This is what I e-mailed recently to Bruce: If each NAND gate is a single-stage circuit with a 6-dB per octave gain roll-off, then cross-connecting two of them will never generate an oscillator. If, however, each NAND gate ( really an inverter once the common input is brought High) is a multi-stage circuit, which, in linear terms, means a faster roll-off in gain, and thus an additional phase lag at high frequency, then the cross-connection might, at a certain frequency, have a total phase lag of not 360 degrees ( 2 inverters ) but 720 degrees ( or even 1080 degrees) and also a gain of at least 1 at this frequency. That circuit can thus oscillate at the frequency where the additional phase lag is 360 ( or n times 360 degrees). Call that a marginally stable ring oscillator. In my defense I can say that nobody should build a latch this way, and no modern latch or flip-flop would show this behavior. We always make sure that the feedback loop is as tight as it possibly can be made, thus avoiding the situation I mentioned. It would be interesting to configure a perverse latch in an FPGA, with several or even many stages of gain inserted in the feedback loop, and then carefully try to make it oscillate. FPGAs are wonderful toys to explore this. No breadboard, no wire-wrap, no mess. So I now claim: 1. A modern CMOS latch can go metastable, but recovers so fast that the problem is, in most applications, irrelevant. ( see curves in the Xilinx data book, page 13-49 ) 2. A modern CMOS latch cannot be made to oscillate while its control inputs are stable. 3. A latch with multiple ( or many ) additional stages in its feedback loop can ( most likely) be made to oscillate. Can we agree on that? Happy New Year! Peter Alfke, speaking for himself.Article: 13895
Bruce Nepple wrote: > Peter Alfke wrote in message <3689409A.9126686@xilinx.com>... > > So if a cross coupled latch with an input race condition can not oscillate, > then it is a metastable free synchronizer and all the years of research and > Xilinx app notes were wasted. > Peter, I think you need to rethink a few things. > > Bruce > > "Having spend untold hours debugging digital designs, I can assure you that > metastable behavior is a real problem, and every digital designer had better > understand it" > Bruce Nepple > 12/31/98 The year comes to an end, but this thread goes on. I never said that metastability does not exist. I have measured it. It does exist, but the recovery delay from the metastable (=balanced) condition to the ultimately stable state is so short in modern CMOS latches and flip-flops, that the problem has lost most of its impact. I have published numbers that have never been challenged, and these numbers prove my point. The contentious question here is not metastable recovery, but oscillations. This is what I e-mailed recently to Bruce: If each NAND gate is a single-stage circuit with a 6-dB per octave gain roll-off, then cross-connecting two of them will never generate an oscillator. If, however, each NAND gate ( really an inverter once the common input is brought High) is a multi-stage circuit, which, in linear terms, means a faster roll-off in gain, and thus an additional phase lag at high frequency, then the cross-connection might, at a certain frequency, have a total phase lag of not 360 degrees ( 2 inverters ) but 720 degrees ( or even 1080 degrees) and also a gain of at least 1 at this frequency. That circuit can thus oscillate at the frequency where the additional phase lag is 360 ( or n times 360 degrees). Call that a marginally stable ring oscillator. In my defense I can say that nobody should build a latch this way, and no modern latch or flip-flop would show this behavior. We always make sure that the feedback loop is as tight as it possibly can be made, thus avoiding the situation I mentioned. It would be interesting to configure a perverse latch in an FPGA, with several or even many stages of gain inserted in the feedback loop, and then carefully try to make it oscillate. FPGAs are wonderful toys to explore this. No breadboard, no wire-wrap, no mess. So I now claim: 1. A modern CMOS latch can go metastable, but recovers so fast that the problem is, in most applications, irrelevant. ( see curves in the Xilinx data book, page 13-49 ) 2. A modern CMOS latch cannot be made to oscillate while its control inputs are stable. 3. A latch with multiple ( or many ) additional stages in its feedback loop can ( most likely) be made to oscillate. Can we agree on that? Happy New Year! Peter Alfke, speaking for himself.Article: 13896
Peter, you seem to be missing the point which is that the cross coupled latch, as I described it, will oscillate, illustrating the effect which causes metastability. You claim that model is bogus. You are incorrect. I feel compelled to continue this thread because it is such a good example, and you dismissed it out of hand. I wish we could spend 15 minutes at a blackboard. Just to be sure there is no mis-understanding, I describe this "ideal" latch as follows: 2 nand gates with 1 ns prop delay and 0 ns. rise/fall time, are connected as a simple RS latch. The R and S inputs are connected together. Initially they are connected to ground, and then are brought to logic 1. The ideal latch then oscillates forever (as a digital ring oscillator). Your talk about linear oscillators is completely irrelevant. A looped digital delay line can oscillate for a while if you inject a short pulse, and it has no gain. Saturated digital logic is a different animal with regard to prop. delays. There is no need to reply further if you cannot answer this 2 part question: If a cross coupled latch does not go unstable when there is a race on its input, then why is it not, then, a metastable free synchronizer? (which according to theories I am familiar with, is impossible). If your answer is that metastability is different, please, then, what model do you use to explain how metastability occurs in a simple cross coupled latch? To simply dismiss my example as "bogus" without offering up the "real" model is a cheap shot. BruceArticle: 13897
I once ran some experiments on 74S74 flip flops to determine the extent of
their metastable behavior. There was some difference from vendor to vendor
and part to part, but it was worthwhile to characterize what might be a
reasonable settling time. If you have the time, it would be educational to
duplicate what I did. I essentially built a 2 stage synchronizer with
clocks driven from two identical Schmidt triggers. The input to one of the
schmitt triggers was delayed slightly by an RC network (variable R, small
C). The delayed circuit drove the second flop. I could adjust the R until
I saw unstable behavior on the output of the second flip flop. (the first
flop should be connected to toggle).
osc ----schmitt ----schmitt ----first flop clock
|--schmitt--RC--schmitt ----second flop clock
Still have some pretty neat pictures of flip flop outputs pulsing high then
low after the clock. It was amazing how accurately I needed to adjust the
delay. I expect it will be even harder now-a-days. Also, the difference
between low to high D and high to low D was dramatic.
Bruce
.extra blows away the email
Tom Bruhns wrote in message <76biho$lhj@hpcvsnz.cv.hp.com>...
>
>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.com
Article: 13898hi bruce, i ran similar experiments about 15 years ago using 54lsxx technology, since that's what we were using for the most part. i don't have the scope photos (perhaps packed away somewhere else wheere i can easily find them :-) but remember that an output would go to one state and then back to the original one; the complement didn't move, iirc. i never saw an oscillation and tried hard to tweak it to get one or to get a non-logic level, which i didn't see either. like your experience, it was a tough tweak to get it to go metastable. perhaps i'll build another set with the stanford digital delay generator (it's the '90s, got digital tweakers now), see what happens with more modern flip-flops like the 74ac74. happy new year! rk ================================== Bruce Nepple wrote: > I once ran some experiments on 74S74 flip flops to determine the extent of > their metastable behavior. There was some difference from vendor to vendor > and part to part, but it was worthwhile to characterize what might be a > reasonable settling time. If you have the time, it would be educational to > duplicate what I did. I essentially built a 2 stage synchronizer with > clocks driven from two identical Schmidt triggers. The input to one of the > schmitt triggers was delayed slightly by an RC network (variable R, small > C). The delayed circuit drove the second flop. I could adjust the R until > I saw unstable behavior on the output of the second flip flop. (the first > flop should be connected to toggle). > > osc ----schmitt ----schmitt ----first flop clock > |--schmitt--RC--schmitt ----second flop clock > > Still have some pretty neat pictures of flip flop outputs pulsing high then > low after the clock. It was amazing how accurately I needed to adjust the > delay. I expect it will be even harder now-a-days. Also, the difference > between low to high D and high to low D was dramatic. > > Bruce > > .extra blows away the email > > Tom Bruhns wrote in message <76biho$lhj@hpcvsnz.cv.hp.com>... > > > >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: 13899
In a previous article "Bruce Nepple" <brucen@imagenation.extra.com> writes: ;If a cross coupled latch does not go unstable when there is a race on its :input, then why is it not, then, a metastable free synchronizer? (which ;according to theories I am familiar with, is impossible). Metastable does not equate oscillation. When output stays in the illegal region for an extented period of time, even if it is not oscillating, it is still called metastable. Oscillation-free synchronizer does exist and is being used in many places.
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