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
Edward Moore wrote: > then Ray Andraka <randraka@ids.net> wrote: > > >It is very difficult to get this kind of performance in a synthesized design > >(especially with the async clocks). In cases like this it is much faster and > >easier to just to do it in schematic the way you know it needs to be implemented > >and be done with it. > > IMO one of the reasons why the schematic entry vs. HDL debate keeps > cropping up is statements like the above, which are originated by people > who either: > > a) might have a vested interest in persuading people that they won't be > able to use a HDL for their designs > > b) havn't tried using a HDL > > c) have tried a HDL, but didn't do it properly > > d) work for FPGA manufacurers and should perhaps know better. > > At it's heart, the 'cant do it in a HDL' arguement seems to stem from a > confusion between inferred and instantiated HDL. No one is claiming that > a synthesiser can infer a a complete async fifo. But using instantited > components is a direct textual equivalant to schematic entry, so there > is no design element that can be placed on a schematic that can't be > included in a HDL design. Period. (as you Americans say). i would strongly disagree that instantiated components in a hdl is a direct equivalent to schematic entry. now, if you draw schematics such that there is just a group of black blox symbols on the sheet, with a textual label on them as a reference designator indentifying the function, and no interconnection between components with lines, just labels for a small net attached to each pin, and the symbols for each component positioned linearly on the page, without respect for data flow or time, then you would have an equivalence. while some engineers do draw schematics that way, it loses a lot of information. ======================================================= > I believe that the mixed inferred/instantiated method is used by most > experienced HDL designers. A designer might predominately infer logic, > but a some point will say to themselves 'it will be easier to just > instantiate this element and have done with it'. or hook a mixture of components, schematic, macro, and hdl on a top level roadmap or dare i say, schematic. a large amount of instantiated logic is good for 'puters, in my opinion, not for humanoids. ======================================================== rkArticle: 13801
Peter, My two cents worth is that whether the problem is a slow clock edge double clocking your part, or a static hazard in your equations can be determined by whether you see this problem only at this state transition or whether you see it happening at other transitions as well. If this is the only transition that has a problem, then you most likely have a static hazard. But don't discount the slow clock edge. A little noise on the rising edge of a clock line can produce a extra splinter pulse that violates the spec on the pulse duration of the clock and will be seen by some FFs and not all. This is very analogous to the asynch race condition that made you gray code your counter. If one FF 'sees' the extra pulse and the others don't, it can transition ahead of the others. Another clue would be if your normal state sequence is 100 to 101 to 001. This would strongly indicate that it is a clock edge problem. The static hazard problem can be very difficult to determine and even harder to fix. The only way I know to diagnose it is to examine the fuse map, or whatever text files are provided which show you the 'optimized' equations that are actually implemented in the fuses in the PAL. Then you can check the coverage of these equations. To see if you have a static hazard, you can draw a Karnaugh-Map with all of the input signals for a given bit. Then circle the minterms as indicated by the product terms in your fuse map. Now you examine the possible transitions. If there is a transition you need to make in moving from one state to another, that crosses between two circled groups and does not stay within a circle while making the transition, you have a static hazard. To fix it you need to add a product term to cover each transition. It is not enough to just cover all the minterms as we are taught to do for logic minimization. If this is not clear, I can refer you to some texts on the subject. Peter wrote: > > I don't think it is this because the state machine is clocked with a > clock common to all three D-types. Glitches, or a slow edge, on an > input should mean simply that the state machine just misses it or just > catches it. > > However I think Don, in a post in this thread, has the right answer... > unfortunately :) > > >You might have a 'static hazard'. For example an XOR gate with both > >inputs connected, if the propogation time is not perfectly matched > >then the output will glitch high on input state changes. -- Rick Collins redsp@XYusa.net remove the XY to email me.Article: 13802
>normally, i would construct a gray coded >machine the asynchronous input going into the clock of the state machine, >which goes through a gray code sequence. then, if you sample the output >asynchronously, it can't jump illegally between states, you can only get >either the present state or the next state. This is true where you have the async input *clocking* the state machine. In my case, the async input is *sampled* by a state machine which is clocked at a constant clock, 1MHz. I think the problem is caused by the equation(s) making use of both Input and !Input, and there is the inevitable slight skew between the two. -- 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: 13803
I am sure that if one is sampling just *one* input, and the states are Gray-coded, then there should never be a metastable hazard. FWIIW I have relied on this extensively in the past, as have others I know, and I always thought it was a well-known principle. But I am in fact sampling *two* inputs, generated from my single input within the state machine equations. My problem is how to rewrite the equations so that either only the input, or only its complement, (but not both) are used. I don't think there is a way to do that predictably using CUPL's state machine language; obviously one could do it by working out all the equations manually but then I am not sure if the 22V10 has enough product terms. I will simply put an HC74 on the async input :) 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. I am astonished at how helpful people here have been, at a time when the world is supposed to have ground to a halt. Many thanks! >I second your opinion on both counts. I think you have identified the >hazard which is causing the problem as well as the cure, but even with >all of the hazards fixed, isn't there still a problem with >metastability? I haven't done the math, but I suppose that at 1 MHz >there is not much likelihood of it causing a failure. But synching the >input will guarantee that there won't be a metastability problem. -- 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: 13804
Magnus Homann wrote: > > z80@ds2.com (Peter) writes: > > Unfortunately, the TEST_ENA signal does get used. It is a manually > > operated switch; rarely used but still needs to work. > > A misunderstanding? The "ENC_IN" from the last term should be removed, > not the !TEST_ENA. To me, it seems that this will keep the logical > functioning of the TEST_ENA, but still remove the hazard. > > > I also have the problem of how to reconcile my preference for using > > CUPL's state machine precompiler with the increasingly obvious fact > > that doing it the hard way is better in this case :) > > I would go for synching all asynch inputs. Makes it easier in the long > run, IMHO. > > > >The second two is where the problem is. > > >> # !ENC_IN & !EQ0 & !EQ1 & EQ2 > > >> # ENC_IN & !EQ0 & !EQ1 & EQ2 & !TEST_ENA > > > > > >If TEST_ENA is inactve, and EQ[0-2] = "001", one of the rows are > > >active, and they switch depending on the input. As a check, none of > > >the other terms are active on that state. > > > > > >Making a two-variable Karnaugh-diagram (very impressive... ;-), I > > >suggest you remove the "ENC_IN" from the last term. That should do it. > > Homann I second your opinion on both counts. I think you have identified the hazard which is causing the problem as well as the cure, but even with all of the hazards fixed, isn't there still a problem with metastability? I haven't done the math, but I suppose that at 1 MHz there is not much likelihood of it causing a failure. But synching the input will guarantee that there won't be a metastability problem. -- Rick Collins redsp@XYusa.net remove the XY to email me.Article: 13805
z80@ds2.com (Peter) writes:
> I am sure that if one is sampling just *one* input, and the states are
> Gray-coded, then there should never be a metastable hazard. FWIIW I
> have relied on this extensively in the past, as have others I know,
> and I always thought it was a well-known principle.
Don't think I've heard it.
> But I am in fact sampling *two* inputs, generated from my single input
> within the state machine equations.
Depends on how you look at it, I guess. If you look at the pin, only
one input. If you look after the generation of the inputs inverse, you
have two inputs. Maybe one should look after the first and gate? Then
you have as many asynch inputs as you have PTs. Or maybe it's the
input to each DFF. Then you are back to one input.
The number of "apparent" input to your logic black box is not
important, What is important is what you do with it inside your box.
I think it is easier to consider it from the "Karnaugh-side", where
you never go from one "sqaure" to another with the same value, without
being covered by the same term.
> My problem is how to rewrite the equations so that either only the
> input, or only its complement, (but not both) are used. I don't think
> there is a way to do that predictably using CUPL's state machine
> language; obviously one could do it by working out all the equations
> manually but then I am not sure if the 22V10 has enough product terms.
>
> I will simply put an HC74 on the async input :)
Will probably save you a lot of grief.
> I am astonished at how helpful people here have been, at a time when
> the world is supposed to have ground to a halt. Many thanks!
No problem, it will be $2.99. Or a beer. :-)
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: 13806rk wrote in message <36878B1E.42C45D73@NOSPAMerols.com>... >Stout wrote: >> >> By the way, I'm not aware of any theory which saz that Gray >> codes can be used to avoid illegal state jumps. I always thought >> they were used to reduce the size of the state machine. Can >> anybody else confirm this? > >gray code machines have the same number of flip-flops as a binary encoded >one. however, they excel at avoiding illegal state jumps since only one I was not talking about the number of FF they use. Clearly they use the same number of FF. What I was talking about was the comb. logic before the the FF is sometimes reduced with Gray codes vs. straight binary implimentation. I would think smart synthesis program could do as well or beter. >variable changes at a time. normally, i would construct a gray coded >machine the asynchronous input going into the clock of the state machine, >which goes through a gray code sequence. then, if you sample the output >asynchronously, it can't jump illegally between states, you can only get >either the present state or the next state. or you can think of it as a I think you are wrong when you said, "it can't jump illegally between states". With metastable, and a pore design, a state machine can do almost anything it wants to. This hole thread is because peter has just proved this. >mechanical shaft encoder. as a shaft rotates, the position is indicated by >a gray code. since sampling is asynchronous, you cannot guarantee that the >inputs are stable when sampled. however, since only one input can be >changing at the clock edge, you will get the correct position to within one >click. > By the way, I've looked at Don's artical and I agree with what he saz. >========================================================= > >> Good Luck >> Jeff Stout > >rk >Article: 13807
After another day spent on this:
AMD PALLV22V10-15JC date code 4264AMK (yes 4264AMK)
Exhibits the already described metastability problem
- approx 1 error per second
PHILIPS P3Z22V10BA date code 9722
So bad it barely runs, I spent days on this before
trying out the AMD parts - these were from 5 samples
received ~6/98 from a UK Philips distributor. I don't
know what is wrong with these but it could be extreme
sensitivity to clock risetime (actual=10ns, spec=20ns
max), clock looks extremely clean on a 200MHz scope
PHILIPS P3Z22V10BA date code 9809
Works perfectly, no errors in over an hour!!
I will still add the external HC74. This has to work at
60C ambient, etc.
So it looks like Philips have done a very quiet but possibly a very
substantial redesign of the device. And the AMD device has a
relatively huge skew in its internal data and !data generation.
On top of all this I have had more fun:
Data I/O Chiplab programmer (used for the AMD parts) being unable to
read any ex-CUPL jedec files ("incompatible data type"); I had to
"process" the jedec file with an old programmer front end (Logiclab,
long-defunct) into a very bare (and possibly barely legal) jedec file
which the Chiplab *does* accept, but this process strips the test
vectors which would have been handy on the Chiplab. The Chiplab also
refuses to program the device, with another cryptic error message,
unless one un-checks the test-vector test option (really obvious!).
Why this stupid programmer cannot intelligently handle jedec files,
especially those which are 64 bits "short" because they don't have the
UES, I don't know.
The Philips Coolrunner programmer refuses to accept the ex-Logiclab
jedec file (fair enough), it does accept the CUPL jedec files but
complains 'not enough fuses' even if one of them (with the 64-bit UES
added) definitely does have enough fuses. It however does not do any
test vector testing. At least I now know the Philips 22V10 problem was
a whole batch of duff devices and not a duff programmer.
I am glad to be doing this with the phone *not* ringing...
--
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: 13808Hi Peter: I'll take another perspective.... forget about "Gray Scales" and....... If the single input signal is feeding flops to determine next state AND the input signal is, as you say asynchronous THEN It COULD be possible that one state flop is having its setup requirement met while the other is not. Endif :) The result of course would be to enter an "unplanned" state. For yuks, I'd register the async input(s) the state machine using the state machine's clock. See what happens. -- Ed McCauley Bottom Line Technologies Inc. http://www.bltinc.com Specializing Exclusively in Xilinx Design, Development and Training Voice: (500) 447-FPGA, (908) 996-0817 FAX: (908) 996-0817Article: 13809
Peter wrote: > > I am sure that if one is sampling just *one* input, and the states are > Gray-coded, then there should never be a metastable hazard. FWIIW I > have relied on this extensively in the past, as have others I know, > and I always thought it was a well-known principle. I don't believe this is true at all. The problem you are seeing, a static logic hazard, and Metastability are two different issues. The logic hazard has to do with the output of combinatoral logic glitching on the change of a single input because of a lack of product terms covering all of the transitions. Metastability has to do with the behaviour of a FF when the setup and hold times are not met. I believe Xilinx has a good app note on metastability. It describes how it happens, complete with the pertinent equations to describe how often you are likely to see a problem from it. But one key point they make is that you can never eliminate it, even by putting a FF in front of your FSM. The output of the FF will have some probability of "holding" a metastable state for the entire clock period. This is analogous to you balancing a pencil on its point. But it only needs to stand for a uSec before the next clock tick clocks the next FF with an indeterminate voltage on its input and produces a metastable condition in that FF. While the likelihood of this happening with the 1 MHz clock is greatly diminished compared to a 30 MHz clock, it is not zero. But I am pretty sure that you won't see it happen within the next year. > But I am in fact sampling *two* inputs, generated from my single input > within the state machine equations. This is the static logic hazard, not a metastable problem. > My problem is how to rewrite the equations so that either only the > input, or only its complement, (but not both) are used. I don't think > there is a way to do that predictably using CUPL's state machine > language; obviously one could do it by working out all the equations > manually but then I am not sure if the 22V10 has enough product terms. I don't think you can adjust the equations in your source code unless you can turn off optimization. Magnus had a good fix for your optimized equations if you can get that into the fuse map. > I will simply put an HC74 on the async input :) 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. You might want to check the Xilinx app note (or others) before you assume this will fix the problem well enough. It may reduce it to once a year or so, but that is a guess. You may need two FFs in front of your FSM for this to work correctly. An HC174 might be more useful (more FFs ;^). > I am astonished at how helpful people here have been, at a time when > the world is supposed to have ground to a halt. Many thanks! I think you must have hit a nerve. I guess a lot of people have encountered this problem before and "feel your pain". -- Rick Collins redsp@XYusa.net remove the XY to email me.Article: 13810
Dan, in principle, there isn't a big difference between finding nice numbers near the original cosine values and truncating them at a certain precision. Both of these are approximations. When I looked at this stuff, the shift and add approaches were for minimizing hardware. If the hardware is given, and you are minimizing software instructions, I don't think it is profitable. Multiplication free DCTs are a subset of multiplication free filters which are well published in the various research magazines. You might look at: SPIE Proceedings Vol. 2419 Digital Video Compression: Algorithms and Technologies 1995 Multiplication free scaled 8 x 8 DCT algorithm with 530 additionsArticle: 13811
>I don't believe this is true at all. The problem you are seeing, a >static logic hazard, and Metastability are two different issues. The >logic hazard has to do with the output of combinatoral logic glitching >on the change of a single input because of a lack of product terms >covering all of the transitions. Metastability has to do with the >behaviour of a FF when the setup and hold times are not met. > >I believe Xilinx has a good app note on metastability. Yes, I agree with you fully. I stupidly used the wrong terminology. I generally understand the issues with metastability, with the frequencies and edge risetimes all affecting it. A fast synchroniser can easily push the occurrence way into the "almost never" area, at only 1MHz. >While the likelihood of this happening with the 1 MHz clock is greatly >diminished compared to a 30 MHz clock, it is not zero. But I am pretty >sure that you won't see it happen within the next year. I think a VHC74, also clocked at 1MHz, will do very well. Its output would have to be wondering about for a whole microsecond to cause trouble. Also, its o/p risetime is <5ns versus my present 50ns edge. Also, (see my other post) the Philips P3Z22V10 is evidently far far better at this than the AMD device, several orders of magnitude. I will however keep using the AMD parts for crap jobs like CPU address decoding - they are very cheap :) >You might want to check the Xilinx app note (or others) before you >assume this will fix the problem well enough. It may reduce it to once a >year or so, but that is a guess. You may need two FFs in front of your >FSM for this to work correctly. An HC174 might be more useful (more FFs >;^). Yes, I have seen this done. In my case I fortunately can tolerate the delay. -- 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: 13812
Christmas seems to bring out the best in the people on these newsgroups. More than a dozen responses, several quite detailed and insightful, within a day, when most of the world is goofing off. Or let's call it "resting" I like it. That's the way it should be. Happy New Year to all of you! Peter AlfkeArticle: 13813
On Mon, 28 Dec 1998 08:24:56 GMT, z80@ds2.com (Peter) was overheard to
say:
[Apologies if my ASCII art gets munged in the process...]
> >Just employing a Gray code doesn't imply that your *implementation*
> >is "hazard free". Make sure there are no adjacent terms in
> >the Karnaugh maps that aren't covered by a *single* minterm!
> >Often, this requires a less than minimal sum-of-products
> >implementation (i.e. some redundant terms are introduced to
> >ensure that the adjacent terms are always within a single minterm).
> >
> >In other words, if there are any paths in the Karnaugh map
> >that *momentarily* leave one minterm's coverage on their
> >way to *another* minterm's coverage, you have a potential
> >hazzard at the transition point.
>
> I think *this* is the answer. I actually suspected this but having
> spent years on "push button" logic design I am not sure what to look
> for.
>
> Thinking back over my previous designs, it turns out that most did
> have a synch'ed input. However I vaguely recall, on a memory
> arbitration state machine I did years ago in an EP900, that I had to
> stop CUPL minimising the expressions.
>
> Oh well, time to blow 20 years' worth of dust off my ex-univ. logic
> books... I always hated those diagrams.
>
> I am not asking others to do my work for me but maybe someone will
> spot something really obvious in the following:
>
> The three D-type outputs are EQ2,EQ1,EQ0, the inputs are ENC_IN and
> TEST_ENA (the latter is not used and is always false) and the logic is
>
> EQ0.d =>
> !ENC_IN & !EQ0 & !EQ1 & EQ2
> # ENC_IN & !EQ0 & !EQ1 & !EQ2
> # !EQ0 & EQ1
> # !EQ0 & !EQ1 & EQ2 & TEST_ENA
\ E1 E0
\
IN E2\ 00 01 11 10
+-----+-----+-----+-----+
00 | 0 | 0 | 0 | C |
+-----+-----+-----+-----+
01 | A | 0 | 0 | C |
+-----+-----+-----+-----+
11 | 0 | 0 | 0 | C |
+-----+-----+-----+-----+
10 | B | 0 | 0 | C |
+-----+-----+-----+-----+
A B and C are all "1"s and just shown this way to indicate which of
the equations above was used to synthesize those particular cases in
the map.
Note I have assumed "TEST_ENA" = 0 and, as such, the 4th equation is
ignored. This allows me to only have to deal with 4 variable maps...
[N.B. I build Karnaugh maps with the input variables listed in
gray code order instead of pure binary -- look at the labeling
of the horizontal and vertical axes...other folks have different
preferences]
> EQ1.d =>
> EQ0 & !EQ1 & EQ2 & !TEST_ENA
> # EQ0 & !EQ1 & !EQ2
> # !EQ0 & EQ1
\ E1 E0
\
IN E2\ 00 01 11 10
+-----+-----+-----+-----+
00 | 0 | B | 0 | C |
+-----+-----+-----+-----+
01 | 0 | A | 0 | C |
+-----+-----+-----+-----+
11 | 0 | A | 0 | C |
+-----+-----+-----+-----+
10 | 0 | B | 0 | C |
+-----+-----+-----+-----+
> EQ2.d =>
> !EQ0 & !EQ1 & TEST_ENA
> # !EQ0 & EQ1 & EQ2
> # EQ0 & EQ1 & !EQ2
> # !ENC_IN & !EQ0 & !EQ1 & EQ2
> # ENC_IN & !EQ0 & !EQ1 & EQ2 & !TEST_ENA
> # EQ0 & !EQ1 & EQ2
\ E1 E0
\
IN E2\ 00 01 11 10
+-----+-----+-----+-----+
00 | 0 | 0 | C | 0 |
+-----+-----+-----+-----+
01 | D | F | 0 | B |
+-----+-----+-----+-----+
11 | E | F | 0 | B |
+-----+-----+-----+-----+
10 | 0 | 0 | C | 0 |
+-----+-----+-----+-----+
Note that the first equation is always false so there is no "A"
in the map... Likewise, the "!TEST_EN" in equation E is always
true...
Imagine a circle drawn to encompass like letters in these maps.
In the above map, the two B's would be in one such circle. Likewise
for the two F's. The circle for the C's would connect the two
*adjacent*(!) C's (imagine the top and bottom edges of the map were
tied together). The D and E would be in their own separate circles.
Now, if you are at "E" (state = 100, IN = 1) and you change the IN
input to "0", it is as if you are traversing from the E to the D. But,
as you make that change, there is a point in time when you are no
longer "covered" by the "E" equation and not yet covered by the "D"
equation. If the clock edge occurs at that time, you end up in some
*other* state!
The solution is to make sure there is an equation that covers you
*while* you are transitioning. In other words, we want a "circle"
that covers both the "D" and "E" squares in the above map.
Note that the D square is represented by state = 100, IN = 1
while E is represented by state = 100, IN = 0. We can cover *both*
of them by noting that "state = 100" and IN = don't care. This
removes the dependancy on "IN" in those two equations and eliminates
the race/hazzard.
Note that you don't have to worry about combining these with,
for example, the two "F" cases immediately adjacent to them
(though you can and this will reduce the equations even further!)
since the "transitions" from D or E to F don't depend on this
asynchronous input of yours...
A minimal implementation of this would be to combine the D E and F
terms into !E1 & E2. Likewise, combine the B E and F terms per
!E0 & E2 (of course, you could factor these two equations
into E2 & (!E0 + !E2) but that won't help you with a two level
sum-of-products implementation typical of PAL AND/OR arrays)
However, combining the E case like this presupposes that TEST_IN
will always be "0". To retain that independant function, you can only
combine D with the F located immediately to it's right. The D can
*also* be combined with the E located below it by adding "TEST_IN"
to the case for the D term.
In other words, treat the D equation as:
...
# !ENC_IN & !EQ0 & !EQ1 & EQ2 & TEST_IN (D.1)
# !ENC_IN & !EQ0 & !EQ1 & EQ2 & !TEST_IN (D.2)
...
and then combine with
# ENC_IN & !EQ0 & !EQ1 & EQ2 & !TEST_IN (E)
to yield
# !ENC_IN & !EQ0 & !EQ1 & EQ2 & TEST_IN (D.1)
# !EQ0 & !EQ1 & EQ2 & !TEST_IN (D.2 + E)
Note that you *could* combine the A and B cases in the equations
for E1 *if* you always assume TEST_IN is wired to "0". Then, they
could be replaced by !E1 & E0
L:ikewise, the E0 equations could combine the A term with part
of the C term located immediately adjacent to it (i.e. remember the
left and right edges of the maps are interpreted as adjacent)
using !IN & E2 & !E0. The B term can be combined with the adjacent
portion of C using IN & !E2 & !E0.
> The above is *after* the lowest level of optimisation by CUPL. With no
> optimisation it won't compile because there are far too many terms to
> fit a 22V10.
Well, my Brainiac2000 might be on the fritz today so double check
all my logic :>
> I can use a HC74 to sync the input if I have to but would prefer to
> avoid it to save PCB space.
Do you have a spare FF inside the GAL/PAL? If so, you could use it as
a synchronizer and route it's synchronized output back into the AND/OR
array as if it was your "ENA" input...
(synchronizers are always a problem issue, though, so make sure
you design it right! :>)
To reply, replace the asterisks: dgy*gci-net*com
Article: 13814More thoughts on this: in a Xilinx FPGA, even though the LUT is a RAM decoder and - like any normal RAM/ROM decoder - could generate decoding glitches, it is guaranteed by Xilinx that no glitches will occur provided only *one* input changes at any one time. Presumably this is achieved by making sure that any differences in propagation delays through different paths of the LUT circuit are *less* than the switching time of the logic (I mean the ability of the logic to respond to an input change) which forms the LUT output(s). So even if glitches were generated - and I can't see how they can be avoided since no two things in nature can ever take exactly the same time - they won't propagate to the LUT output(s). There is no reason why the same principle would not apply to a GAL. Referring to the input pin circuitry (the one which generates the true/complement signals which drive the fuse matrix), if these two signals are generated with a skew which is less than the switching time of the huge OR gates which form the product matrix, then these glitches (which I presumably saw in the AMD device) could never occur. If the above is true, then the AMD PALLV22V10 is a really s****y design, because anyone designing such devices must be aware of the way they are going to get used. Just imagine how many Xilinx FPGA designs would never work if the LUT had propagation time skews big enough to generate glitches. In light of the above I wonder if my statement about a "single async input plus Gray code state machine encoding" is true after all, IF you have a glitchless piece of logic before the D-types. -- 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: 13815
Rickman wrote: <snip bunch of stuff> > > I will simply put an HC74 on the async input :) 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. > > You might want to check the Xilinx app note (or others) before you > assume this will fix the problem well enough. It may reduce it to once a > year or so, but that is a guess. You may need two FFs in front of your > FSM for this to work correctly. An HC174 might be more useful (more FFs > ;^). i think it will be quite less than once per year at those frequencies - and it's easy enough to calculate. the xilinx flip-flops, as shown in peter's app notes, are extremely good. while no matter what you do you can never eliminate metastability problems, it can be made quite small with an extremely low failure rate. 500 nsec settiling time for a modern high-speed flip-flop is pretty good and peter may wish to consider a 74ac74 for better response. also, since that is a dual f-f, he can, if he can stand the latency, let it go through both flops, one for 1 usec settling, the other for 500 nsec. that will give quite adequate performance. ============================================================ > > I am astonished at how helpful people here have been, at a time when > > the world is supposed to have ground to a halt. Many thanks! > I think you must have hit a nerve. I guess a lot of people have > encountered this problem before and "feel your pain". actually, it's an interesting topic and i've designed hazard-free circuits (ok, now how do you test them?). and of course it's a nice case of just hit the button and the software does all the work - and produces a bad circuit. perhaps there's something left for logic designers to do ... rkArticle: 13816
Nothing to add here. I just wanted to be part of what could turn out to be longest thread in the history of CAF. Bob S. Peter wrote: > > Hello, > > I have come across a weird problem. > > 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. > > The single changing input is monotonic. The illegal transition occurs > when "expected", i.e. when the input changes at the same time as the > clock edge. > > Does anyone have any idea what could be causing this? > > I can externally sync the input with an HC74, even using the opposite > clock edge, but if there is something odd happening inside this device > then I am going to have other problems, since I am relying on the Gray > coding to avoid illegal state jumps. > > -- > 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: 13817
Rickman wrote: > I believe Xilinx has a good app note on metastability. It describes > how > it happens, complete with the pertinent equations to describe how > often > you are likely to see a problem from it. But one key point they make > is > that you can never eliminate it, even by putting a FF in front of your > > FSM. The output of the FF will have some probability of "holding" a > metastable state for the entire clock period. This is analogous to you > > balancing a pencil on its point. But it only needs to stand for a uSec > > before the next clock tick clocks the next FF with an indeterminate > voltage on its input and produces a metastable condition in that FF. > > While the likelihood of this happening with the 1 MHz clock is greatly > > diminished compared to a 30 MHz clock, it is not zero. But I am pretty > > sure that you won't see it happen within the next year. > The app note is called XAPP094 and can also be found on pages 13-47...49 of the 1998 Xilinx data book. Metastability is an unpredictable response on a flip-flop OUTPUT that can ( not must ) occur when the set-up time is violated. Modern flip-flops fall back out of the metastable state in a very short time, usually in lass than a few nanoseconds. But that delay is a statistical phenomenon. 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. Driving asynchronous data inputs "simultaneously" into more than one flip-flop, however, is bound to lead to strange results, whether the logic is grey-coded or not. But don't blame that on metastability. Peter Alfke, Xilinx ApplicationsArticle: 13818
good evening,
pls see some comments below,
rk
==============================================================
Jeff Stout wrote:
> rk wrote in message <36878B1E.42C45D73@NOSPAMerols.com>...
> >Stout wrote:
> >>
> >> By the way, I'm not aware of any theory which saz that Gray
> >> codes can be used to avoid illegal state jumps. I always thought
> >> they were used to reduce the size of the state machine. Can
> >> anybody else confirm this?
> >
> >gray code machines have the same number of flip-flops as a binary encoded
> >one. however, they excel at avoiding illegal state jumps since only one
>
> I was not talking about the number of FF they use. Clearly they use
> the same number of FF. What I was talking about was the comb.
> logic before the the FF is sometimes reduced with Gray codes vs.
> straight binary implimentation. I would think smart synthesis program
> could do as well or beter.
i remember from one of my logic books that the logic resources uesed was about
the same, although i never looked into it that much. just for kicks, i coded up
an 8 state machine with enable and synthesized it twice, once for gray coding
the other for straight binary. both used identical number of logic resources.
of course, this is just one test case, ymmv.
=======================================================
> >variable changes at a time. normally, i would construct a gray coded
> >machine the asynchronous input going into the clock of the state machine,
> >which goes through a gray code sequence. then, if you sample the output
> >asynchronously, it can't jump illegally between states, you can only get
> >either the present state or the next state. or you can think of it as a
>
> I think you are wrong when you said, "it can't jump illegally between states".
>
> With metastable, and a pore design, a state machine can do almost
> anything it wants to. This hole thread is because peter has just proved
> this.
actually, no, this thread hasn't proved that at all. what is happening is that
the state machine has more than one variable changing state at a time and a
logic design error (and not a gray code). if you have a set of flip-flops
changing in a gray code sequence and sample the outputs asynchronously, even if
a flip-flop goes metastable, the error can not be large, and the following
machine can't do just about anything it wants, assuming that proper settling
time is allowed after sampling. if the sequence was binary, then your statement
would be partially true, just about anything can happen, as in the case where
the sequence goes from 011 to 100 - any value may be sampled.
now, in the original problem, it's not clear that any flip-flop is going
metastable at all. while clearly the setup and hold times are not being met,
there is no evidence in any of the discussion that oscillations, non-logic
values, or delayed outputs are being observerd. it appears that the problem is
a static hazard and the flip-flop is simply sampling the wrong value. the
output of the pal's combinational logic is not a gray code, two things are
changing, and that's the problem. by adding in the "redundant" terms to cover
all of the transitions, the output of the combinational network can be made to
look like a gray code sequence and things will work fine. or, simply,
synchronize the asynchronous input so that the static hazard happens away from a
clock edge (preferred).
===========================================================
> >mechanical shaft encoder. as a shaft rotates, the position is indicated by
> >a gray code. since sampling is asynchronous, you cannot guarantee that the
> >inputs are stable when sampled. however, since only one input can be
> >changing at the clock edge, you will get the correct position to within one
> >click.
> >
>
> By the way, I've looked at Don's artical and I agree with what he saz.
you should, it's correct and exactly what i said.
don saz:
The point of using a Gray code is that it avoids the types of
hazzards associated with races in the next state logic.
A Gray code, by definition, only has a single bit change between
any two adjacent code words. So, a signal that could have
potential timing problems through the decoding (i.e. next state)
logic will only affect at most a *single* output. By contrast,
if two or more state variables change then if the signal manages
to propagate through *one* path in the time available, *that*
output variable will change correctly while the *other(s)*
may not have enough time for the correct output to be formed.
==========================================================
rk
Article: 13819Hi, 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!Article: 13820
Hi - I'm not trying to be a cheerleader for AMD--Jerry Sanders can do his own PR--but I have no reason to believe that there's anything bad or substandard about AMD versions of the 22V10. 22V10s and most other PLDs are based on AND/OR planes, which are bound to be glitchy if the designer hasn't (a) added product terms to mask the effects of transition or (b) synchronized asynchronous inputs. The Xilinx FPGA implementation is completely different. Each 4-input LUT consists of 16 SRAM cells (latches, actually) followed by a 16:1 mux built with transmission gates. The construction is such that, if you switch a single LUT input, the mux switches between the outputs of two latches, and no others. (To see how this would work, picture 4 levels of 2:1 muxes, each of which has a LUT input as its select. I may be wrong about the exact structure, but you get the idea.) If the two latches we're transitioning between have the same state, you get a glitchless transition. There's no RAM decode glitch because there's no decoder. Each type of implementation has its pros and cons. AND/OR structures can have lots and lots of inputs and product terms, while LUTs are a compact way of implementing arbitrary functions of N variables. You pays your money and takes your choice. Regards, Bob Perlman Cambrian Design WorksArticle: 13821
Bob Perlman wrote: > Hi - > <snip> > 22V10s and most other > PLDs are based on AND/OR planes, which are bound to be glitchy if the > designer hasn't (a) added product terms to mask the effects of > transition or (b) synchronized asynchronous inputs. > > The Xilinx FPGA implementation is completely different. Each 4-input > LUT consists of 16 SRAM cells (latches, actually) followed by a 16:1 > mux built with transmission gates. The construction is such that, if > you switch a single LUT input, the mux switches between the outputs of > > two latches, and no others. <snip> If the > two latches we're transitioning between have the same state, you get a > > glitchless transition. There's no RAM decode glitch because there's > no decoder. Bob is right, but the reason that there is no glitch, even when the multiplexer acts like a break-before-make switch ( it undoubtably does, either in one direction or the other ) is more subtle., There is no glitch even with break-before-make because the stray capacitance between these pass transistors holds the old value for the fractional nanosecond in question. Having answered this question many times... Peter Alfke, Xilinx ApplicationsArticle: 13822
Peter wrote: > More thoughts on this: in a Xilinx FPGA, even though the LUT is a RAM > decoder and - like any normal RAM/ROM decoder - could generate > decoding glitches, it is guaranteed by Xilinx that no glitches will > occur provided only *one* input changes at any one time. > > Presumably this is achieved by making sure that any differences in > propagation delays through different paths of the LUT circuit are > *less* than the switching time of the logic (I mean the ability of the > > logic to respond to an input change) which forms the LUT output(s). So > > even if glitches were generated - and I can't see how they can be > avoided since no two things in nature can ever take exactly the same > time - they won't propagate to the LUT output(s). Yes, kind of. As I just described in a separate entry in this "longest thread", it is the stray capacitance between the pass transistors that bridges over whenever any of the switching 2-to-1 mux'es behaves as break-before-make. > Just imagine how many Xilinx FPGA designs would never work if the LUT > had propagation time skews big enough to generate glitches. > > In light of the above I wonder if my statement about a "single async > input plus Gray code state machine encoding" is true after all, IF you > > have a glitchless piece of logic before the D-types. Here is my attempt at a broad and simple explanation:Any state machine can ususally go to different states, depending on the input conditions. Even if grey-coded, it can still go either forward or backwards. When asynchronous control inputs appear at the D-inputs of sveral flip-flops and change during their set-up-time window, there is a possibility that one flip-flop interprets the control as "go forward", another flip-flop interprets it as "go backwards", and they might both change. It's an old story. Asynchronous inputs should never be synchronized in more than one flip-flop per input. I had that as an example in "Just Say NO to Asynchronous Design" in the 1994 Xilinx data book ( page 9-13). Just another way to make this thread even longer.... :-) Peter Alfke, Xilinx ApplicationsArticle: 13823
In article <368809B8.7E864BB9@xilinx.com>, Peter Alfke <peter@xilinx.com> writes: > 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. Wow! I haven't seen anything like that from Peter Alfke before. I think I understand the issues. I consider metastibility a big part of any design I get involved with. Sometimes, it's easy to convince myself that it won't be a problem. Often, it's a lot of work. I claim the problem isn't under control until metatstbility data gets published in data sheets rather than ApNotes. Note that the Xilinx ApNote that Peter referenced is over a year old. What if I want to use a chip released since then? What was the temp and Vcc during those tests? Can I assume it is worst case? -- These are my opinions, not necessarily my employers.Article: 13824
Hal Murray wrote: > In article <368809B8.7E864BB9@xilinx.com>, Peter Alfke <peter@xilinx.com> writes: > > > 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. > > Wow! I haven't seen anything like that from Peter Alfke before. > > I think I understand the issues. I consider metastibility a > big part of any design I get involved with. Sometimes, it's > easy to convince myself that it won't be a problem. Often, it's > a lot of work. > > I claim the problem isn't under control until metatstbility > data gets published in data sheets rather than ApNotes. good point. the old amd (29800 ?) logic family was "metastable-state hardened" and did have specifications as part of the data sheet. more recently, i've seen numbers in the chip express data books, for various flip-flop configurations. mostly, though, i've seen app notes from a number of the programmable vendors - and some others when you ask them for the metastable state parameters go, 'huh?'. rk
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