synch3 has three stages of retiming registers, to minimize metastability-created setup uncertainty in the "rising" and "falling" outputs. Here is a synchronizer module (Verilog) that I use in one design: clk is 100 - 300 MHz d is a slower asynchronous signal, needs to transition at less than clk/2 q is just the input re-synchronized to the "clk" domain (and delayed) rising and falling are one "clk" period wide, used for input edge detection. I speak VHDL, not Verilog, so I'd implement this as something along the following lines: You'll need to find a way to deal with this, if the delay matters at all. There is, of course, a couple of clocks' worth of latency. The output of the second D-type should, therefore, be reliable. We also work on the assumption - and it is just an assumption - that even if it goes metastable, it'll have settled to either a 0 or a 1 in good time before the next active clock edge. Instead, we ensure that the potentially metastable output feeds exactly one input (the next D-type in the chain), so this can't happen. If it changes state at an unexpected time, the difference in propagation delay could easily mean that one subsequent logic input sees it as a '0' while the other sees a '1', with hilarious consequences). (As an aside - imagine, for example, the case where the metastable signal is used in two places, one physically near the latch and one on the other side of the die. The non-synchronous input (your start or stop signal) connects to the first D input, and we know that the Q output may indeed go metastable, which would risk causing complex logic to misbehave if it were used directly in multiple places. This consists of one or more clocked D-type latches, connected in series (like a shift register). To handle this effect - which is fundamental to the device physics, and not something that can be simply 'designed out' by the FPGA manufacturer - we use a thing called a synchroniser chain. This is termed 'metastability' and it's guaranteed to cause flaky behaviour in your FPGA. Strange things can happen, like the output changing briefly to one state before settling some time later to another even without a further clock pulse arriving. If they're not, the behaviour of the gate will be unpredictable. If they're met, the gate will work reliably. Every logic gate, whether discrete or built into an FPGA, has setup and hold times that must be respected relative to the clock. (The same is also true of every other signal that's an input to the FPGA and that's not properly synchronised to the master clock that's driving your logic, of course). This is very common, and needs handling correctly. The fundamental issue here is that you don't know the timing relationship between your start / stop signals and the master clock that drives your state machine.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |