[SOLVED] 'Post Route' Simulation showing different results than real operation of code

Hi everyone!

I am trying to implement a design in which

- I have to transmit an 8 bit data serially on a pin of FPGA i.e. 10011010.
- Data is to be transmitted at both the rising and falling edge of a signal.
- Moreover, signal is generated whenever an enable pulse is given.

Problem

The problem I am facing is that the design is working fine in 'Post Route Simulation' of ISE platform but when I run the design on FPGA, all other things are working fine but the transmitted data shows different results i.e. 10101010 or 1000000 etc.


Help is required please!

zaidilyas said:

Hi everyone!

I am trying to implement a design in which

- I have to transmit an 8 bit data serially on a pin of FPGA i.e. 10011010.
- Data is to be transmitted at both the rising and falling edge of a signal.
- Moreover, signal is generated whenever an enable pulse is given.

Problem

The problem I am facing is that the design is working fine in 'Post Route Simulation' of ISE platform but when I run the design on FPGA, all other things are working fine but the transmitted data shows different results i.e. 10101010 or 1000000 etc.


Help is required please!

Click to expand...

The most common reason for differences between pre- and post-route simulation results or for differences between simulation and real world is timing violations. The most typical reasons for these violations are:
- Inputs not meeting setup/hold time requirements of the actual design. Peruse the timing report and it will tell you what the setup and hold time requirement of an input pin to the sampling clock. Insure that your simulation actually changes that input during an allowable time. Repeat for all input pins. Peruse the datasheets for the actual devices that produce those inputs and insure that those devices will generate changes on those inputs to your FPGA during that same allowable time.
- Clock domain crossings. If a signal is generated by one clock, but then used inside another clock domain you'll have problems in the real world unless you perform proper clock domain crossing techniques. The way to do this is to that signal generated by Clock1 and then clock it only into a flip flop clocked by Clock2. Do not let that signal go any other place. Now take that flip flop output and clock it into another flip flop, again not letting that signal go any other place. The output of that second flip flop can now be used anywhere you're clocking with Clock2.

Kevin Jennings