Independent clock FIFOs

When you have two independent clocks (133 and 150 MHz), the difference of the two clock periods heas no meaning whatsoever. These two clocks will have any phase- or delay-difference imaginable. They just "walk over each other". That's what makes the design so complex. Meeting timing constraints between independent clock is an exercise in futility. Don't do it! Ignore any complaints! Peter Alfke, Xilinx

Thanks, I TIG'ed those nets, but unfortunately some new ones in the FIFOs then had the same issue. I will have to figure out why ISE is confused.

Cheers, Rob.

snipped-for-privacy@gmail.com schrieb:

It there somewhere an option to disable cross clock domian timing analysis? AFAIK there is such an option in Alteras Quartus-II Software. But ISE from Xilinx??

Regards Falk

Hi Falk,

The Xilinx timing analyser only examines paths which are constrained, so the problem here is (I think) that a spurious constraint has found its way into the system. Usually the constraints are either user-entered or generated by the synthesis tool (and then used as a guide by the subsequent mapping, placement and routing stages).

XST has an option to ignore paths between different clock domains for timing, and not create constraints based on its analysis of such paths.

In this case, the paths are within a FIFO module generated from Coregen. It sounds to me like these constraints have been written out by coregen (into the .ngc netlist, probably), when they're actually unnecessary. The workaround is to TIG these paths manually; the solution is to get the IP fixed so these spurious constraints are not propagated into the design in the first place.

Cheers,

-Ben-

Good luck, everyone! If you fix this without side effects, I would love to see an answer.

I believe the problem arises when the two clocks are related and the Xilinx timing tool figures this out. It tracks the clocks from the same DCM and says "aha!, a relationship!" and then does the timing analysis.

Telling the user to ignore timing errors is silly. Now I have to peruse the timing report manually each time to be sure the errors are ones I can ignore, or write some complicated script to do it for me.

Yes, you can use TIGs, but my experience is weird things happen when you use to many of these. But then, weird things seem to happen in Xilinx timing on complex designs routinely anyway so maybe that doesn't mean anything.

Am I a bit frustrated? Yes. I've been fighting these kind of issues in a Virtex 2vp30 design with 99% of slices (but only 60% of LUTs) used for months.

Seems like the timing tool should also be smart enough to say "Aha! Coregen version of asynchronous fifo, let's be careful about some paths."

Does your fifo have to be asynchronous?

-- Mike Treseler

Yes, data has to cross clock domains--an asynchronous fifo seemed the simplest method

Rob, you mntion that you do not use the FULL and EMPTY flags. In that case, the asynchronous FIFO design becomes trivial. Just have an address counter in each clock domain, and connect one to the write port, the other one to the read port. No Gray counters, no comparators, no anti-metastable re-synchronizers. All that complexity is only needed to generate reliable flags.

Timing constraints that cross the clock domain are inherently meaningless, since there is no fixed timing relationship. Peter Alfke,Xilinx (from home)

Yes, I can get away without using those flags, but I do use the VALID flag for reading. Surely that is just NOT( EMPTY ) and so requires the same precautions?

Rob