Doubt in Asynchronus Circuit design

I can't really see your diagram, but there are a couple of points I can make.

1) Is your 1 MHz domain synchronous to the 100 MHz domain - i.e. do you just divide 100 MHz clock by 100 to make 1 MHz clock? If not and your domains are truly asynchronous you need to be sure your sampling of registers is coherent when you change clock domains. For example if you are looking at 8 bits of data written synchronously to 100 MHz and just put all 8 bits through 2 flip- flops on the 1 MHz clock, you can sometimes get some bits from before and other bits from after a write event. Since your clocks have a very large difference in frequency, it may make sense to sample the 1 MHz clock in the 100 MHz domain and make a clock enable after the rising edge of 1MHz clock that lasts one cycle of the 100MHz clock. Use this clock enable and the 100 MHz clock as the first stage of your synchronizer to ensure data coherency. 2) Generally when you need to indicate an update to an asynchronous process you need handshakes. You can have a register that is set when any of the data registers are written in the 100 MHz domain, and cleared when the 1 MHz domain acknowledges the change. This can have a race condition if changes happen frequently since the reset signal could come just as another update happens. Another approach is similar to a FIFO controller where you count up with one counter on any 1 MHz clock period where an update has occured, and count up with another counter when the 1 MHz logic recognizes the change.

HTH, Gabor

Thanks Gabor for these valuable replys. First of all, how can i draw waveform diagrams in this group? I have seen lot of sessions with neat diagarm, my diagarm was also good when i draw it on the tesxt window but when in converted to the html page it somehow got distotred. How can i share my diagrams with you?

Comming to your second suggestion, that ack from the 100MHz domain to the 1MHz domain is exactly what i want, but how we can do that? The flag which indicates that is set on 100MHz clock and rest on 1MHz clock. Is that possible to use two clocks in a single FF?

I am thinking of another process similar to your suggestion that the flag will be set at 100Mhz, but will also be reset at 100MHz when an edge happend at the 1MHz signal. But these information that an edge happend at the 1MHz location is also needed to be synchronised to the

100MHz domain. That will delay it by two more cycles in the 100MHz domain.

Your first suggestion i could not understand fully. What will happen if i use only two flops operting at 1MHz clock. Please explian me why some bits will be differnt from other bits. My two clocks are fully asynchronus.

1) Use a fixed size font when drawing it. 2) Make sure your client does cut the line automatically at a certain number of character. And in any case try to keep all the line quite short (likee ~75 char)

Is it possible to synchronise the 1MHz clock to the 100MHz domain and keep that clock for all the operations like ADC. (This may not be possible according to the spec i have but i am asking a general doubt).

Easy: just oversample and edge-detect it...

signal enable_1MHz: std_logic; ... process (clk_100MHz) variable resync1, resync2, delay: std_logic; begin if rising_edge(clk_100MHz) then delay := resync2; resync2 := resync1; resync1 := clk_1MHz; if (resync2 and not delay) = '1' then enable_1MHz

I also arrived in the same solution, though i reduced the number of sync flops to two like "if (resync1 and not resync2)". My thought was now we have some fast FFs and this enable signal is going to be used only at the next +ve edge of 100MHz, so by that time we get a valid signal in the "enable_1MHz". Will this assumption work?

The extra FF provides protection against metastable events on "resync1". If your fast clock were, let's say, 20MHz then I definitely would not bother with the extra FF. The question is: how likely is it for a setup/hold violation on "resync1" to induce enough metastability to push its settling time out to about 9ns? A third FF is much cheaper than the time it takes me to look up, and calculate, the math :-)

--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Actually its worse than that. Since the tools usually work with a PERIOD constraint, how can you be sure that you have anywhere near 9 ns of slack in this path to handle this event? Probably

3 ns is enough for most metastable events, but how do you even know you have 3 ns slack without looking through the placed design afterwards? In the 2 flip-flop case there is a high probability that the path between flops will have a large slack at 100 MHz since there are no intervening LUTs. If you want to go overboard, you can hand place the synchonizing flops to ensure lots of timing slack.

Regards, Gabor

The idea was to use one clock and an asynchronous reset. This is why I also suggested that there was a problem concerning multiple events. It could happen that the asynchronous reset masks out a new update. If you want to be sure to handle all updates, but are not worried about responding twice to the same update, you can reverse the process and use an asynchronous set when the update occurs, and synchronous reset on the 1 MHz clock when the update is processed. Still you need to be careful because the set event can come very close to the

1 MHz clock edge.

This is generally the preferred method. Keeping handshake in one clock domain removes the race conditions. However now you need to deal with the possibility of a new update occuring just after an edge of 1 MHz but before the reset signal. Make sure that the 1 MHz process sees the new updates by re-asserting the flag (or not clearing it) if another update has occured within 3 100 MHz cycles prior to the reset signal.

This is important. Two flops are the approved method of synchronizing a single signal to avoid metastability issues. However this does not deal with data coherency. If your registers are single bits with independent functions, or are known to only change one bit at a time (like Grey code) then the 2-stage synchronizer is all you need. But what if you are transferring binary data like an 8-bit number? Now if in one clock domain the number goes from 01111111 to 10000000 binary, the value has changed by 1 count, but all the bits have changed together (in that domain). This does not mean that the bits will change together as sampled in the other clock domain. Varying path delays can cause some bits to meet the setup to the 1 MHz clock when others don't. Then even though there may be no metastability on any of the sampled bits, you could easily read a value like 00000000 binary if for example the highest bit had a longer path delay than the lower 7. The second synchronizing register would not fix this, only delay the

00000000 value by another 1 us.

A much better approach is to use a register clocked by 100 MHz with a clock enable generated like your handshake reset just after the rising edge of 1MHz. This register would be guaranteed to update coherently, but would have nearly 1 us of setup to the next 1 MHz rising edge.

Hi Gabor, You know this already, but for the record:-

NET "numa_numa" MAXDELAY 1ns;

or somesuch.

HTH, Syms.

i am wondering how we can process it if both the frequencies were of

100 MHz and fully asynchronus. with all the possibility that one may be 100.1MHz and the other 99.9 MHz. And if i want send in a register from one to another how we can do that.

That's what asynchronous FIFOs do for a living. But note that a consistent difference in input and output frequencies will inevitably cause the FIFO to go either full or empty. But they signal that to you, even with a warning: almost full, or almost empty.

Asynchr> i am wondering how we can process it if both the frequencies were of

When you are transferring data from one clock domain to another with roughly the same clock rate, it is often best to use a FIFO. I know that's not really an answer to your question, because the design of the FIFO itself must deal with all the problems that you have been considering; but it's well-established stuff, there are plenty of reliable ready-to-use solutions out there, and it meets the majority of requirements very well.

Obviously, if you are sending data from a 100.1MHz clock domain to a 99.9MHz clock domain, it's not possible to send one data value per clock - otherwise the amount of data stored in the FIFO will increase without limit. Again, there are various well-known tricks for working around that:

- Batch-up the source data, perhaps in pairs, so that the average data rate is one double-word per two clock cycles. You can easily deal with this on the slightly slower side.

- Ensure that all data streams have some "padding" so that you can drop a data value occasionally, and have just a little less padding on the slow-clock side. And, of course, many data sources are bursty so that there are significant dead times in which the receiving side can drain the FIFO.

--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.