Re: Independent clock FIFOs

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."



On Wed, 24 May 2006 14:30:43 +0100, Ben Jones wrote:

Hi Falk,

"Falk Brunner" <Falk.Brunner@xxxxxx> wrote in message
news:4dj434F1avlqmU1@xxxxxxxxxxxxxxxxx
rob.misc@xxxxxxxxx schrieb:
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.

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??

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-

.

Relevant Pages

  • Re: FPGA changes behaviour when the resources usage percentage changes
    ... Even if the design does not ... I mean, with the same code and constraints, only ... example) the constraints are always met and the timing report does ... how is it possible that the FPGA ...
    (comp.arch.fpga)
  • Re: Debugging SDRAM interfaces
    ... do these timing constraints look sane? ... The key to getting good I/O timing is to ensure the tools place the I/O ... For each I/O pin you will see a lot of information including the I/O ...
    (comp.arch.fpga)
  • Re: UK report on GPS vulnerabilities seems to overlook NTP
    ... and synchronising with diverse enough time sources that ... "GNSS timing is important for telecommunications applications. ... While ground-based clocks are ... telecom's idea of local time accurate? ...
    (comp.protocols.time.ntp)
  • Re: Timing problem in ModelSim, Post-Route Simulation.
    ... The problem is not in having multicycle or false paths in a design; ... is in having constraints that relax timing requirements on those paths ... any of the above constraints, great, problem solved. ...
    (comp.arch.fpga)
  • Re: Problem with Microblaze max clocking
    ... If you add a TIG timing constraint to your UCF (see your constraints guid ... I'm using EDK 9.1i and in my design I use a Microblaze core (v ... In every system that I create, the maximum clocking that I can acheive ... I don't have time constraints in my ucf file. ...
    (comp.arch.fpga)