04-12-2017 09:46 AM
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)
04-12-2017 12:34 PM
>>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.
04-12-2017 01:00 PM
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.
04-13-2017 11:44 AM
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:
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.
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.
04-13-2017 01:00 PM
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.
04-14-2017 07:59 AM
>>[VRFC 10-704] formal sl_iport0 has no actual or default value ["<project_dir>\parallel_pi.sim/sim_1/synth/func/p
Also refer the below link of UG for timing constraints as well as tutorial:
04-14-2017 11:45 AM
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.
05-01-2017 12:00 PM
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.
05-02-2017 01:54 PM
@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.
05-08-2017 11:24 AM
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.
05-09-2017 11:31 AM
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.