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
Magnus Homann wrote: > 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. i think there is a bit, well, over-forced. :-) let us assume that IN=0 and that Q=00. then the combinational logic will be outputting 10, ready to be clocked in on the next rising edge of the clock. now if you change IN to be a 1, at an inconvenient time, like when the clock is transitioning, then according to your logic description two outputs of the combinational logic will be changing, from 10 to 01, which can cause an error. of course, if a single input causes two bits of the output to change, it's not a gray code. by the definitions of a gray code that i have read, only a single output may change at a time. 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. =============================================================== > Homann thanks, have a nice evening, rkArticle: 13851
>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. I agree with the above, where an input of 0|1 can select either of two next states. However, if an input of 0|1 selected either the present state, or a next state, then a Gray code SM should be reliable, because only *one* D-type will ever be capable of acting on the changing input. If I am right then this is another thing to watch out for. -- 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: 13852
rk <stellare@NOSPAMerols.com> writes:
> let us assume that IN=0 and that Q=00. then the combinational logic will be
> outputting 10, ready to be clocked in on the next rising edge of the clock.
> now if you change IN to be a 1, at an inconvenient time, like when the clock
> is transitioning, then according to your logic description two outputs of the
> combinational logic will be changing, from 10 to 01, which can cause an
> error.
Yes, exactly.
> of course, if a single input causes two bits of the output to change,
> it's not a gray code.
See below.
> by the definitions of a gray code that i have read, only a single output may
> change at a time.
No, the thing is that only one of the _state bits_ can change at any
_state change_. That's the definition. It doesn't say anything about
the combinatorial logic in front of the state bits. It doesn't say
anything about the outputs, it could be a Mealy machine for instance.
I think you are mixing outputs from the state machine with the logic
computing next state.
If indeed you have a clear ref. handy, look it up and let me know
what it says. I'm still doing this from memory.
> 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.
> have a nice evening,
Night, really. It's 2330 :-)
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: 13853Hi All, I am currently doing a design with the Virtex XCV300 part and wanted to get a first order of power consumption estimation on this part. Is there any easy way to do this? TIA, David TangArticle: 13854
Magnus Homann wrote: > rk <stellare@NOSPAMerols.com> writes: > > > let us assume that IN=0 and that Q=00. then the combinational logic will be > > outputting 10, ready to be clocked in on the next rising edge of the clock. > > now if you change IN to be a 1, at an inconvenient time, like when the clock > > is transitioning, then according to your logic description two outputs of the > > combinational logic will be changing, from 10 to 01, which can cause an > > error. > > Yes, exactly. > > > of course, if a single input causes two bits of the output to change, > > it's not a gray code. > > See below. ok ================================================= > > by the definitions of a gray code that i have read, only a single output may > > change at a time. > > No, the thing is that only one of the _state bits_ can change at any > _state change_. That's the definition. It doesn't say anything about > the combinatorial logic in front of the state bits. It doesn't say > anything about the outputs, it could be a Mealy machine for instance. 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. they can come out of a mechanical shaft encoder, as i've stated before. see, for example, _analysis and design of digital circuits and computer systems_, p. chirlian, pp. 336-339. they show the example where the code is nothing more than the output of a set of brushes on a wheel. the codes advance as the mechanical shaft turns. nothing at all to do with flip-flops. since the output is a gray code, only one bit can change at a time and thus the error is small. if you choose to replace the nicely fabricated wheel (which outputs a gray code sequence when a input is applied) with an electrical network which does not share the property of changing only one bit at a time, then the output will no longer be a gray code, the flip-flops will sample a set of values where more than one value can change at a time, and the circuit can have large errors. _digital logic and computer design_, m. morris mano, p. 19-20, has the same definition as chirlian, gray codes are not tied to state machines at all; indeed they are introduced before flip-flops are discussed . they also discuss how it is used to sample analog systems to keep the errors low. _switching theory and finite automate theory_, kohavi, pp. 12-14 again discuss the codes without regard to state machines. the sequence of words have certain properites and they discuss cyclic and reflected codes. i could go on and on but it would be a waste of time. 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. since this thread is going to idiotsville, perhaps you can simply demonstrate the following: sample a set of n values, only one of which is changing at a time, and you have multiple bits in error. ====================================================== > I think you are mixing outputs from the state machine with the logic > computing next state. sorry, nope, i'm confusing nothing. basic logic. ======================================================= > If indeed you have a clear ref. handy, look it up and let me know > what it says. I'm still doing this from memory. i did at first and then i listed some references above. now, of course it is common to think of a sequencer using a gray coded sequence (which is what you are referring to). 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). however, these will not be constructed in the manner in which the original poster constructed his state machine where the next state inputs are a function of the asynchronously changing input, which is a bad circuit. in this case, the next state inputs will be ONLY a function of the current state inputs and the asynchronous signal will be the clock. here's how this circuit is used. suppose you have to count event which occur randomly and the event pulse you get is well formed; i.e., sufficient pulse width to clock your flip-flops and enough dead time between flip-flops so that you do not violate the tlow time of your flip-flops. (or course, with random events you can not guarantee that, but the pulse conditioning circuitry ahead of the gray coded counter takes care of it for you, which is why we still need analog engineers or peter a.'s 1 GHz fpga). now the state machine will count through the gray coded sequence just fine and will never have an error. let's say the system needs to collect the counts at 1 usec intervals. obviously this is asynchronous to the gray coded state machine. will it work? yes, of course it will, because ONLY 1 INPUT TO THE SAMPLING REGISTER IS CHANGING AT A TIME BECAUSE IT'S A GRAY CODED SEQUENCE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! if you would have happenned to use a binary counter to count events, or perhaps a ripple counter, then you got a mess. the important principle here is that when you sample multiple bits asynchronously, it can be done reliably, but only if you sample a gray coded sequence, which means that only one bit is changing at a time. 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). 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, 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. i've said this a bunch of times, perhaps you should go back and read it a bit more slowly. ================================================================ > > have a nice evening, > > Night, really. It's 2330 :-) sorry, NY is center of universe, it's night time :-) rkArticle: 13855
Peter Alfke wrote: > 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. please see explanation to this given in another post. ======================================== > 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. exactly. if more than one input is changing, it's not a gray code, and will obviously be a poor circuit and will fail. ======================================== > All the other dozen responses make for interesting reading, but I am > pretty sure that this example here explains the real root cause. yes, if you sample an input vector where multiple bits are changing at once, for whatever reason (in this case a logic hazard), the circuit will fail. =========================================== rkArticle: 13856
rk wrote: > i think there is a bit, well, over-forced. :-) > > let us assume that IN=0 and that Q=00. then the combinational logic > will be > outputting 10, ready to be clocked in on the next rising edge of the > clock. > now if you change IN to be a 1, at an inconvenient time, like when the > clock > is transitioning, then according to your logic description two outputs > of the > combinational logic will be changing, from 10 to 01, which can cause > an > error. of course, if a single input causes two bits of the output to > change, > it's not a gray code. > > by the definitions of a gray code that i have read, only a single > output may > change at a time. Let me disagree.Magnus brought up this beautifully simple example:The circuit is supposed to transition from 00 to 01 when control is a 1, but to transition from 00 to 10 when control is a 0. That is a legitimate Grey-coded state machine with only one bit changing when everything goes nicely and synchronously. But when the control input changes asynchronously, then the two flip-flops might interprete the control differently ( because of routing delay differences, set-up time differences, etc) So the output might actually change directly from 00 to 11, because the left flip-flop caught control =0, while the right flip-flop caught control =1. Bye-bye Grey code. Peter Alfke, Xilinx ApplicationsArticle: 13857
I think you better look at the examples again. They will oscillate. We can continue from there via email if you'd rather. (remove .extra to email) 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 Peter Alfke wrote in message <3689409A.9126686@xilinx.com>... >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: 13858
Snip
>> 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 !
Not always true (see below)!
>
>> 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.
Actually: way (see below)
>
>> 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
Sorry but this is not true. Try it and you will *probably* never see it
oscillate. However, it is possible for oscillation to persist forever
(or 15 minutes which is close enough) with two cross coupled inverters.
If you insist I will dig out
a photograph/reference, scan it and post to this group.
Of course if your circuit/model for an inverter is nice and simple
with a single pole it will not oscillate. Real circuits can be more
complex although CMOS comes pretty close to the single pole model.
TTL inverters do not come close to a single pole simple model.
Regards,
Fred
Fred U. Rosenberger fred@ee.wustl.EDU
Institute for Biomedical Computing http://www.ibc.wustl.edu/~fred
Washington University Voice: (314) 362-3124
700 S. Euclid Ave. Fax (e-mail preferred):
St. Louis, MO 63110 (314) 362-0234
GPS: N38 38.038' W90 15.769'
Article: 13859Hi - On Tue, 29 Dec 1998 12:50:51 -0800, Peter Alfke <peter@xilinx.com> wrote: >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 ! Actually, sometimes cross-coupled NAND gates can oscillate. Take a look at "Anomalous Behavior of Synchronizer and Arbiter Circuits," a paper written by two metastability demi-gods, Thomas Chaney and Charles Molnar, in the April, 1973 IEEE Transactions on Computers, p. 421. Chaney and Molnar show scope plots of what happens when cross-coupled NAND gate latches built out of SN7400 logic either (a) are hit with a runt pulse on one of the inputs or (b) have both S and R inputs raised from LOW to HIGH simultaneously. In both cases, the outputs oscillate (in phase) for a few cycles, then assume a HIGH or LOW value as they fall out of the metastable state. The authors' claim is that this behavior is more common in gates whose prop-time-to-output-transition-time ratio is high, so I doubt you'd see this behavior inside an FPGA or CPLD. I've never observed this phenomenon myself, but have seen it reported in other articles, too. Bob Perlman Cambrian Design WorksArticle: 13860
On Sun, 27 Dec 1998 20:19:39 GMT, z80@ds2.com (Peter) wrote: >I have an 8-state state machine (fully encoded, not one-hot). It has >only *one* input that ever changes. The states are Gray-coded so that >when transitioning from one state to another, only *one* D-type >changes state. > >This is standard stuff which I have been using for > 10 years, with no >problems, with various PLDs from a 16V8 to an XC3090. I am using CUPL. > >Now I am using an AMD PALCE22V10-15 (3.3 volt) and it is jumping >illegally from state 100 to 001, in response to a single async input. >The only next state should be 101. > >The clock is just 1MHz. I just sat down and read the whole of this thread - good stuff, ought to be required reading for all my digital design students - and I don't think I have anything to add to what's already been said by numerous people whose opinions and skills I've learned to respect. But there is one other point worth noting, which has only been mentioned in passing. I guess it's not the problem here, since we are talking about experienced engineers and not newbies, but it might be worth saying.... 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 terrible problem if the outputs see capacitive loads - even 100pF can be enough to cause real trouble, I've found. Lattice's GALs seem to be particularly troublesome in this regard. The FPGAs I've used seem much better - I suspect the device designers were well aware of the problem of lots of outputs switching simultaneously, and took steps to control output dI/dt. The cynic in me suspects that the fast GALs get some of their datasheet-headline speed from their ill-disciplined and excessively brutal outputs. A quick way to find whether this is a problem, especially since your clock is so slow, is to add about 1k in series with the clock pin, right next to the device. Note that changing the frequency of the clock has no effect. On a 4-layer board, with good layout practice, this is probably NOT the problem. But it is very hard to spot if you aren't ready for it, and it is a problem that's very strongly dependent on what sort of device you use (how big a dI/dt can the outputs create?) and on small details like the size of capacitive load on the outputs. Even the presence or absence of a scope probe on an output can be relevant! Just my 2p-worth (Britain won't have the euro for a while yet...) Jonathan BromleyArticle: 13861
Ray Andraka wrote: > Comp.arch.fpga FAQ > > Q: Is there a FAQ for comp.arch.fpga? > A: This is it. > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email randraka@ids.net > http://users.ids.net/~randraka Good start keep it up:) -- Steve Casselman, President Virtual Computer Corporation http://www.vcc.comArticle: 13862
Tom Lane wrote: > > 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 laneyes, it is obvious that you can take a fixed-point dct and synthesize the mults into a series of shifts and adds. what i meant was "to come up with a few number of shifts and adds".. the objective is to keep the op count reasonable. that is why i claim that if one uses a efficient mult. free dct (say something that does a 8x8 dct in 400 ops) it is unlikely that this dct will pass the IEEE dct accuracy test (atleast i have not seen anything published in any ieee journal on mult. free dcts that achieves this for reasonable op count).Article: 13863
Peter wrote in message <368a2e45.96017826@news.netcomuk.co.uk>... > >>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. > >I agree with the above, where an input of 0|1 can select either of two >next states. > >However, if an input of 0|1 selected either the present state, or a >next state, then a Gray code SM should be reliable, because only *one* >D-type will ever be capable of acting on the changing input. > >If I am right then this is another thing to watch out for. > > 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. Cannot be done without changing 2 D-inputs at once, in which case you are not sampling a gray code sequence, and it will fail. All you can do is stay in state A or advance to state B based on the async input. You can build a safe gray code counter with an async. count enable, but that is about all it will ever be. 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/98Article: 13864
>>>>>>>>> Lucent SPAM deleted by Archive OwnerArticle: 13865
On 29 Dec 1998 17:23:25 +0100, Magnus Homann <d0asta@mis.dtek.chalmers.se> wrote: >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? :-) I'll try to present a minimal target... :> >What do you mean by a "synchro"? Never heard that term before. Just shorthand for 'synchroniser'. > 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*. >[...] >> 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. Yes, but they'd only be at the input to *one* f/f, so the hazard/s wont matter. >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. True, so what you're saying is that if you're careful with your design, then you *can* sample an async input in different f/fs, as long as you're certain that the samples don't occur on the same clock edge. But then you have to make certain that you don't have any hazards, so you have to design your machine by hand.... but why bother? If you only sample in one f/f, then you're *guaranteed* that you won't get any problems, and you don't have to do any hazard analysis. >> 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. 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? In this case, there are at least two f/fs sampling the async input on the same clock cycle, and hazard analysis won't help). one f/f per async input seems a lot cleaner to me. But if Peter can't recode his machine cleanly, then perhaps it's the only option (apart from using an external synchro, of course). EvanArticle: 13866
Stuart Clubb wrote in message <36894c5d.1727921@nntp.netcruiser>... >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 would suggest upgrading to Foundation 1.5. You could use Active-VHDL 3.2 directly from the flow ( in the similar way as a gate level simulator) More information you can find on website www.aldec.com http://www.aldec.com/activevhdl/html/XLX_FND_AVHDL.pdf 'Using Active-VHDL Simulation with Xilinx Foundation 1.5' > >>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. There are two libraries: UNISIM - used for functional and post-synthesis simulation SIMPRIM - used for timing simulation Both libraries are included to Active-VHDL 3.2 install. They are compiled so all you have to do is adding the appropriate library declaration in your VHDL code. (Foundation export to VHDL can do it automatically, this can be set in a xilinx.cfg file located in the VHDL subfolder, if you have any questions about it let me know: grzegorza@aldec.com ) > >>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. > Yes, Active-VHDL works in a similar way. You need both time_sim.vhd and an SDF file. You can find more details in the above mentioned pdf document. >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)Article: 13867
On Tue, 29 Dec 1998 21:49:25 GMT, s_clubb@NOSPAMnetcomuk.co.uk (Stuart Clubb) wrote: >3 - Synthesis > Leonardo Spectrum (MGC) does mentor own exemplar?? MGC's website describes exemplar as 'an independent company'. a couple of things to add: >> Now I am thinking of using mentor leonardo to synthesis it good >> and function simulate it bad - it's not a simulator >> and then generate EDIF file. Export it to xilinx foundation, >> and then do programming and timing verify. good >> But, how to do timing verify just with a EDIF file? leonardo/spectrum produce an EDIF (or XNF) file and, optionally, a xilinx constraints file. foundation implements the design, and can carry out a *static* timing analysis on the design. foundation will also optionally produce an SDF (standard delay format) file. this contains timing information which can be used by a vhdl or verilog simulator, for timing simulation. >> And, can I do the whole thing with mentor? with timing simulation and back >> annotation? the short answer is no. you'll need to buy a VHDL simulator, which must be VITAL-compliant. the long answer is maybe. if you pay enough for spectrum, it will read in the SDF file produced by foundation, and you can then use the schematic viewer option, which will report on timing delays from point A to point B. i believe (but i haven't tried this) that it will also use the SDF information to verify any timing constraints that you originally entered into spectrum; in other words, it will do static timing analysis for you. if your budget is limited, i'd suggest: 1) get foundation, with the cheap synthesiser (a cut-down version of synopsys's FPGA express) 2) spend your money on a VITAL-compliant simulator (you can't go wrong with modelsim, but there are cheaper ones) 3) if you've got any money left over, you can think about buying a better synthesiser, such as spectrum. evanArticle: 13868
Thanks. I found some samples. Seems there's an issue with the JTAG-based ISP. Supposed to be corrected by product release in late January (WW4). Regards, Carl Victor Snesarev wrote in message <3680EA3D.EEC791B1@nortelnetworks.com>... >Our Altera rep. at RTP, North Carolina will have samples available after >Christmas. > >There's also a data sheet on Altera's web site: > >http://www.altera.com/document/ds/dsconf.pdf > >Sorry, cannot comment on Xilinx application of that chip. > >Cheers, > >VictorArticle: 13869
George 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? > You can do a post-synthesis Fonctionnel gate level simulation according to the "Xilinx/Exemplar Large Device Design Methodology" application note : http://www.xilinx.com/apps/4000.html For a real timing simulation, you need the Alliance series Software from xilinx. Then, generate a file.vhd and a file.sdf with Alliance and import it to Modelsim (Mentor group). > Thank you very much! If you do the post-synthesis fonctionnel gate level simulation, let me know please. Good luck, good purchase. Michel. Michel Le Mer Gerpi sa 3, rue du Bosphore Alma city 35000 Rennes France.Article: 13870
This is a multi-part message in MIME format.
--------------FEC4E2A6DB089053FCD3A9BB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
CALL FOR PAPERS
SPIE's International Symposium on Voice, Video & Data Communications
19-22 Septmber 1999 - Hynes Convention Center -- Boston Massachusetts
USA
Reconfigurable Technology: FPGAs for Computing and Applications (VV03)
This is the Fourth Year of this Conference
On-site Proceedings. Abstracts for this conference are due by 8
February
1999. Manuscripts are due by 28 June 1999.
Conference Chairs: John Schewel, Virtual Computer Corp.; Peter M.
Athanas,
Virginia Polytechnic Institute and State Univ.; Steven A. Guccione,
Xilinx
Inc.; Stefan Ludwig, Compaq Computer Corp.; John T. McHenry, National
Security Agency
Many systems engineers are using reconfigurable device technologies,
such
as Field Programmable Gate Arrays (FPGAs) and Complex Programmable Logic
Devices (CPLDs), to overcome computation and product development
bottlenecks. In recent years, these devices have been incorporated into
computing systems for the purpose of providing a reconfigurable
environment
for high-performance applications. This conference focuses on two areas
of
reconfigurable technology:
1) systems, tools and techniques
2) high-performance applications
Today's reconfigurable devices can be used for datapath and data
processing
applications, as well as for general logic replacement.Processors built
from reconfigurable logic devices are being applied to a wide range of
computationally-intensive tasks.
The conference will present papers that illustrate applications and
techniques for using reconfigurable technology in both the design cycle
and
in production systems. Papers relating to the following areas are
solicited:
* digital and analog reconfigurable components
* programming tools and methodologies for configurable computing systems
* applications and platforms utilizing configurable technology for:
- hardware/software codesign
- rapid product development
- high-performance computing
- image, signal, and communication processing
intelligent systems, robotics, and evolvable algorithms
Abstract Due Date: 8 February 1999
Manuscript Due Date Date: 28 June 1999
Abstract Information Required:
1. Submit To: VV03 Schewel ET AL
2. Abstract Title
3. Author Listing (Principle Author First)
First Name, Last NAme, Affliation, Mailing Address,
Telephone, Fax, Email
4. Presentation: "Oral" or "Poster"
5. Abstract Text (Aproximately 250 Words) English
6. Keywords: Five Max.
7. Brief Bio of Principle Author
You may submit Abstracts in ONE of the following options:
SPIE WEB --- Form to be found on SPIE Website
www.spie.org/forms/pe99_submission_form.html
EMAIL --- To: abstracts@spie.org ; in ASCII Text Only
Subject: VV03, Schewel
MAIL --- Three copies of abstract to:
Voice, Video & Data Communications
SPIE PO Box 10, Bellingham WA 98227-0010 USA
or Shipping Address
1000 20th St. Bellingham WA 98225 USA
FAX --- one copy top SPIE at (1) 360-647-1445
--
Best Regards,
John Schewel, VP Marketing & Sales
Virtual Computer Corp.
http://www.vcc.com
--------------FEC4E2A6DB089053FCD3A9BB
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for John Schewel
Content-Disposition: attachment; filename="vcard.vcf"
begin: vcard
fn: John Schewel
n: Schewel;John
org: Virtual Computer Corporation
adr: 6925 Canby Ave. #103;;;Reseda;CA;91335;USA
email;internet: jas@vcc.com
title: VP Marketing & Sales
tel;work: +1 (818) 342-8294
tel;fax: +1 (818) 342-0240
x-mozilla-cpt: ;0
x-mozilla-html: TRUE
version: 2.1
end: vcard
--------------FEC4E2A6DB089053FCD3A9BB--
Article: 13871As the person who started this thread (!!) I think my original "theory": it is OK for a SM to sample a single async input provided that its states are gray-coded should have this added and provided that the effect of that input is EITHER to remain in the present state, OR to go to a next state (i.e. using the input to select one of *two* next states is not allowed) In the example you give below, one is indeed sampling just one input but one has *two* D-types potentially acting on that signal, and it is only a matter of time before one sees the signal as 1 and the other sees it as 0. It so happens that my state machine does sample only one input, and also happens to obey rule #2 above (this won't be apparent unless one looks at the state diagram, which I could but did not post). However, as I have said before, my "one input" becomes "two inputs", courtesy of CUPL's usage of *both* true and complement versions of that input and courtesy of a nice skew in the generation of the true and complement versions in the *AMD* 22V10. >But when the control input changes asynchronously, then the two >flip-flops might interprete the control differently ( because of >routing delay differences, set-up time differences, etc) >So the output might actually change directly from 00 to 11, because the >left flip-flop caught control =0, while the right flip-flop caught >control =1. >Bye-bye Grey code. -- 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: 13872
Whoopeeee! After 60 posts to this thread... ! >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. Cannot be done without >changing 2 D-inputs at once, in which case you are not sampling a gray code >sequence, and it will fail. > >All you can do is stay in state A or advance to state B based on the async >input. You can build a safe gray code counter with an async. count enable, >but that is about all it will ever be. -- 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: 13873
We have the following openings at large semiconductor companies. We provide US work visa for qualified candidates if needed. Firmware Engineer (Portland, Oregon) * Will be responsible for developing firmware/software to allow customers to use the company chips. * Will help to develop a process so that the firmware/software routines can be easily re-used in future chips. * Will support prototype and test validation. * Will work with customer to develop requirements and support customer in the integration of the chips. BSCS/BSEE or equivalent with 2+ years designing and developing software is required. Must have program in C/C++ language experience. Experience writing firmware for embedded designs, image processing a plus. Japenese, Korean and Mandarin languge knowledge a plus. Application Engineer (Oregon and Arizona) Primary duties of the position include providing technical support to customers as well as the company marketing and sales personnel. Developing technical collateral to aid in product implementation and business development. Analyzing and resolving product performance, function and application issues. Perform competitive analysis, and developing evaluation boards, demonstration applications, and other tools to aid in product evaluation and sales. BSEE, 2+ years experience in applications/systems engineering. In depth knowledge of circuit analysis and electronic system architecture; excellent verbal and written communication skills; (Japanese, Korean and Mandarin knowledge is a big plus) ========================================= Capability to effectively operate logic analyzers, scopes, and other electronic diagnostic tools. In addition, it is required that candidates have knowledge of software languages (C++, Assembly), and have experience in printed circuit board design and tools. EDA SW developer. (Arizoan) 2+ years experience in UNIX, C++ and EDA SW development Please send your TEXT only resume if you are interested. Sincerely: Gary LangArticle: 13874
z80@ds2.com (Peter) wrote: > >As the person who started this thread (!!) I think my original >"theory": > > it is OK for a SM to sample a single async input provided that > its states are gray-coded > >should have this added > > and provided that the effect of that input is EITHER to > remain in the present state, OR to go to a next state (i.e. > using the input to select one of *two* next states is not > allowed) 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 and static hazards associated with that input may still cause problems. Cheers Terry...
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