Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
15 years ago

DCFIFO - incorrect functionality of a ModelSim timing simulation

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.

13 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    --- 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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

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