cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Contributor
Contributor
5,588 Views
Registered: ‎04-12-2017

design works in simulation but not on hardware

Jump to solution

Hi all,

First things first, I’m fairly new to FPGA design, so don’t judge me.

I’m currently working on a very simple design which (in theory) calculates pi (actually pi/4). It consists of a pipeline of double precision floating point ip cores (adders, reciprocals, accumulators) which feeds into block design containing a microblaze which outputs the result to the uart.

The design works perfectly fine in the behavioral simulation, it meets all timing requirements and I don’t get any critical warnings. The only problem is that it doesn’t work on the hardware (a Digilent Nexys Video powered by an Artix 7 XC7A200T). I tried using an on-chip debugger and thus found out that the result of the pipeline isn’t synchronous to the clock, it just bounces around randomly (as you can see in the attached picture) which makes me think that my timing constraints are incorrect.

I also tried running a post synthesis and post implementation simulation, but all I get are empty windows.

I hope someone out there can help me with my problem,

thanks in advance.

 

 

(sorry for posting a second time, I failed the first time)

sim_vs_hardware.png
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Contributor
Contributor
5,962 Views
Registered: ‎04-12-2017
I solved the problem. Fixed-point did the trick!

View solution in original post

0 Kudos
12 Replies
Highlighted
Moderator
Moderator
5,567 Views
Registered: ‎09-15-2016

Hi @recyclehere

>>I also tried running a post synthesis and post implementation simulation, but all I get are empty windows.

Are you not able to see any signals in the object window in case of post synthesis and implementation simulation simulation?

Also are you seeing any warnings related to the optimization in the synthesis and implementation log?

Can you please attach these logs along with the constraints file?

 

Before trying on hardware you should make sure that your functionality is correct till post implementation timing simulation. 

 

Regards

Rohit

Regards
Rohit
----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------

0 Kudos
Highlighted
Contributor
Contributor
5,561 Views
Registered: ‎04-12-2017

Thanks for the quick response.

 

First of all, I don't see anything in the objects window, it's just empty.

When I looked at the synthesis warnings, I noticed a lot of "Could not resolve non-primitve black box cell ..." warnings for pretty much every ip core in the design. Those warnings look like the problem to me. I exported them to a spreadsheet which I will attach here.

 

Thanks for helping.

0 Kudos
Highlighted
Moderator
Moderator
5,494 Views
Registered: ‎09-15-2016

Hi @recyclehere

 

You need not to worry about the warning "Could not resolve non-primitve black box cell ..." . This warning is just because your IPs are synthesized in OOC (out of context) mode so their  netlist appears to be black box during the regular synthesis run, hence the warning. The netlist of the all the Ips synthesized in OOC mode get combine with the netlist of regular synthesis run during the opt_design phase.

 

For the warning [Timing 38-316] Clock period '100.000' specified during out-of-context synthesis of instance '...' at clock pin 'clka' is different from the actual clock period '20', this can lead to different synthesis results.

If you are using the Xilinx IP, please follow the steps mentioned in the below link of UG896 page 29 to 31 to set the desired frequency:

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2016_4/ug896-vivado-ip.pdf

 

Also  before running post synthesis simulation, can you manually try deleting behav.wdb,simulate.log,xelab.pb files from the project directory path <project_dir>sim_1/behav and then run the simulation.

 

Also i cannot see any timing constraints in your xdc. Add proper timing constraints for the proper timing analysis of the paths and make sure timings are clean.

Once the timings are clean at your end and post implementation timing simulation matches the behavioral simulation, try implementing on the hardware.

 

Regards

Rohit

----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------

 

 

Regards
Rohit
----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------

0 Kudos
Highlighted
Contributor
Contributor
5,489 Views
Registered: ‎04-12-2017

Thank you for the information.

 

I changed the clock in the xdc files of the ip cores to the correct values.

When I try to run a post synthesis or post implementation simulation now, I get the following error:

 

[VRFC 10-704] formal sl_iport0 has no actual or default value ["<project_dir>\parallel_pi.sim/sim_1/synth/func/pi_sim_func_synth.vhd":937702]

 

The problem is, I have no idea which port that is. I thought the block design is causing this error, so I tried recreating it but that didn't help.

 

Another question: How should I constrain the output of the pipeline? It isn't connected to an actual io pin, it feeds into a delay stage which outputs the current value every 100 µs. Then I use the output of the delay stage as an input for the microblaze (via a gpio block, which is probably not the best idea). The only output in the design is the txd pin of the uart.

 

I have been looking for documentation regarding timing constraints for quite a while, but I wasn't able to find something. It would be great if you could point me to some material on this topic.

 

Thanks a lot for helping.

 

delay.png
0 Kudos
Highlighted
Moderator
Moderator
5,466 Views
Registered: ‎09-15-2016

Hi @recyclehere

 

>>[VRFC 10-704] formal sl_iport0 has no actual or default value ["<project_dir>\parallel_pi.sim/sim_1/synth/func/pi_sim_func_synth.vhd":937702]

 

Please check this below thread https://forums.xilinx.com/t5/Simulation-and-Verification/Vivado-error-while-trying-to-simulate-with-user-defined-data/m-p/543121

 

Also refer the below link of UG for timing constraints as well as tutorial:

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2016_4/ug903-vivado-using-constraints.pdf

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2016_4/ug945-vivado-using-constraints-tutorial.pdf

 

Regards

Rohit

 

 

Regards
Rohit
----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------

0 Kudos
Highlighted
Contributor
Contributor
5,456 Views
Registered: ‎04-12-2017

Hi,

 

I fixed the simulation error by removing all debug cores from the design.

I will post again when I fixed the timing constraints or when I have some additional questions.

 

Thanks a lot.

0 Kudos
Highlighted
Contributor
Contributor
5,226 Views
Registered: ‎04-12-2017

Hi,

 

I think I now know what's causing the problem. Looking at my timing report, I see very little positive hold slack (only about 0,06 ns).

Now I need to find a way to solve this.

 

Thanks for any suggestions.

0 Kudos
Highlighted
Teacher
Teacher
5,205 Views
Registered: ‎03-31-2012

@recyclehere with xilinx tools, 60ps of hold slack is pretty good. Basically if xilinx timing engine says you have positive hold you should be ok (for a properly constrained design). I'd investigate your constraints instead of trying to address the hold first.

- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
0 Kudos
Highlighted
Contributor
Contributor
5,188 Views
Registered: ‎04-12-2017

Thank you for the information.

60 ps sounded like nothing to me, so good to know.

0 Kudos
Highlighted
Contributor
Contributor
3,664 Views
Registered: ‎04-12-2017

Hi,

 

Now I know what is causing the problem (sort of).

For some reason, the floating point adders work fine in the behavioural and the post-synthesis but not in the post-implementation simulation.

 

Here are two examples of values entering the core and the corresponding results:

7 + 0 = 3
0.09090909 + 0.09090909 = 0

 

However, the subtractors, which are essentially the same core, work just fine.

 

I also tried deleting and recreating the core, but nothing changed. When I tried this, I got the message you can see in the attached picture.

 

I hope someone has an idea what is causing this behaviour.

double_add_message.png
0 Kudos
Highlighted
Contributor
Contributor
3,645 Views
Registered: ‎04-12-2017

Hi,

 

I tried a little quick and dirty fix for the problem. Instead of using adders, I used subtractors and set the sign bit on the b input to 1. Now all the additions work (I would prefer a proper solution), but the accumulator on the output delivers erratic results.

 

Thanks for any suggestions.

0 Kudos
Highlighted
Contributor
Contributor
5,963 Views
Registered: ‎04-12-2017
I solved the problem. Fixed-point did the trick!

View solution in original post

0 Kudos