Gate Level Simulation

[Altera_Forum]

Hey everyone, 

  I have a functional model of an NLMS core running. Its simulation shows correct operation.    However, I've never downloaded it onto an FPGA yet. While I figure out how to excite the inputs, I am wondering how to perform a gate level simulation.    First, is a gate level simulation the same as downloading the circuit onto the board? If it works with the gate level simulation, will it work on the FPGA?    Second, how do you go about setting up a gate level simulation? I selected Tools->Run EDA Simulation->EDA Gate Level Simulation after performing full compilation. But, I get the following error:    Error: C:/altera/10.1/modelsim_ase/win32aloem/../altera/verilog/src/cycloneii_atoms.v(537): $hold( posedge clk &&& reset:662856 ps, d:662929 ps, 138 ps );# Time: 662929 ps Iteration: 1 Instance: /test_fir/ff/\wncb|ib|altsyncram_component|auto_generated|ram_block1a27 /addr_b_register# 663 x6552700 x1 x00 X 52 2 9 40 x X0x 0x 52 x00 x0 x x x# **     I also get don't cares for most of my signals.    Is it something I am doing wrong with the simulation? Do I need to compile/add some extra files?

[Altera_Forum]

If you're using NativeLink, setting up RTL and gate level simulation is the same thing. 

You just need to use "Tools -> ... -> EDA RTL Simulation" and "Tools -> ... -> EDA gate level simulation"  From the looks of it, there's nothing wrong with the simulation. Quite simply, it's telling you that there are timing violations in the design. Hence the $hold() errors and the XXXX outputs. Ie, it's telling you it won't work.   Thus, you need to go back and track down what's wrong. Did you constrain your design properly (ie, specify clocks)? Does it meet the timing constraints? Are you using TimeQuest? Are your testbench stimulus realistic and consistent with the constraints?

[Altera_Forum]

--- Quote Start ---  First, is a gate level simulation the same as downloading the circuit onto the board? If it works with the gate level simulation, will it work on the FPGA?  --- Quote End ---    Mostly, yes. However, simulations suffer from the "garbage in, garbage out" rule.  Also, simulations aren't 100% perfect. Gate level simulations don't, for example, take into account I/O signal integrity issues or power supply issues.

[Altera_Forum]

Thanks for the reply rbugalho. How would you go about fixing the timing violations?  

 I also don't understand what you mean by constraints. I've never used the timing simulations before. Could you please give me a little understanding as to what you mean?   Also, I specified a clock as fclk in my testbench, and used it in some of my always statements. Is that the same as specifying a clock? If not, then how do I specify it.   I know these questions are pretty basic, but this is my first time perfoming a gate level simulation, and any suggestions would be greatly appreciated.

[Altera_Forum]

--- Quote Start ---   I also don't understand what you mean by constraints. I've never used the timing simulations before. Could you please give me a little understanding as to what you mean?    --- Quote End ---    Read the timequest.pdf I posted to this thread:  http://www.alteraforum.com/forum/showthread.php?t=31457  and also read Rysc's TimeQuest document on the Altera Wiki.  http://www.alterawiki.com/wiki/timequest  Cheers, Dave

[Altera_Forum]

--- Quote Start ---  Thanks for the reply rbugalho. How would you go about fixing the timing violations?   --- Quote End ---   The short answer is that you make sure that the inputs to your design meet the input setup and hold timing constraints. See next reply for more     --- Quote Start ---  I also don't understand what you mean by constraints. I've never used the timing simulations before. Could you please give me a little understanding as to what you mean?  --- Quote End ---   Take a look at the timing report. Let's say that it says that signal 'a' has a setup time requirement of 10 ns before the rising edge of 'clk' and a hold time requirement of 2 ns after the rising edge of 'clk' (this is a completely fabricated example, meant to demonstrate the principle not necessarily what you're actually seeing).   Now, in your testbench let's say you have the following for signal 'a'.  process(clk) begin if rising_edge(clk) then a <= ... end if; end process;  The signal 'a' will transition 1 simulation delta cycle after the rising edge of 'clk' (one simulation delta cycle is essentially equivalent to 0 ns). If you did that, then 'a' would not meet the hold time of 2 ns specified in the timing report.   Now let's modify the example a bit to 'fix' the hold time problem by adding a 9 ns delay; let's also assume that 'clk' has a period of 10 ns.  clk <= not(clk) after 5 ns; -- This will generate a 10 ns period clock process(clk) begin if rising_edge(clk) then a <= ... after 9 ns; -- Delaying 'a' to fix the hold time problem end if; end process;  Now the problem is that 'a' will transition 9 ns after the rising edge of 'clk' which is the same thing as 1 ns before the rising edge of 'clk'. This will violate the setup time requirement specified in the timing report.   The end result of the story is that the testbench inputs must meet the timing requirements listed in the FPGA's timing report.   There is a analogous story to be told on the output side. If the timing lists that some output 'b' is valid 5 ns after the rising edge of the clock, then you would not want to flag it as a problem right at the rising edge or 1 ns after; you would need to wait until 5 ns after.     --- Quote Start ---  Also, I specified a clock as fclk in my testbench, and used it in some of my always statements. Is that the same as specifying a clock? If not, then how do I specify it.  --- Quote End ---   Assuming that what you're saying here is that you specified a clock frequency of (example) 100 MHz, and then the testbench generates a 10 ns clock then yes you're correct.     --- Quote Start ---  I know these questions are pretty basic, but this is my first time perfoming a gate level simulation, and any suggestions would be greatly appreciated.  --- Quote End ---   If you understand how to generate the timing constraints for the tool to use during synthesis then you would likely understand how to generate the testbench. Since you're asking the question, I'm guessing that the input constraints weren't setup properly. The first clue to this is if you do not understand what the timing requirement output report is telling you.    For example, if signal 'a' has a setup timing requirement of 15 ns relative to 'clk', is that good? Well, the answer is whether or not you specified a desired requirement and how it compares to 15 ns. If your analysis says that the PCBA will produce something that allows for 20 ns of setup time you're good; if it says 10 ns then it will (eventually) fail. You don't need to do this manually; the idea is that you - Perform analysis to determine what the requirements are for the FPGA design - Enter the results of that analysis into Quartus (aka 'constrain' the design) - Run Quartus - Inspect Quartus' timing report to see if it reports any requirements that could not be met (aka 'fails timing').   The short answer (if you can call this short) to your question about the testbench is that the testbench must match reality in some sense (i.e. nothing transitions 0 ns after 'clk''). The long answer is that maybe you need to get up to speed on how to perform static timing analysis. It's not quite clear just which path you need, so you'll need to provide some more info.   Kevin Jennings

[Altera_Forum]

EE, 

constraints are used by synthesis and static timing analysis (STA), not by gate level simulation; and specifying constraints has nothing to do with the testbench.  These constraints tell the tools what timing requirements you need the design to meet.  The most basic requirement you need to specifiy is the clock frequency at which you want to run your design.  Then those tools will a) attempt to meet your requirements and b) check that your requirements have been met or not. If you haven't constrained your design or the STA says that the requirments haven't been met*, then gate level simulation is pretty much a waste of time.  * You get a "Critical Warning: Timing requirements not met" in the final stages of compilation.  For modern Altera FPGAs, the STA tool to use is TimeQuest and Rysc has a wonderful guide on how to use it, as Dave mentioned.