Simulation works, Programmed FPGA does not

[utauta]

I wanted to know what are the common pitfalls/mistakes made when the
simulation of a design works, but the same code implemented on the
FPGA does not.

*The timing requirements for each signal appear to be within specs.

 

[Mike Treseler]

I wanted to know what are the common pitfalls/mistakes made when the
simulation of a design works, but the same code implemented on the
FPGA does not.

Sometimes,
[] a pin assignment doesn't match the board
[] an unassigned pin gets a default assignment to a random node.
[] unclocked logic or unintended latches don't happen to work
[] forgot to run STA and Fmax < Fclk
[] wrong or bad bit image
[] clock not running, one of the supplies isn't working
[] undocumented timing constraint on a reused entity.
[] reset is stuck active

-- Mike Treseler

 

[jeppe]

I agree with issues above and can only add:

[] Asyncronous inputs - most automatic generated simulations tend to be syncrone with the system clock and hence will the simulation not show the problems which comes with the real hardware / design.

Jeppe

 

[kenm]

I wanted to know what are the common pitfalls/mistakes made when the
simulation of a design works, but the same code implemented on the
FPGA does not.

Sometimes,
[] a pin assignment doesn't match the board
[] an unassigned pin gets a default assignment to a random node.
[] unclocked logic or unintended latches don't happen to work
[] forgot to run STA and Fmax < Fclk
[] wrong or bad bit image
[] clock not running, one of the supplies isn't working
[] undocumented timing constraint on a reused entity.
[] reset is stuck active

     -- Mike Treseler

Good points Mike.

Also (in order of likelihood in my experience)
[]an error by the synthesis tool, producing incorrect logic. Run a
post synthesis or post PAR simulation to check for this if you are
having problems. (Never seen any of these with XST but I have with
another synthesiser)
[] Design is being driven in a different way in simulation to what it
is on the board.
[] Missing or incorrect setup and hold time requirement on I/O

Good Luck,

Ken

 

[Nicolas Matringe]

Mike Treseler a écrit :

I wanted to know what are the common pitfalls/mistakes made when the
simulation of a design works, but the same code implemented on the
FPGA does not.

Sometimes,
[] a pin assignment doesn't match the board
[] an unassigned pin gets a default assignment to a random node.
[] unclocked logic or unintended latches don't happen to work
[] forgot to run STA and Fmax < Fclk
[] wrong or bad bit image
[] clock not running, one of the supplies isn't working
[] undocumented timing constraint on a reused entity.
[] reset is stuck active

[] An asynchronous input is not properly synchronized to the main clock

Nicolas

 

[Andy]

I wanted to know what are the common pitfalls/mistakes made when the
simulation of a design works, but the same code implemented on the
FPGA does not.

Sometimes,
[] a pin assignment doesn't match the board
[] an unassigned pin gets a default assignment to a random node.
[] unclocked logic or unintended latches don't happen to work
[] forgot to run STA and Fmax < Fclk
[] wrong or bad bit image
[] clock not running, one of the supplies isn't working
[] undocumented timing constraint on a reused entity.
[] reset is stuck active

-- Mike Treseler

[] incorrect multi-cycle or false path timing constraints (multi-cycle/
false paths that aren't)

I might add that I have very rarely encountered synthesis tool errors
that did not correctly implement the behavior I coded, so long as I
coded using proper synchronous techniques (I rarely use combinatorial
processses, so sensitivity list issues are not a problem). In my
experience, XST has been more prone to such problems than Symplify.
But other causes already mentioned, including improper synchronization
boundary crossings, and invalid assumptions about external interfaces
during simulation, are MUCH more common.

Andy

 

[Peter]

I wanted to know what are the common pitfalls/mistakes made when the
simulation of a design works, but the same code implemented on the
FPGA does not.

Sometimes,
[] a pin assignment doesn't match the board
[] an unassigned pin gets a default assignment to a random node.
[] unclocked logic or unintended latches don't happen to work
[] forgot to run STA and Fmax < Fclk
[] wrong or bad bit image
[] clock not running, one of the supplies isn't working
[] undocumented timing constraint on a reused entity.
[] reset is stuck active

[] reset released before system clock is running stable or all
supply voltages are within spec.
[] forgot to initialize state machines

/Peter

 

[rickman]

Sometimes,
[] a pin assignment doesn't match the board
[] an unassigned pin gets a default assignment to a random node.
[] unclocked logic or unintended latches don't happen to work
[] forgot to run STA and Fmax < Fclk
[] wrong or bad bit image
[] clock not running, one of the supplies isn't working
[] undocumented timing constraint on a reused entity.
[] reset is stuck active

[] reset released before system clock is running stable or all
supply voltages are within spec.
[] forgot to initialize state machines

How about [] verify reset released synchronously or state machines
designed to not matter if reset not released synchronously.

I have not seen a problem with this, but the built-in global reset
signal that most devices have is not designed to start the part
cleanly. I always provide a small amount of logic that is reset by
the internal reset. This then generates a synchronous reset which the
tools typically place on the global reset signal line.

Rick