Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

How to decide between Handshake & fifo in async design

Status
Not open for further replies.

sakshi gupta

Full Member level 1
Full Member level 1
Joined
Jun 30, 2010
Messages
96
Helped
4
Reputation
8
Reaction score
4
Trophy points
1,288
Location
India
Activity points
1,810
on what basis we can decide ,we have to use fifo or Hanshake technique for data transfer between async clock domains ?
 

Re: How to decide between Handshake & fifo in async des

sakshi gupta said:
on what basis we can decide ,we have to use fifo or Hanshake technique for data transfer between async clock domains ?

Could you please be more clear ? Coz Hankdshake can be implemented with FIFO.
 

Re: How to decide between Handshake & fifo in async des

If I need to transfer data from one clock domain to other ,on what basis I will decide which synchronisation techique I should use to avoid metastability . What will be factors on basis of which I decide to choose FIFO or Handshake technique ?

Hope my query is clear now .
 

Re: How to decide between Handshake & fifo in async des

sakshi gupta said:
If I need to transfer data from one clock domain to other ,on what basis I will decide which synchronisation techique I should use to avoid metastability . What will be factors on basis of which I decide to choose FIFO or Handshake technique ?

Hope my query is clear now .

OK I see now, you mean difference between synchronzers based on dff for clock domain crossing and Handshake protocol. I think that this depend on the application itself.
If you have a parallel data to transfert use the Handshake protocol, this let you ovoid using synchronizer for each bit, so you gain many transistor and consequently some watts.
 

Re: How to decide between Handshake & fifo in async des

I have few queries :

1) By parallel data ,u mean multi-bus data

2) In which scenario we should use FIFO ?

3) we can use handshake or fifo if data transfer is between
a.slow to fast domain
b. fast to slow domain
 

Re: How to decide between Handshake & fifo in async des

can anybody help me in this ?
 
1/ Yes
2/ This depends on your budjet (area/power consumption)
3/It can be done for both direction but you have to ensure that you will not loose data as consequence of asynchronism.
 
Re: How to decide between Handshake & fifo in async des

sakshi gupta said:
on what basis we can decide ,we have to use fifo or Hanshake technique for data transfer between async clock domains ?

It's possible to use either, both, or neither, depending upon what exactly you're doing.

If the receiving logic has a sufficiently fast clock relative to the data rate, it may be possible to have the sender always drive its data and a single "data ready" signal long enough for the receiver to notice it. It will be okay if the data ready signal and actual data change simultaneously if both will be valid for at least two receiver clocks. If desired, the data_ready signal could toggle on each byte, to avoid having to have two detectable edges per byte.

Handshaking without other latching may be used in cases where the sender is willing to hold data on its output until it has been received, but doesn't know how long that will take, and the receiver is willing to wait for the sender to provide data after it's requested (but again doesn't know how long that will take).

A queue allows a sender to offload its data as fast as it wants, without regard for the receiver, unless or until the queue becomes full, and allows a receiver to grab data as fast as it wants, without regard for the sender, whenever the queue is not empty. An important caveat with a queue, however, is that the sender must know what the receiver will want before the receiver says it wants it. If the sender can't know what data will be required until the receiver is wanting to hear it, a queue will be useless.
 
Re: How to decide between Handshake & fifo in async des

usually if the sender has a higher data rate than the reciver, then you have to use a FIFO. Size of this fifo depends on the difference in data rates between sender and the reciver. In this case you need to calculate the difference in the data rates to know exactly how big your FIFO needs to be.

In cases where the sender and receiver clocks are the same but there is a skew between them, then you can use a double flop synchronizer to handshake the data accross the clock domains.
 
Re: How to decide between Handshake & fifo in async des

rakko said:
In cases where the sender and receiver clocks are the same but there is a skew between them, then you can use a double flop synchronizer to handshake the data accross the clock domains.

If the sender and receiver clock are not synchronized, I wouldn't expect a double-flop synchronizer to be sufficient unless the receiver gets at least two cycles for each unit of data to be transferred or certain other conditions are met. Essentially, the receiver has to know on what cycle it can reliably grab data. Suppose the receiver's clock cycle is 100ns (10MHz), and the combined sample/hold/jitter times are 8ns. A sender cound send data at 8MHz if it outputs the data for 10ns without strobing it, then hits the strobe and holds the data for 115ns before starting to output the next unit. If the data switches precisely when it's sampled, its value won't be used until 100ns later, when it will have had plenty of time to stabilize. If the clock switches precisely when it's sampled, the data will have been present for 10ns (so it will have been sampled cleanly), and the data will be present for another 115ns so even if the clock isn't detected until the next cycle.

Note that to achieve such a data rate, a unit of data must be sent on each edge of the synchronized clock. If the original clock cycles once for each unit of data, it could be fed through a divide-by-two before the synchronizing flip flop.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top