cross clock timing constraints

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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
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

Re: cross clock timing constraints
Quoted text here. Click to load it
Does the reset reset things synchronously or asynchronously? Async needs
more care. Much, much more!

Quoted text here. Click to load it
Oh dear. So the clocks aren't on the dedicated global clock resource? That
would be bad. Very, very bad.

Quoted text here. Click to load it
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?

Quoted text here. Click to load it
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

Quoted text here. Click to load it
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.

Re: cross clock timing constraints
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.


Re: cross clock timing constraints
Quoted text here. Click to load it
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.
Quoted text here. Click to load it
Don't just try to use them. Actually use them. You can use the FPGA editor
tool to confirm this.
Quoted text here. Click to load it
It depends. You say you use the CLKFX outputs? So the frequency and phases
of the clocks can be different.
Quoted text here. Click to load it
...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
There's more effort up front, but it works for me >trillions of times a day!
YMMV, Syms.

Re: cross clock timing constraints
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

Site Timeline