Beginner Question - Differences between Simulation and Application

Do a search for "Timing closure". That one is typically the problem of all designs that do not behave like in simulation.

The reason is that simulation does not take time into account.

--- Quote Start ---

Do a search for "Timing closure". That one is typically the problem of all designs that do not behave like in simulation.

The reason is that simulation does not take time into account.

--- Quote End ---

Will do. Thanks!

Apart from timing, there are other important issues that result in hardware/simulation mismatch:

1) startup values on registers. Best to have reset values on all registers.

2) wrong simulation input vectors that do not represent actual inputs as to pattern and relative relations. i.e. simulation was false pass... include also any floating nonconnected inputs.

3) loss of data flow control e.g. overfilling or underfilling of buffers. This may be difficult to simulate with finite vectors.

4) hardware issues e.g. clock jitter. floating pins.

A proper standard testbench is important. The testbench itself must be dead simple so that you don't have to test your testbench.

For hardware, make extensive use of alarms (to LEDs...) to help you localise the issues.

Interesting stuff, thank you.

Any suggestions on how to overcome any issues with buffers or floating values ?

I've tried using tri0 instead of wire to describe output lines, which seemed to work in one case where an output was defaulting to a false active... that kind of thing?

Hi,

For suspected floating inputs or outputs you can use onchip pullup option in the assignment editor. This makes your unconnected inputs high and drives outputs as well high. If an output is active low e.g. memory write, you can then prevent accidental writing.

The issue of floating inputs/outputs applies to a full system. However you can do some internal vectors and test your fpga with it and check your outputs internally as well (sort of synthesisable testbench).

For buffers, LEDs are best provided you latch/clear the alarms for time suitable to human eye.

Don't forget signaltap could be very useful.

--- Quote Start ---

Apart from timing, there are other important issues that result in hardware/simulation mismatch:

1) startup values on registers. Best to have reset values on all registers.

2) wrong simulation input vectors that do not represent actual inputs as to pattern and relative relations. i.e. simulation was false pass... include also any floating nonconnected inputs.

3) loss of data flow control e.g. overfilling or underfilling of buffers. This may be difficult to simulate with finite vectors.

4) hardware issues e.g. clock jitter. floating pins.

A proper standard testbench is important. The testbench itself must be dead simple so that you don't have to test your testbench.

For hardware, make extensive use of alarms (to LEDs...) to help you localise the issues.

--- Quote End ---

Remarkable. Thanks.

--- Quote Start ---

Don't forget signaltap could be very useful.

--- Quote End ---

In my experience, signaltap has been an invaluable tool. Having a much more hardware background, I like to prototype as much as possible on development kits, and use signaltap to monitor any important signals. This can be done in small "modules" which then build a much more complex system.

Ensuring clock synchronization is also quite helpful. Sometimes if there are signals crossing clock domains, you can use a simple D flipflop in between domains to gate the timing. Quartus has a much easier time doing the timing analysis then.

The RTL viewer can also help identify timing glitches in the synthesizer. I have had circumstances where state machines were being reset in places where the code should not have allowed it, but a race condition identified with the RTL viewer allowed me to change the code so the race condition no longer existed.

My last advice is to use the built in timing tools in Quartus. You can do a lot with optimizing for speed vs. area, and using logic lock regions on any timing-critical modules.