Stratix III FPGA: Problem using Asynchronous FIFOs

I get those frequencies using TimeQuest Analyser from Quartus, but when I try to test my design using modelsim (with the .vho and .sdo files) it doesn't work for those frequencies. So, can the frequencies be wrong?

Referring to the sdc file, how can I set the output delays?

--- Quote Start ---

I get those frequencies using TimeQuest Analyser from Quartus, but when I try to test my design using modelsim (with the .vho and .sdo files) it doesn't work for those frequencies. So, can the frequencies be wrong?

--- Quote End ---

No the frequencies are correct. But you need to carefully generate your input signals, i.o.w. they must respect proper setup times as reported byt the Datasheet Report in TimeQuest.

Now I try to avoid Gate Level Simulation in Timequest. A: because of the input setup requirements, the output delays. B: you can not probe every signal as the ones optimized away are niot there anymore. Furthermore the ones you can watched are 'real time' and are shifted in regards with the input clocks, so if you are debugging a design it gets difficult to see cause and action. And C: it is painfully slow compared to RTL simulation. Of course if you are designa a physical module like a Memory PHY you utlimnately have to run Gate Level Simulation, although TimeQuest can tell you all about it.

--- Quote Start ---

Referring to the sdc file, how can I set the output delays?

--- Quote End ---

You could read Rysc's Timequest doc, you can find it on the wiki:timequest user guide (http://www.alterawiki.com/wiki/timequest_user_guide)

--- Quote Start ---

My design works in functional simulation, so I'm trying to test it in Gate Level simulation before I introduce it into the board. But it works only in the best case (Fast and 0 ºC) and fails in the others, so it isn't going to work in the FPGA.

--- Quote End ---

I think it is in the testbench. I have a different style and I don't see immediately how the input signals behave. Maybe you can send be a .qar(with the inputdata.txt file)? I'll take a deeper look then.

Dear Drumont,

when there's a timing violation, Modelsim puts a yellow marker in the the waveform window and prints a warning message to the log.

Which register is suffering the timing violation?

Regarding I/O constraints: to get you started with simulation setting the max & min delays to zero is good enough.

Of course, you need to make sure that it's true. That is, the inputs your testbench provides to your UUT must be aligned with with clock your testbench provides to the UUT.

If I read the .VHD correctly, you're using a FIFO with a 5 stage synchrnonizer, correct?

IIRC, DCFIFO actually has two different use cases

a) 1 synchronizer state, for when the write and read clock are related

b) 2 or more synchrnonizer stages, for unrelated clocks

If you go with option "b", the DCFIFO function automatically sets false path exceptions on some of it's internal clock crossing logic -- it's not possible to do timing analysis on unrelated clocks anyway.

Thus, it's possible to get a green light from TimeQuest and see failures in gate level simulation.

If your use case is actually of related write and read clocks, then just go with option "A" and set the number of stages to 1.

OTHO if your use case of unrelated write and read clocks, then you just have to bite the bullet: timing violations are unavoidable. Your FPGA will misbehave on occasion -- but the more synchronizer stages, the better.

Regarding gate level simulation, if you're getting timing violations on synchronization registers, you'll just have to work around it and disable timing checks for those registers using the tcheck_set command.

Important note: make sure you understand what you're doing. You should only need to disable timing checks in the first synchronization registers. If you see timing checks elsewhere, then it's another problem

I suggest you read Altera's "Understanding Metastability in FPGAs" too.

There are seven timing violations. This events are produced by both FIFOs. I can attach some parts of the log where you can see the events

SETUP Low VIOLATION ON aclr WITH RESPECT TO clk;

/tb_fifo/UUT/\fifo_cmp|dcfifo_component|auto_generated|fifo_ram|ram_block9a108\/addr_b_register

SETUP Low VIOLATION ON aclr WITH RESPECT TO clk;

/tb_fifo/UUT/\fifo_cmp|dcfifo_component|auto_generated|fifo_ram|ram_block9a72\/addr_b_register

SETUP Low VIOLATION ON aclr WITH RESPECT TO clk;

/tb_fifo/UUT/\fifo_cmp|dcfifo_component|auto_generated|fifo_ram|ram_block9a0\/addr_b_register

SETUP Low VIOLATION ON aclr WITH RESPECT TO clk;

/tb_fifo/UUT/\fifo_cmp|dcfifo_component|auto_generated|fifo_ram|ram_block9a36\/addr_b_register

HOLD High VIOLATION ON DATAIN WITH RESPECT TO CLK

/tb_fifo/UUT/\fifo_cmp|dcfifo_component|auto_generated|rs_dgwp|dffpipe10|dffe11a[1]

SETUP High VIOLATION ON ASDATA WITH RESPECT TO CLK;

/tb_fifo/UUT/\fifo2_cmp|dcfifo_component|auto_generated|ws_dgrp|dffpipe14|dffe15a[0]

SETUP High VIOLATION ON ASDATA WITH RESPECT TO CLK;

/tb_fifo/UUT/\fifo2_cmp|dcfifo_component|auto_generated|ws_dgrp|dffpipe14|dffe15a[3]

It's not possible to perform timing analysis on unrelated clocks because.. they're unrelated: they may drift, they may have unknown phase relations.

Static timing analysis needs to know the timing of the edges of the clocks in respect to one another.

Case 1: consider CLK1 and CLK2 which are generared from 2 different 10 MHz crystals. Since the crystals are never perfect, one may be 10.00001 MHz while the other may be 9.999999 MHz.

This means the clock edges will drift one in relation to another.

You can't do timing analysis on transfers between these two clocks.

Case 2: consider CLK1 and CLK2 which are generated from the same crystal but because CLK2 passes through a unknown length of cable and thus you can't know the phase of CLK1 in relation to CLK2.

Again, you can't do timing analysis on transfers between these two clocks.

Case 3: consider CLK1 and CLK2 which are generated from the same crystal, and go through some propagation chain BUT in this case you know the phase of CLK1 in respect to CLK2 at the FPGA's input pins, with a small error.

Now you have two related clocks and transfers between these two clocks can be analysed -- you can use a set_clock_uncertainty constraint to handle the error.

In this situation, you should go with option "A".

If you do have unrelated clocks, then your only option for a gate level simulation is to disable timing checks on the synchronization registers.

PS: You can ignore those SETUP violation of ACLR in respect to CLK, as long as the reset pulse is longer than 1 clock.

It's the other ones which are hurting you.

You need to look down into the RTL or post mapping schematics, find out which are the first level of synchronization registers and then disable timing checks on them.

I think it will be something like

tcheck_set /tb_fifo/UUT/\fifo_cmp|dcfifo_component|auto_generated|rs_dgwp OFF

But I stress again, it's important that you know what you're doing and only disable checks for the first level of synchronization registers.

If you disable timing checks for other registers, you may just end up hiding other bugs that may exist.