Clock signal jumps two states with one edge #625
Comments
|
Neither the nMigen language nor the FPGA synthesis toolchains guarantee that clocks generated with logic in this way are glitchless. In other words, the behavior you're seeing is not a bug, but an allowed interpretation of the language semantics. If you give a bit more detail about the problem you're solving, I could suggest a different way of approaching it. |
|
Thank you for the quick response! I'm implementing a SpaceWire IP core, and the standard defines this method of sending the clock in those two wires in that specific way. I thought the problem was with the generation of the signals, so I tried changing w2 from comb to a DDR flip-flop, but this kept happening, so clearly the problem is with the receiver and its retrieval of the clock. Currently I'm using a workaround that solves the problem in the simulations, but won't work in the actual FPGA. |
|
Thanks for the help. I ended up solving it with this change:
|
I'm trying to create a module that receives two wires and retrieves a clock signal from them as clk2 = w1^w2 to drive said module's FSM. w1 is driven from sync, w2 is driven from comb. The issue I'm having is that I can see clk2 and it's exactly the same as the original clock, but when w2 maintains the same value for more than one clock period, the clock edge in that period acts as two fast edges, making the FSM jump two states instead of one.
I have a test case in this repository. https://github.com/AlanVek/nMigen-Cocotb-bug
Please, let me know if I wasn't clear enough with the explanation. Thank you.
Here are some images with the outputs of the test case. The signal "counter", which should be incremented by one in each state, is sometimes incremented by two. And those glitches coincide with the edge in which w1 is changing and w2 is stable.
The text was updated successfully, but these errors were encountered: