DCFIFO - incorrect functionality of a ModelSim timing simulation

[Altera_Forum]

Hey guys, 

 A brief background:My VHDL design (for Stratix III) has input data arriving at 20MHz. The data is read at a rate of 100Mhz. The reading and writing operations aren't necessarily simultaneous. I have prepared a dedicated FIFO block, based on the DCFIFO megafunction, to handle this input interface.  The relevant DCFIFO settings I have chosen:  overflow_checking => "ON" underflow_checking => "ON"   rdsync_delaypipe => 3 wrsync_delaypipe => 3  use_eab => "ON" write_aclr_synch => "ON"  The problem:The block works smoothly in logic simulation (ModelSim 6.5B) and timing (post-synthesis) simulation (Quartus II - 9.1). But, when I run the timing simulation in ModelSim (based on the vho+sdo files generated in Quartus) the functionality is incorrect: The first data sample which is written to the FIFO never appears on the FIFO's output lines. All the following data samples appear correctly.  Each time I raise the write enable, only the second data sample can be read. Attached:

• A logic simulation in ModelSim (perfect functionality) screen shot. 
• A timing simulation in ModelSim (incorrect functionality) screen shot.

purple - writing clock domain. orange - reading clock domain. fifo_full <-> wrfull fifo_empty <-> rdempty write_en <-> wrreq read_en = not(fifo_empty) <-> rdreq I tried (and failed) to solve the problem in the following methods:

• Assigning register on for the input and output ports of the DCFIFO to make sure no setup\hold time violations occur. 
• Reading from the FIFO a single clock cycle after fifo_empty goes low.

I am an undergraduate student and a newbie in digital design. This is my final project and it is crucial for me to perform a successful ModelSim timing simulation for the whole design.  I will appreciate any consultation.  Thanks ahead.

[Altera_Forum]

Did you define all your clocks in Timequest and put all your timing requirements? It could come from bad timing. 

I would rely more on Modelsim's output than Quartus'

[Altera_Forum]

Hello, 

 Thank you for answering.  I have defined both of the clocks in the TimeQuest analyzer. Those clocks are to be generated by a single PLL in the top level entity which includes my design as a sub-block. For the simulation's sake, I am generating them in my vhdl test bench. I have no idea how to define the clock uncertainties, so I have set them all to zero. When I perform compilation, only the "Uncosntrained Paths" category of the timing analyzer report goes red.  These are all the timing constraints I have applied. Am I doing anything wrong here ? Am I forgetting something ?  Thanks ahead.

[Altera_Forum]

--- Quote Start ---  When I perform compilation, only the "Uncosntrained Paths" category of the timing analyzer report goes red.  --- Quote End ---   You need to constrain your input/output delays, and then insure that the signals that you generate in your test bench are compliant with those constrains. This is the only way you can ensure that the timing solution will give you realistic results.

[Altera_Forum]

Thank you for the advice, Daixiwen.  

 I went through an agonizing process of getting familiar with the TimeQuest analyzer. Currently, I managed to get zero unconstrained paths and zero failed paths (no red colored lines in the timing report). I have also made sure that my test bench drives the inputs in agreement with the input delay constraints, as defined in the .sdc file.   Nevertheless, the timing simulation in ModelSim exhibits the exact same problem which I described earlier.   Any other thoughts of what might be the problem ?  Should I try changing the target FPGA device to uncover the bug ?  Thanks,  Yoni.

[Altera_Forum]

Timequest is difficult to learn but it is time well spent ;) 

Are you sure that the timing requirements are met? Timequest doesn't produce an error when they aren't met, just a critical warning. Could you post your code (fifo instantiation, sdc file and testbench)?

[Altera_Forum]

Hey Daixiwen, 

   --- Quote Start ---  Timequest doesn't produce an error when they aren't met, just a critical warning.  --- Quote End ---    I have checked that no warnings regarding the timing requirements were produced during the Quartus compilation.  At your request, I have written a code for the dcfifo instantiation and a simple test bench for it. The test bench demonstrates the problem I am facing.   Additionally, I have added the constraints file and the vho+sdo files produced by Quartus.   The waves for the logic and timing simulations (performed in ModelSim SE 6.5b) are also attached. The incorrect functionality of the post synthesis dcfifo will be clear when you compare those two waveforms.  I am very grateful for your intention on helping me.  Yoni.

[Altera_Forum]

Oh, there are two things I forgot to mention: 

• I have attempted synthesizing for Stratix IV and witnessed the same incorrect behavior. 
• I am using a tcl script for the ModelSim simulation (see attached).

[Altera_Forum]

I tried your project on my system (Quartus 9.0 SP2 and Modelsim 6.4a) and didn't have the same results. 

First Quartus couldn't meet the timing requirements. I don't know what are your actual I/O timings, but I tweaked a bit the sdc file to make the job easier for Quartus. I didn't try to enable any optimizations or set fast paths/registers. I changed the .sdc file to this: create_clock -period 10.000 -name read_clk create_clock -period 50.000 -name write_clk derive_clock_uncertainty set_input_delay -clock { read_clk } -max 2.0 set_input_delay -clock { read_clk } -min 0.0 set_input_delay -clock { write_clk } -max 2.0 set_input_delay -clock { write_clk } -min 0.0 set_input_delay -clock { write_clk } -max 3.0 set_input_delay -clock { write_clk } -min 1.0 set_output_delay -clock { read_clk } -max 0.4 set_output_delay -clock { read_clk } -min -2.0 set_output_delay -clock { write_clk } -max 0.4 set_output_delay -clock { write_clk } -min -2.0 But of course you should set requirements that are compatible with what you connect to the FPGA. Then to run the timing analysis in Modelsim I added some lines to your script: vlib lib vmap work lib vcom -O0 project/simulation/modelsim/DCFIFO_inst_4l_900mv_100c_slow.vho vcom -O0 VHDL/DCFIFO_inst_tb_rtl.vhd vsim -novopt -L altera_mf -t ps +transport_int_delays +transport_path_delays -sdfmax /DCFIFO_inst_tb/eut_DCFIFO_inst=project/simulation/modelsim/DCFIFO_inst_4l_900mv_100c_vhd_slow.sdo DCFIFO_inst_tb add wave -color green sim:/DCFIFO_inst_tb/rst add wave -color orange sim:/DCFIFO_inst_tb/read_clk add wave -color orange -unsigned sim:/DCFIFO_inst_tb/read_data add wave -color orange sim:/DCFIFO_inst_tb/read_enable add wave -color orange sim:/DCFIFO_inst_tb/FIFO_empty add wave -color magenta sim:/DCFIFO_inst_tb/write_clk add wave -color magenta -unsigned sim:/DCFIFO_inst_tb/write_data add wave -color magenta sim:/DCFIFO_inst_tb/write_enable add wave -color magenta sim:/DCFIFO_inst_tb/FIFO_full add wave -color yellow sim:/DCFIFO_inst_tb/good_result add wave -color pink sim:/DCFIFO_inst_tb/done run -all wave zoomfull where 'project' is the path to the Quartus project. When I ran the simulation I had timing violations at the beginning. Changing the test bench so that the clocks start at 0 instead of 1 fixed it. I'm not used to perform timing simulations so I don't know if this is normal or not. Nevertheless, the simulation ran fine. So I don't know if your problem comes from a different setting somewhere, or a bug in Quartus 10.0

[Altera_Forum]

Hello Daixiwen, 

 I would like to thank you for your detailed reply and for the time you spent to compile & simulate my code.  In the meanwhile, I have applied a service request on Altera's mySupport. They have helped me to solve the problem. To cut a long story short, I've discovered that by modifying the Quartus settings, it can be tolled to generate a ModelSim script for an appropriate rtl / gate level simulation. Using such a script, I've been able to simulate my design and achieve correct functionality, thus putting an end to this miserable saga.   I have examined your last reply, though, and I still have some questions:

1. How come the .sdc file you've suggested does not contain any virtual clocks ? I thought those were necessary, quoting the QII version 10.0 HandBook, Volume 3, chapter 7:   --- Quote Start ---  For I/O interface uncertainty, you must create a virtual clock and constrain the input and output ports with the set_input_delay and set_output_delay commands that reference the virtual clock. The virtual clock is required to prevent the derive_clock_uncertainty command from applying clock uncertainties for either intra- or inter-clock transfers on an I/O interface clock transfer when the set_input_delay or set_output_delay commands reference a clock port or PLL output.  --- Quote End ---   
2. What is the meaning of a negative value for the minimum output delay ? When I examine the equation Altera proposes to derive this delay, I figure that a negative value suggests that the hold time for the output latch (external to the FPGA device) is longer than the minimal delay path leading to this latch. Thus, Quartus has to place the logic to create extra (in our case) 2.0 ns of contamination delay to make sure that the hold requirement is met. I find it hard to believe that this will make the compilation job for Quartus any easier (I also checked and so that it caused a smaller f_max). Am I missing something ?

Again, thank you for your kind help. The advice you gave me allowed for a great improvement in my digital design skills.  Yoni. 

[Altera_Forum]

1. This is my mistake... I removed the virtual clocks to check if it changed anything, but forgot to put them back in 

2. The actual hold (delay between the clock edge and the time the signal is allowed to change) is the *opposite* of the output min delay. I don't know why they put it like this. But again the actual value depends on the external components' requirements, and the pcb delays. The document in this thread (http://www.alteraforum.com/forum/showthread.php?t=1269) explains it well, and give practical examples (which in my opinion the Altera documentation lacks). Opening the Timequest analyser and using the report timing function also helps to understand how your requirements are interpreted. I agree that my setting doesn't necessarily make the fitter job any easier, but neglecting the hold requirements can cause problems in "fast" conditions (high supply voltage and low temperature).

[Altera_Forum]

Hey Daixiwen, 

 Thanks again for your help and advice. I will examine the document more thoroughly as soon as I'll need to perform full design synthesis.  Yoni.

[Altera_Forum]

Can you tell me what script needs to be written for a correct gate-level simulation?

[Altera_Forum]

Hey ramanadn, 

 Please follow these steps:  1. Define the relevant simulation settings (note the bottom ones in case you have a test bench) in: assignments -> settings -> eda -> simulation. In the "More NativeLink Settings" definge the way you want the scripts to be generated. 2. Compile the design. 3. In the output directory you've defined in the simulation settings (stage 1) you'll find the scripts you are looking for (with a .do suffix). 4. You can run these scripts in the third party tool directly from Quartus by choosing Tools -> Run EDA simulation tool -> EDA gate level simulation.  Hope this helps. Ask further if not.  Yoni.