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
On Sep 20, 10:52=A0am, Darol Klawetter <darol.klawet...@l-3com.com>
wrote:
> I recently fixed a problem with one of my state machines, and I think
> that the cause could be a bug in Xilinx XST. Below is the code that
> produced the failure. The state-machine worked most of the time,
> though occasionally the 'phaseRamWE' signal would be stuck low, even
> though I could see 'phaseRamReadAdr' and 'phaseRamWriteAdr'
> incrementing. =A0I fixed it by explicitly declaring the desired value of
> 'phaseRamWE' in every state. Notice that all states are defined so it
> should recover from any conditions introduced by asynchronous inputs.
>
> Have any of you seen similar behavior? Appears to be an XST bug to me.
>
<snip>
I only skimmed the code, but this bit jumped out at me:
if (pipeFill =3D=3D 1'b1) // 'pipeFill' is
asynchronous to 'clk'
If pipeFill is really asynchronous to the clock that is running your
state machine, using it without synchronizing it first is going to
cause you problems. Probably not because of metastability, but
because of coherency problems. If pipeFill is changing near the clock
edge, some FFs will see the new value, and some the old. This can
cause weird and flaky behaviour.
Regards,
John McCaskill
www.FasterTechnology.com
Article: 149001On Sep 20, 11:00=A0am, Frank Buss <f...@frank-buss.de> wrote: > Darol Klawetter wrote: > > I recently fixed a problem with one of my state machines, and I think > > that the cause could be a bug in Xilinx XST. Below is the code that > > produced the failure. The state-machine worked most of the time, > > though occasionally the 'phaseRamWE' signal would be stuck low, even > > though I could see 'phaseRamReadAdr' and 'phaseRamWriteAdr' > > incrementing. =A0I fixed it by explicitly declaring the desired value o= f > > 'phaseRamWE' in every state. Notice that all states are defined so it > > should recover from any conditions introduced by asynchronous inputs. > > > Have any of you seen similar behavior? Appears to be an XST bug to me. > > I have seen similar behaviour with Altera Quartus. It was the same proble= m: > asynchronous inputs changed the state machine and sometimes it hangs. I > think it is possible that the state machine is internally implemented wit= h > some more bits and it is possible that it hangs, if there are some timing > violations or meta stability conditions, because then there is an invalid > state encoded and everything can happen with optimized gates. The fix was > easy: Creating an input latch (or even two, if you are paranoid) for each > asynchronous signal to make it synchronous. > > -- > Frank Buss,http://www.frank-buss.de > piano and more:http://www.youtube.com/user/frankbuss I thought the same thing, especially because XST often uses one-hot encoding internally, and that introduces more state bits. Even though I exhaustively defined all states, this may not be the case in the post-synthesis result.Article: 149002
On Sep 20, 11:05=A0am, John McCaskill <jhmccask...@gmail.com> wrote: > On Sep 20, 10:52=A0am, Darol Klawetter <darol.klawet...@l-3com.com> > wrote: > > > I recently fixed a problem with one of my state machines, and I think > > that the cause could be a bug in Xilinx XST. Below is the code that > > produced the failure. The state-machine worked most of the time, > > though occasionally the 'phaseRamWE' signal would be stuck low, even > > though I could see 'phaseRamReadAdr' and 'phaseRamWriteAdr' > > incrementing. =A0I fixed it by explicitly declaring the desired value o= f > > 'phaseRamWE' in every state. Notice that all states are defined so it > > should recover from any conditions introduced by asynchronous inputs. > > > Have any of you seen similar behavior? Appears to be an XST bug to me. > > <snip> > > I only skimmed the code, but this bit jumped out at me: > > =A0 =A0 =A0 =A0 =A0 =A0 if (pipeFill =3D=3D 1'b1) =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 // 'pipeFill' is > asynchronous to 'clk' > > If pipeFill is really asynchronous to the clock that is running your > state machine, =A0using it without synchronizing it first is going to > cause you problems. =A0Probably not because of metastability, but > because of coherency problems. If pipeFill is changing near the clock > edge, some FFs will see the new value, and some the old. =A0This can > cause weird and flaky behaviour. > > Regards, > > John McCaskillwww.FasterTechnology.com Agreed, but the state machine should recover, right? All states are defined.Article: 149003
On Mon, 20 Sep 2010 08:52:16 -0700 (PDT), Darol Klawetter <darol.klawetter@l-3com.com> wrote: >I recently fixed a problem with one of my state machines, and I think >that the cause could be a bug in Xilinx XST. Below is the code that >produced the failure. The state-machine worked most of the time, >though occasionally the 'phaseRamWE' signal would be stuck low, even >though I could see 'phaseRamReadAdr' and 'phaseRamWriteAdr' >incrementing. I fixed it by explicitly declaring the desired value of >'phaseRamWE' in every state. Notice that all states are defined so it >should recover from any conditions introduced by asynchronous inputs. > >Have any of you seen similar behavior? Appears to be an XST bug to me. Try adding a (* safe_implementation = "yes" *) to your state register and see if that gets rid of the problem. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 149004
On Sep 20, 11:05=A0am, John McCaskill <jhmccask...@gmail.com> wrote: > On Sep 20, 10:52=A0am, Darol Klawetter <darol.klawet...@l-3com.com> > wrote: > > > I recently fixed a problem with one of my state machines, and I think > > that the cause could be a bug in Xilinx XST. Below is the code that > > produced the failure. The state-machine worked most of the time, > > though occasionally the 'phaseRamWE' signal would be stuck low, even > > though I could see 'phaseRamReadAdr' and 'phaseRamWriteAdr' > > incrementing. =A0I fixed it by explicitly declaring the desired value o= f > > 'phaseRamWE' in every state. Notice that all states are defined so it > > should recover from any conditions introduced by asynchronous inputs. > > > Have any of you seen similar behavior? Appears to be an XST bug to me. > > <snip> > > I only skimmed the code, but this bit jumped out at me: > > =A0 =A0 =A0 =A0 =A0 =A0 if (pipeFill =3D=3D 1'b1) =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 // 'pipeFill' is > asynchronous to 'clk' > > If pipeFill is really asynchronous to the clock that is running your > state machine, =A0using it without synchronizing it first is going to > cause you problems. =A0Probably not because of metastability, but > because of coherency problems. If pipeFill is changing near the clock > edge, some FFs will see the new value, and some the old. =A0This can > cause weird and flaky behaviour. > > Regards, > > John McCaskillwww.FasterTechnology.com I think I just found the source of the problem, and it's not a bug in XST. In state S1, if 'state' is updated while 'phaseRamWE' is not, then it would produce the symptoms I saw. Early on, I had considered synchronizing pipeFill to the 'clk" domain, but I thought I would just handle it in the robustness of the state machine - my mistake.Article: 149005
On Sep 20, 11:12=A0am, Darol Klawetter <darol.klawet...@l-3com.com> wrote: > On Sep 20, 11:05=A0am, John McCaskill <jhmccask...@gmail.com> wrote: > > > > > On Sep 20, 10:52=A0am, Darol Klawetter <darol.klawet...@l-3com.com> > > wrote: > > > > I recently fixed a problem with one of my state machines, and I think > > > that the cause could be a bug in Xilinx XST. Below is the code that > > > produced the failure. The state-machine worked most of the time, > > > though occasionally the 'phaseRamWE' signal would be stuck low, even > > > though I could see 'phaseRamReadAdr' and 'phaseRamWriteAdr' > > > incrementing. =A0I fixed it by explicitly declaring the desired value= of > > > 'phaseRamWE' in every state. Notice that all states are defined so it > > > should recover from any conditions introduced by asynchronous inputs. > > > > Have any of you seen similar behavior? Appears to be an XST bug to me= . > > > <snip> > > > I only skimmed the code, but this bit jumped out at me: > > > =A0 =A0 =A0 =A0 =A0 =A0 if (pipeFill =3D=3D 1'b1) =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 // 'pipeFill' is > > asynchronous to 'clk' > > > If pipeFill is really asynchronous to the clock that is running your > > state machine, =A0using it without synchronizing it first is going to > > cause you problems. =A0Probably not because of metastability, but > > because of coherency problems. If pipeFill is changing near the clock > > edge, some FFs will see the new value, and some the old. =A0This can > > cause weird and flaky behaviour. > > > Regards, > > > John McCaskillwww.FasterTechnology.com > > Agreed, but the state machine should recover, right? All states are > defined. Hello Darol, While you may have specified all the possible states for the width of state variable that you used, unless you tell XST otherwise, it will choose which ever encoding style that it feels is optimal. That is usually a one hot encoding for a state machine the size of yours. By default, XST will assume that states that you do not explicitly have a transition to are truly unreachable and will not worry about them, and will ignore default or when others cases of your case statement. You can change the default behavior. You can force the tools to use an encoding of your choice, and you can use the safe state machine constraint to cause the tools to be more conservative in their assumptions about unreachable states. Doing that will come at a cost that the tools will choose a different encoding that will probably be slower and bigger. I think that you are much better off to always synchronize an asynchronous signal at the boundary of your design. Regards, John McCaskill www.FasterTechnology.comArticle: 149006
On Sep 19, 8:58=A0pm, "jt_eaton" <z3qmtr45@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote: > Is it my imagination of did all the spam on this newsgroup suddenly > disappear? > I checked google groups and the last piece I saw was dated 10 Aug. I was > sure that there were some more recent stuff. > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com I think that there are a number of people using Google Groups that are now reporting posts as SPAM. In another thread someone has posted that it takes about 40 total abuse reports from at least two different IP addresses for the Google routines to punt a post. So if everyone does a little community service and clicks the "Report spam" link 5-10 times each time these show up they will disappear quickly. Sometimes I only get 2 or 3 clicks and the post is gone so I know there are others out there doing the same. Ed McGettigan -- Xilinx Inc.Article: 149007
On Sep 20, 11:55=A0am, John McCaskill <jhmccask...@gmail.com> wrote: > On Sep 20, 11:12=A0am, Darol Klawetter <darol.klawet...@l-3com.com> > wrote: > > > > > On Sep 20, 11:05=A0am, John McCaskill <jhmccask...@gmail.com> wrote: > > > > On Sep 20, 10:52=A0am, Darol Klawetter <darol.klawet...@l-3com.com> > > > wrote: > > > > > I recently fixed a problem with one of my state machines, and I thi= nk > > > > that the cause could be a bug in Xilinx XST. Below is the code that > > > > produced the failure. The state-machine worked most of the time, > > > > though occasionally the 'phaseRamWE' signal would be stuck low, eve= n > > > > though I could see 'phaseRamReadAdr' and 'phaseRamWriteAdr' > > > > incrementing. =A0I fixed it by explicitly declaring the desired val= ue of > > > > 'phaseRamWE' in every state. Notice that all states are defined so = it > > > > should recover from any conditions introduced by asynchronous input= s. > > > > > Have any of you seen similar behavior? Appears to be an XST bug to = me. > > > > <snip> > > > > I only skimmed the code, but this bit jumped out at me: > > > > =A0 =A0 =A0 =A0 =A0 =A0 if (pipeFill =3D=3D 1'b1) =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 // 'pipeFill' is > > > asynchronous to 'clk' > > > > If pipeFill is really asynchronous to the clock that is running your > > > state machine, =A0using it without synchronizing it first is going to > > > cause you problems. =A0Probably not because of metastability, but > > > because of coherency problems. If pipeFill is changing near the clock > > > edge, some FFs will see the new value, and some the old. =A0This can > > > cause weird and flaky behaviour. > > > > Regards, > > > > John McCaskillwww.FasterTechnology.com > > > Agreed, but the state machine should recover, right? All states are > > defined. > > Hello Darol, > > While you may have specified all the possible states for the width of > state variable that you used, unless you tell XST otherwise, it will > choose which ever encoding style that it feels is optimal. That is > usually a one hot encoding for a state machine the size of yours. =A0By > default, XST will assume that states that you do not explicitly have a > transition to are truly unreachable and will not worry about them, and > will ignore default or when others cases of your case statement. > > You can change the default behavior. You can force the tools to use an > encoding of your choice, and you can use the safe state machine > constraint to cause the tools to be more conservative in their > assumptions about unreachable states. Doing that will come at a cost > that the tools will choose a different encoding that will probably be > slower and bigger. > > I think that you are much better off to always synchronize an > asynchronous signal at the boundary of your design. > > Regards, > > John McCaskillwww.FasterTechnology.com Thanks for the response, John. Yes, I realized that the Xilinx tools could use different state encoding than that specified by the user, but it seemed reasonable to assume that functionality would be matched (wrong assumption). Anyway, you may have noticed, from a previous post to this thread, that my problem was caused by my own error and was not tool related. I agree with your last paragraph. It's typically better to use a couple of flops on an asynchronous control signal than trying to handle it within the state machine (especially if the tool is going to take encoding liberties).Article: 149008
On Sep 20, 2:02=A0pm, Darol Klawetter <darol.klawet...@l-3com.com> wrote: > > I agree with your last paragraph. It's typically better to use a > couple of flops on an asynchronous control signal than trying to > handle it within the state machine (especially if the tool is going to > take encoding liberties).- Hide quoted text - > The rule is that any time there is a logic path from an asynchronous input to more than one device that samples the signal(s), you must first synchronize the signal before feeding it into any logic path. This condition occurs for any state machine with more than one state. KJArticle: 149009
> > I agree with your last paragraph. It's typically better to use a > couple of flops on an asynchronous control signal than trying to > handle it within the state machine (especially if the tool is going to > take encoding liberties).- Hide quoted text - > The rule is that any time there is a logic path from an asynchronous input to more than one device that samples the signal(s), you must first synchronize the signal before feeding it into any logic path. This condition occurs for any state machine with more than flip flop used to implement the state. KJArticle: 149010
On Sep 20, 3:49=A0pm, KJ <kkjenni...@sbcglobal.net> wrote: > > I agree with your last paragraph. It's typically better to use a > > couple of flops on an asynchronous control signal than trying to > > handle it within the state machine (especially if the tool is going to > > take encoding liberties).- Hide quoted text - > > The rule is that any time there is a logic path from an asynchronous > input to more than one device that samples the signal(s), you must > first synchronize the signal before feeding it into any logic path. > > This condition occurs for any state machine with more than flip flop > used to implement the state. > > KJ I agree that this is a rule that should be generally followed, but there are exceptions. For example, a gray-coded state machine is sometimes used to tolerate an asynchronous control input. If timing is violated on any of the flops, the machine will stay at the current state or transition to the next state.Article: 149011
On Sep 20, 5:01=A0pm, Darol Klawetter <darol.klawet...@l-3com.com> wrote: > On Sep 20, 3:49=A0pm, KJ <kkjenni...@sbcglobal.net> wrote: > > > > I agree with your last paragraph. It's typically better to use a > > > couple of flops on an asynchronous control signal than trying to > > > handle it within the state machine (especially if the tool is going t= o > > > take encoding liberties).- Hide quoted text - > > > The rule is that any time there is a logic path from an asynchronous > > input to more than one device that samples the signal(s), you must > > first synchronize the signal before feeding it into any logic path. > > > This condition occurs for any state machine with more than flip flop > > used to implement the state. > > > KJ > > I agree that this is a rule that should be generally followed, but > there are exceptions. For example, a gray-coded state machine is > sometimes used to tolerate an asynchronous control input. If timing is > violated on any of the flops, the machine will stay at the current > state or transition to the next state. In practice, Gray code is not very useful for state machines that have many branch possibilities. Remember that you need to make sure that any possible transition only changes one state bit. This is easy for any linear or loop state logic like a counter, but most control logic state machines will have multiple-way branching from many of the states. So unless you add intermediate states to prevent more than two-way branching from any node you can still run into problems with asynchronous inputs to the Gray coded machine. The added states would give the same delay as a synchronizer flop on the input signal.Article: 149012
On Sep 20, 2:01=A0pm, Darol Klawetter <darol.klawet...@l-3com.com> wrote: > On Sep 20, 3:49=A0pm, KJ <kkjenni...@sbcglobal.net> wrote: > > > > I agree with your last paragraph. It's typically better to use a > > > couple of flops on an asynchronous control signal than trying to > > > handle it within the state machine (especially if the tool is going t= o > > > take encoding liberties).- Hide quoted text - > > > The rule is that any time there is a logic path from an asynchronous > > input to more than one device that samples the signal(s), you must > > first synchronize the signal before feeding it into any logic path. > > > This condition occurs for any state machine with more than flip flop > > used to implement the state. > > > KJ > > I agree that this is a rule that should be generally followed, but > there are exceptions. For example, a gray-coded state machine is > sometimes used to tolerate an asynchronous control input. If timing is > violated on any of the flops, the machine will stay at the current > state or transition to the next state. This is not a rule that "should be generally followed". It is rule that must ALWAYS be followed! If a signal from a "foreign" clock domain is used in a conditional inside a state machine, the state machine will fail (eventually). This is NOT a metastability problem. It is because the time to decode the D inputs of the state bits is different for each D input, and if the "foreign clock" signal is used in a conditional it will go to more than one D input. There is no way to ensure that the D inputs are all valid at the same time, and when the clock happens while one is valid and the other is not state machine gets corrupted. This syndrome is independent of the coding method of the state variable. Synchronizing all inputs to a state machine to the state machines clock will prevent that. Not optional. Sorry. RKArticle: 149013
In comp.arch.fpga, Gabor <gabor@alacron.com> wrote: > > In practice, Gray code is not very useful for state machines that have > many > branch possibilities. Remember that you need to make sure that any > possible transition only changes one state bit. This is easy for any > linear or loop state logic like a counter, but most control logic > state > machines will have multiple-way branching from many of the states. > So unless you add intermediate states to prevent more than two-way > branching from any node you can still run into problems with > asynchronous inputs to the Gray coded machine. The added states > would give the same delay as a synchronizer flop on the input signal. Did that many years ago for a CPLD design! Draw a big Karnaugh map, try put in your states with the minimum possible dummy states and only single bit changes. Great fun, better than cross-words. :-) But agreed, wouldn't do that now (although, I might ...), and back then it only worked if the machine was not too complex. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) Most public domain software is free, at least at first glance.Article: 149014
On Sep 20, 4:31=A0pm, d_s_klein <d_s_kl...@yahoo.com> wrote: > On Sep 20, 2:01=A0pm, Darol Klawetter <darol.klawet...@l-3com.com> > wrote: > > > > > > > On Sep 20, 3:49=A0pm, KJ <kkjenni...@sbcglobal.net> wrote: > > > > > I agree with your last paragraph. It's typically better to use a > > > > couple of flops on an asynchronous control signal than trying to > > > > handle it within the state machine (especially if the tool is going= to > > > > take encoding liberties).- Hide quoted text - > > > > The rule is that any time there is a logic path from an asynchronous > > > input to more than one device that samples the signal(s), you must > > > first synchronize the signal before feeding it into any logic path. > > > > This condition occurs for any state machine with more than flip flop > > > used to implement the state. > > > > KJ > > > I agree that this is a rule that should be generally followed, but > > there are exceptions. For example, a gray-coded state machine is > > sometimes used to tolerate an asynchronous control input. If timing is > > violated on any of the flops, the machine will stay at the current > > state or transition to the next state. > > This is not a rule that "should be generally followed". =A0It is rule > that must ALWAYS be followed! > > If a signal from a "foreign" clock domain is used in a conditional > inside a state machine, the state machine will fail (eventually). > > This is NOT a metastability problem. =A0It is because the time to decode > the D inputs of the state bits is different for each D input, and if > the "foreign clock" signal is used in a conditional it will go to more > than one D input. =A0There is no way to ensure that the D inputs are all > valid at the same time, and when the clock happens while one is valid > and the other is not state machine gets corrupted. =A0This syndrome is > independent of the coding method of the state variable. > > Synchronizing all inputs to a state machine to the state machines > clock will prevent that. > > Not optional. =A0Sorry. > > RK RK, You'll have to convince me that the rule "must ALWAYS" be followed, independent of state encoding. It still seems to me that gray coding could work - the machine either stays in the current state or transitions to the next state because only one bit is transitioning. If the input to this bit's register meets timing, then the machine goes to the next state; if timing is not met, it either goes to the next state or stays at the current one. The other bits are static.Article: 149015
Darol Klawetter <darol.klawetter@l-3com.com> wrote: (snip, someone wrote) >> > > This condition occurs for any state machine with more than flip flop >> > > used to implement the state. (snip) >> This is not a rule that "should be generally followed". It is rule >> that must ALWAYS be followed! >> If a signal from a "foreign" clock domain is used in a conditional >> inside a state machine, the state machine will fail (eventually). (snip) >> Synchronizing all inputs to a state machine to the state machines >> clock will prevent that. (snip) > You'll have to convince me that the rule "must ALWAYS" be followed, > independent of state encoding. It still seems to me that gray coding > could work - the machine either stays in the current state or > transitions to the next state because only one bit is transitioning. > If the input to this bit's register meets timing, then the machine > goes to the next state; if timing is not met, it either goes to the > next state or stays at the current one. The other bits are static. For a gray code state machine, and only one unsynchronized input, maybe it can work. Assuming that there are more than two states, you have to ask about the interaction with other inputs, and the possible state transitions. If it is already going from state 1 to state 3, and the unsynchronized input goes from state 1 to state 0, then it seems possible that you might end up in state 2. So, for each synchronous state transition, you have to figure out what transition occurs if the unsynchronized input changes just before or just after the clock. For more than one, you have to figure out the transition for all combinations of inputs changing just before or just after the clock, even if there is supposed to be an order. I suppose if you do that, then I believe that it can work. -- glenArticle: 149016
On Sep 20, 9:04=A0pm, Darol Klawetter <darol.klawet...@l-3com.com> wrote: > On Sep 20, 4:31=A0pm, d_s_klein <d_s_kl...@yahoo.com> wrote: > > > > > On Sep 20, 2:01=A0pm, Darol Klawetter <darol.klawet...@l-3com.com> > > wrote: > > > > On Sep 20, 3:49=A0pm, KJ <kkjenni...@sbcglobal.net> wrote: > > > > > > I agree with your last paragraph. It's typically better to use a > > > > > couple of flops on an asynchronous control signal than trying to > > > > > handle it within the state machine (especially if the tool is goi= ng to > > > > > take encoding liberties).- Hide quoted text - > > > > > The rule is that any time there is a logic path from an asynchronou= s > > > > input to more than one device that samples the signal(s), you must > > > > first synchronize the signal before feeding it into any logic path. > > > > > This condition occurs for any state machine with more than flip flo= p > > > > used to implement the state. > > > > > KJ > > > > I agree that this is a rule that should be generally followed, but > > > there are exceptions. For example, a gray-coded state machine is > > > sometimes used to tolerate an asynchronous control input. If timing i= s > > > violated on any of the flops, the machine will stay at the current > > > state or transition to the next state. > > > This is not a rule that "should be generally followed". =A0It is rule > > that must ALWAYS be followed! > > > If a signal from a "foreign" clock domain is used in a conditional > > inside a state machine, the state machine will fail (eventually). > > > This is NOT a metastability problem. =A0It is because the time to decod= e > > the D inputs of the state bits is different for each D input, and if > > the "foreign clock" signal is used in a conditional it will go to more > > than one D input. =A0There is no way to ensure that the D inputs are al= l > > valid at the same time, and when the clock happens while one is valid > > and the other is not state machine gets corrupted. =A0This syndrome is > > independent of the coding method of the state variable. > > > Synchronizing all inputs to a state machine to the state machines > > clock will prevent that. > > > Not optional. =A0Sorry. > > > RK > > RK, > > You'll have to convince me that the rule "must ALWAYS" be followed, > independent of state encoding. It still seems to me that gray coding > could work - the machine either stays in the current state or > transitions to the next state because only one bit is transitioning. > If the input to this bit's register meets timing, then the machine > goes to the next state; if timing is not met, it either goes to the > next state or stays at the current one. The other bits are static. Must always is too strong. Your Gray coding example is valid and deals with the issue of coherency, since only one FF changes state based on the asynchronous signal. It does not address the issue of metastability, but that is becoming much less of an issue because of how fast the FFs have become. There have been post by either Austin or Peter that they have a problem even trying to make it happen so that they can measure it. What I would say is that unless you have a very good reason not to, you want to just use a synchronizing circuit before you do anything else with an asynchronous signal. The cost is usually low, and the consequences of doing it another way and getting it wrong are high. I have debugged this sort of problem before, and it is a painful process. FPGAs and their tools assume that you are using synchronous techniques, and can work against you if you deviate from that path. They can take your carefully coded Gray state machine and change it to one hot if you don't have the proper constraints, or they might replicate state registers if they have a high enough fan out and you did not turn off that option. Regards, John McCaskill www.FasterTechnology.comArticle: 149017
On Sep 20, 7:04=A0pm, Darol Klawetter <darol.klawet...@l-3com.com> wrote: > On Sep 20, 4:31=A0pm, d_s_klein <d_s_kl...@yahoo.com> wrote: > > > > > > > On Sep 20, 2:01=A0pm, Darol Klawetter <darol.klawet...@l-3com.com> > > wrote: > > > > On Sep 20, 3:49=A0pm, KJ <kkjenni...@sbcglobal.net> wrote: > > > > > > I agree with your last paragraph. It's typically better to use a > > > > > couple of flops on an asynchronous control signal than trying to > > > > > handle it within the state machine (especially if the tool is goi= ng to > > > > > take encoding liberties).- Hide quoted text - > > > > > The rule is that any time there is a logic path from an asynchronou= s > > > > input to more than one device that samples the signal(s), you must > > > > first synchronize the signal before feeding it into any logic path. > > > > > This condition occurs for any state machine with more than flip flo= p > > > > used to implement the state. > > > > > KJ > > > > I agree that this is a rule that should be generally followed, but > > > there are exceptions. For example, a gray-coded state machine is > > > sometimes used to tolerate an asynchronous control input. If timing i= s > > > violated on any of the flops, the machine will stay at the current > > > state or transition to the next state. > > > This is not a rule that "should be generally followed". =A0It is rule > > that must ALWAYS be followed! > > > If a signal from a "foreign" clock domain is used in a conditional > > inside a state machine, the state machine will fail (eventually). > > > This is NOT a metastability problem. =A0It is because the time to decod= e > > the D inputs of the state bits is different for each D input, and if > > the "foreign clock" signal is used in a conditional it will go to more > > than one D input. =A0There is no way to ensure that the D inputs are al= l > > valid at the same time, and when the clock happens while one is valid > > and the other is not state machine gets corrupted. =A0This syndrome is > > independent of the coding method of the state variable. > > > Synchronizing all inputs to a state machine to the state machines > > clock will prevent that. > > > Not optional. =A0Sorry. > > > RK > > RK, > > You'll have to convince me that the rule "must ALWAYS" be followed, > independent of state encoding. It still seems to me that gray coding > could work - the machine either stays in the current state or > transitions to the next state because only one bit is transitioning. > If the input to this bit's register meets timing, then the machine > goes to the next state; if timing is not met, it either goes to the > next state or stays at the current one. The other bits are static. It is more basic than that: When the asynchronous input drives the D of asingle flip-flop, there can be no problem. The flip-flop either changes or does not. When, however the asynchronous input drives the D of more than one flip-flop, then inevitably there will come the moment where one gets set and the other one gets reset. Usually, this is a disaster, and can and should be avoided by synchronizing all data inputs. There might be special designs that can tolerate this ambiguity, but the best practice is to synchronize. I have been preaching this for over 40 years, but there are always new designers who fall into the old trap... Peter AlfkeArticle: 149018
On Sep 20, 7:38=A0pm, Peter Alfke <al...@sbcglobal.net> wrote: > On Sep 20, 7:04=A0pm, Darol Klawetter <darol.klawet...@l-3com.com> > wrote: > > > > > > > On Sep 20, 4:31=A0pm, d_s_klein <d_s_kl...@yahoo.com> wrote: > > > > On Sep 20, 2:01=A0pm, Darol Klawetter <darol.klawet...@l-3com.com> > > > wrote: > > > > > On Sep 20, 3:49=A0pm, KJ <kkjenni...@sbcglobal.net> wrote: > > > > > > > I agree with your last paragraph. It's typically better to use = a > > > > > > couple of flops on an asynchronous control signal than trying t= o > > > > > > handle it within the state machine (especially if the tool is g= oing to > > > > > > take encoding liberties).- Hide quoted text - > > > > > > The rule is that any time there is a logic path from an asynchron= ous > > > > > input to more than one device that samples the signal(s), you mus= t > > > > > first synchronize the signal before feeding it into any logic pat= h. > > > > > > This condition occurs for any state machine with more than flip f= lop > > > > > used to implement the state. > > > > > > KJ > > > > > I agree that this is a rule that should be generally followed, but > > > > there are exceptions. For example, a gray-coded state machine is > > > > sometimes used to tolerate an asynchronous control input. If timing= is > > > > violated on any of the flops, the machine will stay at the current > > > > state or transition to the next state. > > > > This is not a rule that "should be generally followed". =A0It is rule > > > that must ALWAYS be followed! > > > > If a signal from a "foreign" clock domain is used in a conditional > > > inside a state machine, the state machine will fail (eventually). > > > > This is NOT a metastability problem. =A0It is because the time to dec= ode > > > the D inputs of the state bits is different for each D input, and if > > > the "foreign clock" signal is used in a conditional it will go to mor= e > > > than one D input. =A0There is no way to ensure that the D inputs are = all > > > valid at the same time, and when the clock happens while one is valid > > > and the other is not state machine gets corrupted. =A0This syndrome i= s > > > independent of the coding method of the state variable. > > > > Synchronizing all inputs to a state machine to the state machines > > > clock will prevent that. > > > > Not optional. =A0Sorry. > > > > RK > > > RK, > > > You'll have to convince me that the rule "must ALWAYS" be followed, > > independent of state encoding. It still seems to me that gray coding > > could work - the machine either stays in the current state or > > transitions to the next state because only one bit is transitioning. > > If the input to this bit's register meets timing, then the machine > > goes to the next state; if timing is not met, it either goes to the > > next state or stays at the current one. The other bits are static. > > It is more basic than that: > When the asynchronous input drives the D of asingle flip-flop, there > can be no problem. The flip-flop either changes or does not. > When, however the asynchronous input drives the D of more than one > flip-flop, then inevitably there will come the moment where one gets > set and the other one gets reset. Usually, this is a disaster, and can > and should be avoided by synchronizing all data inputs. > There might be special designs that can tolerate this ambiguity, but > the best practice is to synchronize. > > I have been preaching this for over 40 years, but there are always new > designers who fall into the old trap... > Peter Alfke Well, and then there is the rare case of metastability, where even a single flip-flop driven with an asynchronous D input, can change its Q output asynchronously, perhaps moving up and down within a few ns. Peter AlfkeArticle: 149019
Not sure if it helps but Mentor's Supportnet newsletter had this today: Problems running ModelSim from Xilinx ISE Symptoms You have more than one simulator loaded, or have replaced an existing one with another. The Xilinx compiled libraries are not valid for the simulation. The default information in the modelsim.ini file are not correct. Causes The Xilinx project accesses ModelSim from 3 different places, and if they don't all point to the same install problems can arise. Solution Check that the following all point to the same install: 1) Environment path (check that only one path points to the modelsim executables), remove all others. You should have one valid path (Xilinx uses it to create the default modelsim.ini file using "vmap -c". 2) Xilinx top Menu: Edit --> Preferences -- ISE General -- Integrated Tools -- Model Tech Simulator: Example: <Drive>:\<install_dir>\win32pe\modelsim.exe 3) Window "View": M Simuilation; highlight the device in the Hierarchy window. Expand Design Utilities and Right Mouse Button 'Compile HDL Simulation Libraries' and select 'Process Properties': fill in the GUI as needed. Hans www.ht-lab.com "muhammad_umer" <muhammad_umer@n_o_s_p_a_m.n_o_s_p_a_m.comsats.edu.pk> wrote in message news:9qCdnQs3T8C0igrRnZ2dnUVZ_jednZ2d@giganews.com... > Hi, > I am developing a design using xilinx ISE 12.1. I have selected ModelSim > 6.5 SE for simulations. When i run behavioral simulation following error > comes: > > > ---------------------------------------------------------------------------- > * udo file already exist (pie_tb.udo). It will not be re-generated. > * creating main do file (pie_tb.fdo) for Behavioral Simulation... > > executing 'D:/modeltech_6.5/win32/vsim.exe -version' to get the > mti_se version... > > Modelsim version is 6.5 > * determining pre-compiled simulation library path information... > > using mapping file set by MODELSIM env (D:\modeltech_6.5)... > > ERROR: Unable to read the "D:\modeltech_6.5" file. > Reason: couldn't open "D:\modeltech_6.5": permission denied > > INFO: Simulation process aborted! > ---------------------------------------------------------------------------- > > any one can please help me and tell me why this problem arise. I am using > administrator account and i also give full rights to modelsim folder. Also > my integrated tools option is set correctly point towards modelsim exe > file. > please guide me how to remove this error. > Thanks in advance > > --------------------------------------- > Posted through http://www.FPGARelated.com >Article: 149020
Hi everyone! I've been trying to constraint a carry chain in my Virtex 4 design to be placed so that the least significant part of it is in the upper part of a CLB. By doing this I would have a little more "near" sites for the lower significant input registers. I want to run ny design fairy fast and the carry chain is critical. If it's relevant I am using Xilinx software. I've managed to do this with fixed location constraints from PlanAhead, but I would want to use RLOC (and BEL) constraints in my vhdl source instead since my component is instantiated several times. I've only been able to use RLOC constraints for this Virtex 4 design with XY coordinates. Is it somehow possible to have CLB relative RLOC constraints with Virtex 4? Or is their any other nice solution to my problem?Article: 149021
Here's another reason to NEVER NEVER NEVER feed asynchronous signals to a state machine: Sometimes the back end tools in the default settings will replicate flip flops to make routing easier. For instance if there is a gray code counter bit that goes to many places, the router could split it into two equivalent bits that go to half as many places each. I have been burned by this before on input deglitching flip flops, where the tool replaced it with two parallel deglitching flip flops, which is obviously not much of a deglitcher. There are tool directives to prevent this from happening, but I like to do the two deglitchers in series trick so that the first deglitcher will only have one load, so it can't be split. -JeffArticle: 149022
Concise summary of this thread: While it's possible to build a state machine that safely handles asynchronous inputs, there's seldom any justification for it. Failure to synchronize inputs invites trouble and violates decades of solid design practice.Article: 149023
Back when we used PALs with only 4 or 8 registers (16R4 & 16R8 PALs), separately synchronizing an input to a state machine was not always an option from a resource point of view. As has been said above, there are methods* of making a state machine tolerant of asynchronous inputs. But these methods are exceedingly difficult to verify and/or review, especially when compared to the use of an explicit synchronizer. Furthermore, these methods are often thwarted by optimizations that are commonplace in FPGA synthesis tools. Finally, given the abundance of registers in FPGAs, there is very rarely an acceptable excuse to not use an explicit synchronizer. * the rules for these methods are: 1. All transitions of the state machine in response to an asyncrhonous reset, including any registered outputs, must result in the possibility of only one bit changing. 1A. A state may have conditional destinations of itself and an adjacent (on a K-map) state 1B. A state may have two separate destination states that are adjacent to each other, but then staying in the current state is not allowed. 1C. A state may change a single-bit registered output based on the async input, but it cannot also transition out of that state at the same time. An old trick to effectively "re-use" a synchronizing register was to set a flag while in the state based on the async input, then transition out of the state based on the flag a clock later. The same flag could be used in multiple states, for multiple different async inputs. The hoops we jumped through to get things done in 8 flops or less... AndyArticle: 149024
On Sep 20, 7:28=A0pm, John McCaskill <jhmccask...@gmail.com> wrote: > On Sep 20, 9:04=A0pm, Darol Klawetter <darol.klawet...@l-3com.com> > wrote: > > > > > On Sep 20, 4:31=A0pm, d_s_klein <d_s_kl...@yahoo.com> wrote: > > > > On Sep 20, 2:01=A0pm, Darol Klawetter <darol.klawet...@l-3com.com> > > > wrote: > > > > > On Sep 20, 3:49=A0pm, KJ <kkjenni...@sbcglobal.net> wrote: > > > > > > > I agree with your last paragraph. It's typically better to use = a > > > > > > couple of flops on an asynchronous control signal than trying t= o > > > > > > handle it within the state machine (especially if the tool is g= oing to > > > > > > take encoding liberties).- Hide quoted text - > > > > > > The rule is that any time there is a logic path from an asynchron= ous > > > > > input to more than one device that samples the signal(s), you mus= t > > > > > first synchronize the signal before feeding it into any logic pat= h. > > > > > > This condition occurs for any state machine with more than flip f= lop > > > > > used to implement the state. > > > > > > KJ > > > > > I agree that this is a rule that should be generally followed, but > > > > there are exceptions. For example, a gray-coded state machine is > > > > sometimes used to tolerate an asynchronous control input. If timing= is > > > > violated on any of the flops, the machine will stay at the current > > > > state or transition to the next state. > > > > This is not a rule that "should be generally followed". =A0It is rule > > > that must ALWAYS be followed! > > > > If a signal from a "foreign" clock domain is used in a conditional > > > inside a state machine, the state machine will fail (eventually). > > > > This is NOT a metastability problem. =A0It is because the time to dec= ode > > > the D inputs of the state bits is different for each D input, and if > > > the "foreign clock" signal is used in a conditional it will go to mor= e > > > than one D input. =A0There is no way to ensure that the D inputs are = all > > > valid at the same time, and when the clock happens while one is valid > > > and the other is not state machine gets corrupted. =A0This syndrome i= s > > > independent of the coding method of the state variable. > > > > Synchronizing all inputs to a state machine to the state machines > > > clock will prevent that. > > > > Not optional. =A0Sorry. > > > > RK > > > RK, > > > You'll have to convince me that the rule "must ALWAYS" be followed, > > independent of state encoding. It still seems to me that gray coding > > could work - the machine either stays in the current state or > > transitions to the next state because only one bit is transitioning. > > If the input to this bit's register meets timing, then the machine > > goes to the next state; if timing is not met, it either goes to the > > next state or stays at the current one. The other bits are static. > > Must always is too strong. Your Gray coding example is valid and deals > with the issue of coherency, since only one FF changes state based on > the asynchronous signal. =A0It does not address the issue of > metastability, but that is becoming much less of an issue because of > how fast the FFs have become. =A0There have been post by either Austin > or Peter that they have a problem even trying to make it happen so > that they can measure it. > > What I would say is that unless you have a very good reason not to, > you want to just use a synchronizing circuit before you do anything > else with an asynchronous signal. =A0The cost is usually low, and the > consequences of doing it another way and getting it wrong are high. =A0I > have debugged this sort of problem before, and it is a painful > process. =A0FPGAs and their tools assume that you are using synchronous > techniques, and can work against you if you deviate from that path. > They can take your carefully coded Gray state machine and change it to > one hot if you don't have the proper constraints, or they might > replicate state registers if they have a high enough fan out and you > did not turn off that option. > > Regards, > > John McCaskillwww.FasterTechnology.com If, and only if your gray code is implemented with a gray counter. Otherwise, it's just another state coding, and the idea that only one bit changes at a time is false. 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