CROSS CLOCK vhdl

The current habit of the tribe is to use a dc fifo. This includes ready made synchronisation and data transfer so you don't start from scratch.

Your data at 40MHz is written to fifo(when valid) and read out on 24MHz. You will need some thought on how best to control the flow so that fifo is never empty or full.

Hello,

Thank you for your answer.

Excuse me becuase I am a litle bit ignorant in this topic.:D

What about the 2 stage Flip Flop synchronizer, they are not useful in this case?:cool:

Pls, look the attached file.

Thank you:)

DABG

Hi,

The fifo circuitry contains hidden multistage synchronisers(defaults to 2 or use more, setup by you in the megawizard). So don't worry about what others say. Use the fifo to read/write. The main headache is getting the flow under control, this depends on input burstiness, fifo size, fill-level ...etc. Try it and you will learn. I assume you have clk enable(or data valid at input) and you expect steady 24MHs data rate at fifo output.

Looking at your picture, I can see clk is 160MHz out of PLL. There is some confusion here. I assume you first want to cross from 40MHz to 24MHz...nevertheless if you want to cross from 40 to 160 the same rule applies but your data cannot change rate unless you interpolate or decimate.

It looks that Your design produces 160MHz but doesn't seem to use it.

If your intention is cross from 40 to 160(rather than 24) then you can do that directly using fifo or it might be a good idea to have another clk 40MHz from PLL(synchronised with 160) and read fifo out as this eases the problem of flow control, though these two clks are not locked to each other i.e. they will get drift away with time and you still need some flow control.

Once you want to go in 160MHz domain, then you either keep data rate(valid every 4 clks) or upsample by 4 if you want it valid every clk(depends on your purpose)

My thoughts:

1 - Truly the dual-clock FIFO is the easiest, most reliable method for cross-domain bus data transfer. If you just had one or two signals it might be a different story.

2 - A second option (assuming you are crossing from 40Mhz to 160Mhz) would be to use the 40MHz clock as the input to a PLL to produce your 160MHz clock. Then, your two clock domains would actually be related. In this case you can cross the clock domains fairly easily without a FIFO.

3 - The third option alluded to by kaz is to cross from 40MHz to 160MHz but where the 160MHz clock is not related to the 40MHz. In this case, I still vote for the dual-clock FIFO. You could perform oversampling but 4x is kind of a low oversampling rate. And of course you would have to write the oversampling block which I suspect you don't really want to do.

Recommendation: Use the dual-clock FIFO unless your two clock domains are related. In which case I'd still use the FIFO unless you are really trying to save RAM resources.

Jake

Hello,

Thank you KAZ and JACK,

Yes, the 2nd option that explains Jake is the easiest, however the problem is that I am using a Cyclone 2, and the CLK_40MHz that comes from the camera is not phisically connected to a dedicated CLK pins. (We designed the board, and we did not take it not account, ups:o)

"only dedicated CLK pins on the FPGA

can be connected to clock input ports of PLLs" Cyclone 2 manual.

And I got this error after compiling:

"Port type INCLK of the PLL is assigned to a location which is not

connected to port type INCLK of any PLL on the device".

I guess I will try to develop the option that use the FIFO.

I need to work at 160MHz because then I am going to store the last 20 lines of the image in the internal memory (m4k), and I need to read 4 random pixels to implement a Bilinear Interpolation.

Still I am confused with the two flip flop stage synchronizer, in which cases are them useful?

Thank you.

Directly crossing clock domains with a synchronizer is useful in many cases. Most particularly when you are passing single control signals between clock domains or sampling an asynchronous signal at low data rates.

The reason two registers are used is because when you sample the signal in the first flip-flop, there is the possibility that the input is rising or falling which can push the flip-flop into metastability. Latching the signal into a second flip-flop increases the probability that the latched output signal will be stable. Adding even a third flip-flop increases the probability more.

This type of resynchronization is not as useful when you are dealing with large data buses. It certainly can be done under the right circumstances and constraints but in your particular case, it's just not worth the effort.

Jake

Hello,

It means that for cross clock the data I should use the FIFO, and to cross clock domain the signal LVAL, FVAL and DVAL I should use 2-ff stage synchronizer?

Can I mix the 2 techniques?:confused:

----------------------------------------------------------

clk domain 1 // >>---------------------->>// clock domain 2

-----------------------------------------------------------

data[9:0] ----------->> fifo ------------>> data_sync[9:0]

FVAL --------------->> 2-ff sync------->> FVAL_sync

DVAL --------------->> 2-ff sync------->> DVAL_sync

LVAL --------------->> 2-ff sync------->> LVAL_sync

fval=frame valid

dval=data valid

lval=line valid

Thank you,

DABG

Anything that passes through dc fifo will pass through the fifo's two stage synchroniser.

If you want to pass other signals with data just add an extra bit to width of fifo for every extra bit you want to pass.

You may use a signal at write only and not pass it e.g. data valid can be used as write enable to fifo without the need to pass it through if at the read side every clk is valid data, this seems unlikely in your case. So it depends on your application.

Having said that I foresee difficulty in flow control because your fifo clks are not locked.

You will need to have a plan for that. I suggest not passing data valid(if I understand its purpose). Instead use it as write enable. Watch your fifo getting near empty, stop reading and generate your own data valid now accordingly in the new domain.

As such fifo is not allowed to get full either unless it is too shallow because your read clk is free to read at any clk edge.

I frequently pass video across clock domains using dual-clock fifos. Simply use the empty signal on the read side of the FIFO as a datavalid or clock enable. All other signals should be passed as data through the FIFO.

Jake