02-23-2011 07:52 AM
Hello,
I have a question regarding the cross clock domain crossing.
I have three signals that are outputs of statemachine which runs at 40 Mhz.
1. Data bus of 32 bit
2. start signal
3. pulse signal of 1 clock wide
Now i have to transfer these three to 125 Mhz clock domain. I also want to keep the pulse signal 1 clock wide even with the 125 Mhz clock.
I was planning to use a FIFO .
Shall I combine all the three signals to a 35 bit data bus at the input of fifo and then decode the output of fifo back to separate the three signals.
or
Is there any other efficient way of doing the same thing.
Thanks.
02-23-2011 08:53 AM
@abdullahansari wrote:
Hello,
I have a question regarding the cross clock domain crossing.
I have three signals that are outputs of statemachine which runs at 40 Mhz.
1. Data bus of 32 bit
2. start signal
3. pulse signal of 1 clock wide
Now i have to transfer these three to 125 Mhz clock domain. I also want to keep the pulse signal 1 clock wide even with the 125 Mhz clock.
I was planning to use a FIFO .
Shall I combine all the three signals to a 35 bit data bus at the input of fifo and then decode the output of fifo back to separate the three signals.
or
Is there any other efficient way of doing the same thing.
Thanks.
I'd do the FIFO.
02-23-2011 09:00 AM
So,is it best to create fifo instead of using a fifo that xilinx provides for this situation?
02-23-2011 09:05 AM
@abdullahansari wrote:
So,is it best to create fifo instead of using a fifo that xilinx provides for this situation?
I don't know what Xilinx provides. For this sort of thing, a simple LUT-based FIFO with enough entries to cover the requirements is fine.
02-23-2011 09:27 AM
a,
There is nothing 'simple' about clock domain crossing. I would use a soft IP FIFO (IP core), or the hardened BRAM/FIFO.
Only there are you using something that is debugged, and works, which already has taken into account the problems of metastability, synchronizers, etc.
You can always use SRLs, and design your own synchronizers, but unless you are an aysnchronous expert, I suggest you not do that.
Usually there is one engineer in a whole team, who does the async stuff. Even a standard cell master-slave DFF is an asynchrnonous design: if you get that wrong, your asic/assp/fpga/SOC (whatever) is garbage and does not work.
Asynchronous design: DFF, synchronizers, FIFO's -- let the experts do it!
02-23-2011 11:02 AM
While I agree that a FIFO will do the trick, this is a case that doesn't necessarily require one
since the clock frequencies are different enough that you could generate a clock enable
in the 125 MHz clock domain that can adequately sample signals created in the 40 MHz
clock domain. You could think of it as a FIFO with a depth of 1. If I did this in Verilog
it would look something like:
// Generate a signal that toggles on every rising edge of clk40. This is
// required because you can't reliably route the clock itself to the non-clock
// loads in the 125 MHz clock domain:
reg ck40_toggle;
always @ (posedge clk40)
if (rst) ck40_toggle <= 0;
else ck40_toggle <= ~ck40_toggle;
// Sample the togging signal in the 125 MHz clock domain and
// detect both edges. The actual sampling point created by the
// trailing egde of ck_ena will be between 2 and 3 periods of
// clk125 after the toggle data changes. You may need a FROM : TO
// constraint on the sampled signals to deal with the minimum
// delay of 16 ns going from clk40 to clk125.
reg [1:0] toggle_syn;
reg ck125_ena;
always @ (posedge clk125)
if (rst)
begin
toggle_syn <= 2'b0;
ck125_ena <= 0;
end
else
begin
toggle_syn <= {toggle_syn,ck40_toggle};
ck125_ena <= toggle_syn[1] ^ toggle_syn[0];
end