1. Home
  2. Field-Programmable Gate Arrays
  3. cross clock timing constraints

cross clock timing constraints

Hi all,

Would appreciate a lot if i could get some help on this. Got a couple of questions and have read a lot of those messages on this group on cross clock domain design. Infact I have changed my design to include asynchronous fifo in my design. Now data crossing happens only by the fifo.

But first the clocks. There are three clocks. And the three clocks are getting generated from three DCMs using CLKFX outputs. with the same input clock to three of them

Presently my design works but not always. Sometimes there is the wrong output when i reset the design. i dont think this is the problem of the reset. Also the design is stable at lower frequencies.

The things I have done and experimented are

1.)used LOWSKEWLINES constraint on all the clocks and reset.(my design started working only after this.)oh yeah as well i am using 92% of the slices that is after i included the FIFO. this is ok.

2.)have mentioned the period constraint for the input clock to the DCM as well as the PERIOD constraints on the output clocks of the DCM.

3.) included the BRAMS_PORTA constraint for the FIFO. and then associated the clock nets for each of the ports of the FIFO. i think this is how to do it. but in this none of the nets nor instances are included and analyzed. here is the output of the timing analyzer

Timing constraint: TS_groupa1 = PERIOD TIMEGRP "clk_fpga" 18.182 nS HIGH 50.000000 % ;

0 items analyzed, 0 timing errors detected.

4.) I think the only timing problem affecting my design is the cross clock domain in the FIFO itself. Slack: -11.613ns (requirement - (data path - clock path skew + uncertainty)) Source: receiver/buffercatch/fifo/BU545 (FF) Destination: receiver/buffercatch/fifo/BU216 (FF) Requirement: 0.001ns Data Path Delay: 6.132ns (Levels of Logic = 5) Clock Path Skew: -5.482ns Source Clock: clk_fpga rising at 478487.558ns Destination Clock: clk_datain rising at 478487.559ns Clock Uncertainty: 0.000ns

I am not sure on how to constrain this. The from to constrain and the multicycle constraint will not work with my design because the clocks are not related and there is not a definite time period after which the other clock appears. the clocks are 55,34and 40MHZ.

If anyone feels this problem has been addressed before in a tech document like the xilinx app or anything please let me know the same.

Thank you cheers vasu

Reply to
design
Loading thread data ...

Does the reset reset things synchronously or asynchronously? Async needs more care. Much, much more!

Oh dear. So the clocks aren't on the dedicated global clock resource? That would be bad. Very, very bad.

In my experience, this means that the analyser has analysed no items. So getting no errors isn't difficult to achieve. I suggest including more things in your timing group. Maybe BRAMS_PORTB could be a start?

Well, you've designed your async fifo properly, yes? (Opinion on this newsgroup is divided as to the ease of this task, as you may have recently read!) So, you don't need a clock to clock timing constraint, per se. You might consider some MAXDELAY ones on your signals which can be metastable, to help reduce the probability of an occasional error. BTW, a 1ps requirement can be tricky to meet. You might want to read about TIG constaints.

There's a good XAPP about self-addressing fifos. I use those when I have to. They're great for keeping everything in the same clock domain, except at the I/O interface. Cheers, Syms.

Reply to
Symon

Many questions. Let me just answer the one onFIFOs :-) An asynchronous FIFO provedes perfect isolation between the two clock domains. I call it a shock absorber or rubber band. You just interface to the two sides, each in their own clock domain, and the FIFO will take care of the data transport. It sends a synchronized EMPTY signal to the read side,and a synchronized FULL signal to the write side. Everything is synchonous to the clock domain that is involved. That's the beauty of it. You do not have to think. Peter Alfke

Reply to
Peter Alfke

I am using the ASYNC fifo by Xilinx coregenerator. and that is where the signal crosses clock domains. I cannot really apply MAXDELAY constraints I believe. I have included BRAMS portb constraints also from the beginning. its the same no change.

one thing i did try is to remove LOWSKEWLINES and try to use clock buffers. still no difference.

i am wondering that peter spoke about the FIFO in general and didnt give any suggestions on why there are no items analyzed. and regarding the low requirement. I have read about the low requirement before but then the time period i am mentioning is in even number and i believe the DCM takes care of the rest of the timing requirements because all of the clocks used in the design are outputs of DCM.

However thank you both for the suggestions.

vasu

Reply to
design

Hi Vasu, Try using the floorplanner to find out the 'real' names of the instances and/or nets you want included in your timing groups. You can also use the timing analyser to "query timegroups" to find out if you've succeeded.

Don't just try to use them. Actually use them. You can use the FPGA editor tool to confirm this.

It depends. You say you use the CLKFX outputs? So the frequency and phases of the clocks can be different.

...although they did a fat lot of good!! ;-) So, FWIW and for next time this type of design crops up, allow me to tell you how I try to do designs with multiple clocks. As each clock and it's associated data enter the device, I connect them to the input of a 'self addressing fifo' from XAPP291. I then make a new fast(ish) clock rate which clocks the core of the design, i.e. all the logic that processes the incoming data. This master clock clocks the output of the aforementioned SA fifo. The fifo provides an enable in the master clock domain. Likewise, as each different clock and data leave the device, another SA fifo converts from the master clock domain to the output domain. The SA fifo provides an enable to the masterclock domain. The evil clocks are limited to single pins on a BRAM, so no skew problems, everything 'inside' runs at some master clock rate, enabled at the correct rates. There's more effort up front, but it works for me >trillions of times a day! YMMV, Syms.

Reply to
Symon

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.