1. Home
  2. Field-Programmable Gate Arrays
  3. Synchronizing multibit bus - 2

Synchronizing multibit bus - 2

Dear Mr Tschaggelar,

let us assume the following situation:

I have an 16bit bus which is synchronous to an external clock 30MHz. If I sychronize this bus with a set of three stage-flip flop-chains clocked by an internal generated 90MHz clock will the sampled pattern be wrong?

I do not know if you were talking about asynchronous bus without any clock or if you were talking about asynchronous bus with regard to the FPGA internal sampling clock.

Thank you for sheding some light on it.

Best regards André

>ALuP>> In one of the last posts I read the following: >> >>>It is true though that a more common mistake is to synchronize a >>>multibit bus without realizing that this will result in invalid values >>>except in the case of Gray-coded logic. >> >> Does that mean that using a multi-stage flip flop chain to synchronize >> the asynchronous input bus will lead to invalid values ? >Since the indivdual bits of the multi bit bus may change at >their own time, sampling at odd intervals may result in >sampled bus pattern that are just temporary in nature. >Thus the sampled pattern may be wrong. >Only the gray code is save to sample at odd intervals as >only one-bit changes are allowed. > >Apart from that, the multi bit bus could also contain its own >clock, showing when the data is valid. > >Rene >-- >Ing.Buero R.Tschaggelar -
formatting link
>& commercial newsgroups -
formatting link
Reply to
ALuPin
Loading thread data ...

Andre,

The "Moving Data Across Asynchronous Clock Boundaries" article by Peter Alfke shows how to synchronize a bus by implementing a simple handshake protocol.

formatting link

HTH,

-- Georgi

Reply to
Georgi Beloev

There is no guarnatee that your data will be correct. Your 90Mhz clock is asynchronous to your 30Mhz clock. It doesn't matter how many synchronizing flops you send it through ... if on the first set of flops, 1 bit does not meet the setup time and all the others do ... you will latch the wrong data and this will be propagated through all your other synchronization flops.

one technique to solve this issue is to utilize a single bit signal that indicates that data is valid ... send this signal through your synchronizing flops and then when you sample this valid in your internal clock domain ... it guarantees that the data will also be sampled properly.

Mike

Reply to
Mike Lewis

Only using 2-stage ganged synchronizer flops to move a data bus from one clock domain to another is GUARANTEED to fail.

A metastable event on any of the synchronizers will delay the transition on that bit causing a wrong value to appear on the bus in the receiving clock domain.

Now if your data is an incrementing Gray code pattern, where only one bit changes per increment, you can use synchronizers over a bus, but this is a special case. (We use this in implementing asynchronous FIFOs where we need to pass read and write pointers across the clock domains - but that's another story...)

In general you need to use either a handshake protocol or an asynchronous FIFO to move data across clock domains. Implementations of handshake protocol based clock domain crossers are cheap in terms of LEs but have a high latency penalty while FIFOs are more expensive while enabling streaming data transfers.

-Paul

Reply to
scheidt

What have you gained by running the bus through 3 stages of FF? You have solved the metastability problem, but you haven't solved the problem of how to get a data word from one clock domain to the other.

The simple approach is to use a FIFO. Just look in your cookbook.

That's a lot of resources for such a simple problem. So you can build a special purpose bus transfer module.

The general idea is that the source domain togles a data-ready FF and loads the data into a holding register. Data-ready goes through the classic pair of metastability FFs. Then it goes to an edge detector to enable copying the data from the holding register to the output clock domain.

One problem is that 3 is a small number. Can you get through all that logic before the holding register gets reloaded? Maybe, but I think it requires pushing logic back into the "metastability" FFs. 90 MHz is not fast with modern logic. You might have enough time to do that.

Plan two is to use 2 holding registers. If the data-ready FF is high, load into one register. When it's low, load into the other. That gives you 6 clocks on the output side to grab the data before it changes. Should be simple.

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.
Reply to
Hal Murray

Sorry I was unclear. You need the clock(or alike) together with the data. Say the data is valid when the clock(or alike) is high. That makes it much simpler. Discard everything unless the clock(or alike) is high.

If the clock is the real clock of the data, then the data may be valid from the rising slope. Some delay and perhaps pulseforming circuit may be required.

Rene

Reply to
Rene Tschaggelar

As Peter mentioned : A bus that allows only one bit changes is boring and rather limited.

Rene

--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net
Reply to
Rene Tschaggelar

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.