CROSS CLOCK vhdl

[Altera_Forum]

Hello Everybody, 

 In my application I receive images from a camera that uses CAMERA LINK protocol (100 fps).  The camera generates its own 40 MHz pixel clock. All the data's from the camera are synchronized with this clock (d[8:0],lval, dval, fval).   In the FPGA I am working with a different clock at 24MHz, it comes from a xtal.  In my algorithm I need to work at 160 MHz, I need to implement a Bilinear interpolation.  QUESTION:   :confused: How must I manage the cross clock domain? :confused:  Thank you.  DABG

[Altera_Forum]

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.

[Altera_Forum]

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

[Altera_Forum]

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)

[Altera_Forum]

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

[Altera_Forum]

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.

[Altera_Forum]

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

[Altera_Forum]

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

[Altera_Forum]

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.

[Altera_Forum]

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.

[Altera_Forum]

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

[Altera_Forum]

--- Quote Start ---  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  --- Quote End ---     Thats exactly what I do - works great. I see you mention you are doing billinear interpolation.. why do you need a 160 MHz clock? I get the feeling you are buffering up a line and then doing 4 reads to get your 4 pixel values.   If you're only doing billinear interpolation (and nothing else) you can run it at 40MHz and just cope with a 1 line latency (which you'll get at 160MHz anyway). The pixels you need come from a line delay memory and a few registers, all clocked at input pixel frequency.  Not knowing the full spec of the system, I cant really comment. But I assume you have a billinear interpolate as part of a Warp function?

[Altera_Forum]

Hi, 

 However, Altera adviced against getting any fifo full or empty during normal operation. Isn't this still the case?

[Altera_Forum]

Whats wrong with emptying a FIFO? if you have proper data flow control, and dont just expect valid data on every clock cycle (ie. you have a data_valid control signal) you shouldnt have a problem. 

 with video, you get about 80/20 valid data to blanking ratio, with the blanking region not valid. You get a long period of inactivity that is likely to empty your fifos.  What is the reason for not allowing fifos to get empty? I can understand the full problem (espcially if its video, you will lose syncronisation on the data) with pixels being dropped.

[Altera_Forum]

It seems that altera has two remediies for their old warning: 

 1) an almost_empty flag   2) protection circuitry(extra logic)   This what they say(dc fifo user guide)   --- Quote Start ---   Underflow and overflow circuitry protections are enabled by default to prevent FIFO data corruption. Turning on the option from the FIFO MegaWizard plug-in disables the protection circuitry.    When the protection circuitry is disabled, writing to a full FIFO can corrupt the FIFO dataand reading from an empty FIFO can return unknown data and produce unpredictable future results; however, when the protection circuitry is disabled, the FIFO megafunction uses fewer device resources.  --- Quote End ---   

[Altera_Forum]

--- Quote Start ---  It seems that altera has two remediies for their old warning:   1) an almost_empty flag   2) protection circuitry(extra logic)    --- Quote End ---    I see what you mean. I wonder if this is the same for LOOKAHEAD style fifos.  But the above problem can surely be avoided (on the read side at least) by anding any read control with !empty, then you will never try and read from an empty fifo.

[Altera_Forum]

Yes ANDing will do certainly. In some cases you don't want to AND because you have to honour a given request rate. But anyway, the protection circuitry is there by default. So it is not a problem really.

[Altera_Forum]

It should be understood that this... 

  --- Quote Start ---  Underflow and overflow circuitry protections are enabled by default to prevent FIFO data corruption. Turning on the option from the FIFO MegaWizard plug-in disables the protection circuitry.  When the protection circuitry is disabled, writing to a full FIFO can corrupt the FIFO dataand reading from an empty FIFO can return unknown data and produce unpredictable future results; however, when the protection circuitry is disabled, the FIFO megafunction uses fewer device resources.   --- Quote End ---    does not mean that you shouldn't empty or fill a FIFO. You just can't write to a full FIFO or read from an empty FIFO without corrupting the contents. And the obvious reason why is that the read or write counter will roll over.  So, you can either instruct the megawizard to perform protection for you or you can perform the protection yourself (which is what I typically do). Typically you have the empty and full signals anyway so you can perform flow control. It's certainly not hard to gate your write and read signals with the full and empty signals.  Jake

[Altera_Forum]

Hello Guys,  

 I had done the cross clock domain, I used the FIFO that you sugested me. It works.  About the person that ask me about the frequency, it is 160 MHz, because I need to do the interpolation using 4 random pixels.  I attach here the RTL, maybe it can be usefull to someone else in the future.  Also in the attached file you can see the output of my system.  Thank you.  DABG