SV Blog SystemVerilog Blog
Related Articles
We’ve been through a simple synchronizer and constraints. Now we need to move data from one clock domain to another. There are a couple of ways to do this, but one thing I am hoping to see is efficiency. So you might be thinking FIFO, but try to think of how else it might be done.
Question
You need to pass some control information from one clock domain to another, say a 32 bit bus with a wr_en control signal. The data will be written infrequently, so you don’t have to worry about it coming too fast for you to pass it in a simple way.
This could be done with a FIFO, but FIFOs take a lot of resources. Note I said that the data is infrequent and you have time to pass it simply. Given the above diagram, you could use a pulse synchronizer.
wr_req is converted into a a toggle through U6, U7 and U8. The heart of a pulse synchronizer is a toggle synchronizer, U1, U2, U3 and U5. The output from U3 is a single RX_CLOCK pulse. Data must be held constant until captured, so either it must be guaranteed stable or an acknowledge is sent back from TX to RX (not shown). Writing constraints is similar to the simple synchronizer, with an addition to do with the data:
Data has at most 2 RX CLOCK cycles of delay to settle. To be conservative, apply a 1 clock cycle max delay, which gives an entire clock cycle to settling time.
The circuit above could be reduced by generating a toggle wr_en, thus removing a clock of latency and also a FF.
(Sorry for the quick post today. My daughter has a play this week. If you spot any errors, shout out and I’ll update.)
Latch write en signal & data on the tx clock, resync the write en signal using double dff thus becoming write en resync. Use this last signal to store the latched data into some registers running on tx clock.
This is solution is ok if rx clock verifies Shannon condition.possibly dff for the tx clock latched data might be remove if rx clock frequency >4 tx clock frequency?
Resync really becomes funny when Shannon condition is not verified and the data to transfer shall be kept until latched in the destination clock domain.
Also the xbits asynchronous timer would require special gray counter methodology to guarantee reading with a maximum of +/- 1 cycle error.
I am note an FPGA designer, but an ASIC one. I have been through all this issues.
I have a challenge for you: what resync strategy would you apply for a 512 bits RTC 1 Hz counter (representing time and date) accessible by a 32 bits CPU running at 20MHz or more? Gate count would be a KPI in this challenge. Time shall be read no error allowed.
I’ve done my share of ASIC design, although long ago when 100Mhz was fast and 100K gates was the knee of the curve of manufacturing.
In the counter example above, since 512 bits would require 16 clocks to read, you would want to take a snapshot of the 512 bits upon reading say the lower bits of the 512. Like you said, you’d likely want a grey coded register in the 1Hz domain so that at most you’d be off by 1 second if the counter was changing when read (you are reading a stored value (either new or last and since only one bit can change, you will either read the new or last value if you happen to catch it when changing, the same principal as a FIFO address crossing domains). Since you would need 2×512 registers on the fast side, it is expensive.
The only other gate efficient, yet messy way would be to capture the grey coded value with a single rank of FFs but wait a few clocks before using the data to allow the meta stability to settle.
Just a couple of off the cuff ideas, if you have a better solution, I’m open to hearing it.