Simulation works, Programmed FPGA does not

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.

utauta wrote:
> 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

On Aug 2, 8:20*am, Mike Treseler <mtrese...@gmail.com> wrote:
> utauta wrote:
> > 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

On Sat, 02 Aug 2008 00:20:23 -0700, Mike Treseler <mtreseler@gmail.com>
wrote:

>utauta wrote:
>> 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.

In Xilinx, check the Map report files (map.mrp or mydesign.mrp) to
diagnose these. Also check for I/O logic types voltages appropriate to
your board, and I/O flip-flops being created as you expect. (If not, I/O
timings will be MUCH slower than you expect)

My experience puts most of these problems as I/O related; maybe 60% of
them.

>[] unclocked logic or unintended latches don't happen to work

Again with Xilinx, there are pitfalls associated with DLL use for clock
generation: here are a few
(a) "reset" to a DLL must be active for some time (these have changed
over the years; check the actual FPGA's most recent documentation,
and/or search the answers database! older documents for V2Pro said 4
cycles but newer ones may say more)
(b) don't clock the reset timer from the DLL output clock; it's inactive
during reset so you'll never come out of reset! (don't ask me how I know
:-)
(c) wait for a DLL to lock (sense its "lock" output) before bringing
downstream logic out of reset
(d) don't cascade more than 2 DLLs; the third one won't reliably lock
(e) obey any constraints on clock speeds; especially don't run below 20
(25?) MHz on the main clock; that's why there are divided clock
outputs...

Bring clock and reset signals out on unused pins to observe these
problems.

>[] undocumented timing constraint on a reused entity.

Or the simulation model of the outside world doesn't match reality; e.g.
you haven't correctly accounted for clock timings to external memories,
or you are using simple models instead of the manufacturer's models, so
memory timings are different...


If all else fails, there's Chipscope...

- Brian

Mike Treseler a écrit :
> utauta wrote:
>> 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

On Aug 2, 2:20 am, Mike Treseler <mtrese...@gmail.com> wrote:
> utauta wrote:
> > 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

On 2 Aug, 09:20, Mike Treseler <mtrese...@gmail.com> wrote:
> utauta wrote:
> > 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

On Aug 4, 10:38 am, Peter <peter.hermans...@sts.saab.se> wrote:
> On 2 Aug, 09:20, Mike Treseler <mtrese...@gmail.com> wrote:> utauta wrote:
> > > 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

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