Debug one-hot SM w/ 2 states active: look at actual SM bits?

[Altera_Forum]

Basically Signal Tap is reporting that under certain conditions a State Machine has two states active. My impression is that SignalTap does some encoding of the actual SM bits when it reports the active states. How can we capture the actual underlying state machine bits to better understand what is going on? I don't see anything other that the state names when I list the signals in SignalTap. 

 Details:  We have an AHDL SM with many states that was synthesized with one-hot encoding. When I add the states (via their name) to SignalTap, it seems like the value is set to 1 whenever the state machine is in that state. This is different than the encoding reported by the SM viewer tool. For our reset state "IDLE" the encoding reports all bits are 0's, while SignalTap returns a 1 in the IDLE signal when we are in the idle state. Therefore it seems like SignalTap is doing some encoding when it reports the states.  The problem we see is that while in the IDLE state, a signal that NOT used in the IDLE state (but is used in other states) is pulled very weakly low to high. When this signal finally goes high SignalTap reports a second state is also active along with IDLE. Obviously using a floating signal to determine which state to go to next will result in unpredictable operation. BUT since this signal is not used in any of the state transition equations to leave the IDLE state (verified via the SM viewer transitions equations) it should have no effect in the IDLE state. All the signals involved in leaving the IDLE state are synchronous and steady during this time.  What we expect is that the actual underlying state machine bits are corrupted but SignalTap's encoding hides that. Perhaps when SignalTap reports IDLE the actual underlying bit pattern is invalid but the encoding hides that.  Stefan

[Altera_Forum]

Note that SMs are generally not encoded as one-hot but as "Altera one-hot". What this means is that the bit representing your reset bit will power-up to 0 and have not gates put before and after(also called not-gate pushback). So taking an encoding that you think of as: 

 0001 0010 0100 1000  If you look at the actual registers directly, it will be: 0000 0011 0101 1001  As I mentioned, a not-gate is added before and after this reset bit, which is absorbed for free into upstream and downstream logic. So all logic based on this bit will see it as the inverse, i.e. it will be active high. And all logic that would send it to be active high will get inverted and send it low. The net sum is your state-machine works exactly as it should in the system, and the only "strange" thing is that if you look directly at the register with SignalTap, it looks like it's inverted.  Another place to look is in the Compilation Report -> Analysis & Synthesis -> State-Machine Optimizations, and it should show the encoding there(assuming synthesis recognized it as a state-machine). This is also in the .map.rpt.  I'm not sure exactly how SignalTap interprets states though. It might try to do things in the intended manner(show a 1 when in that state), or the actual representation(where IDLE is 0 only in the IDLE state). It sounds like you're seeing the first case.   As for your issue, is the behavior consistent or occasional. Haveing a floating input control a SM is not just an issue that it's inconsistent behavior, but the SM registers could go metastable if this input transitions near a clock edge, and SMs(as most control logic) do not handle metastability and can cause all sorts of strange issues.

[Altera_Forum]

The representation of the initial state in SignalTap may depend on the netlist type of the signal, in most cases, it's shown with correct polarity, inactive state = L. Without using the state machine safe coding option, you have a certain chance that the state machine gets caught in an illegal state, once it was entered e. g. due to timing issues.  

 Generally, a rich source of timing problems and all kinds of unexpected logical behaviour is the processing of asynchronous external signals. If they are used in more than one logical term without an additional synchronisation FF, the state of the signal may be seen different in two places for the same clock edge. A signal, that advances a SM state, may be seen in the expression, that sets the new state and not seen where the old state should be deasserted. As a result, both states may get active. The probability of such events increases with slow transitioning signals, but also exists with good quality digital signals.

[Altera_Forum]

Rysc provides a good description of what I am seeing. Based on the State Machine Viewer I was expecting the "reset" state to be all 0's, but in SignalTap I was seeing a "1" for the reset state. So it would appear that the value that I am watching is the inverted one. Perhaps as FvM indicates it would make a difference in which type (pre vs. post synthesis, etc.) I choose in SignalTap. 

 Certainly as you both describe having an unknown or unstable value when the state machine is clocked can lead to all sorts of problems. However, I had thought that if I had combinatorial (A AND B) and A is 0, then it would not matter if B was unstable; the output would always be 0. Perhaps I am wrong here. This effectively describes my situation. The second state that becomes active has transitions that involve the unstable input but only from states other than the current state. I had thought that even though the input was unstable, the equation could never be TRUE since the state bit in the equation would be FALSE.  In the State Machine Viewer and the Compiler report I can see the encoding and the transitions from each state (reset is all 0's). Is there any place that I can see the full equation for a state bit? i.e. if there are 4 ways to get into a state I can see the full optimized equation rather than just the 4 individual transition equations?  FYI: The signal in question is bi-directional and I was driving inactive and disabling at the same time. I added an extra state so the the signal is driven inactive instead of weakly pulled inactive and the problem appears solved.  Is there any easy way to indicate when more than one state is active so that you can trigger in SignalTap, light an LED, etc?  Thanks   Stefan

[Altera_Forum]

You can look in the Chip Editor or the Technology Map Viewer(I think) to get equations. You can also write out an equations file(.eqn) for your whole design. To be honest, all of these are painful to really figure out what something is doing and I would recommend against. It sounds like driving the SM with synchronous signals fixes the problem, which is really good design practice anyway.