0
\$\begingroup\$

I am trying to debug my VHDL project in Vivado 2014.03 on a KC705.

My project consists of multiple VHDL modules implemented as custom IP cores, which are connected in a block design.

I selected mark debug on the signals that are connected to the ILA core.

After synthesis I used setup debug and added the nets that my ILA core is analyzing. The .xdc file was modified and I even resynthesized the project just incase...

After writing the resultant binary file onto the FPGA, I get two ILA cores, both of which get stuck at "waiting for trigger". Sometimes my ILA cores responded to trigger immediate, but they always return the same result and it isn't useful because the time window that I need is quite short.

I mapped one of the signals to an LED and confirmed that the signal exists.

I also synthesized the entire project in pure VHDL without using any custom IP cores. Again - I had the same problems.

I would like to make smart moves while debugging this issue, because each synthesis takes about two hours and it is very easy to make the project go out of date.

What could I be doing wrong? What can I try next?

\$\endgroup\$
  • 1
    \$\begingroup\$ VTC - This question is not about the design side of electronics as subscribed to be on topic for this site. In fact the risk assessment asked about hints at the need for a repair which is also off topic. \$\endgroup\$ – Michael Karas Jul 30 '17 at 19:54
  • 1
    \$\begingroup\$ The best place to put this question is at Xilimx forums. \$\endgroup\$ – Claudio Avi Chami Jul 30 '17 at 20:32
  • 1
    \$\begingroup\$ The thing that is missing from your story is exactly what trigger conditions you established for each of your ILAs. \$\endgroup\$ – Dave Tweed Jul 31 '17 at 12:24
  • 1
    \$\begingroup\$ Have you considered the fact that your signals are in fact not changing, thus never triggering the core? This is usually a symptom of bad reset polarity... Have you performed a functional simulation of the system and confirmed it to work correctly and affecting those signals which you trigger upon? \$\endgroup\$ – Rami Jul 31 '17 at 13:58
  • 1
    \$\begingroup\$ If you have multiple trigger signals in the ILA, make sure you use the appropriate logic setting (global OR, AND, etc.). Check your implemented netlist to ensure the signal is actually connected to the ILA. Try manually instantiating ILAs from IP integrator instead of using the mark debug attribute. \$\endgroup\$ – ks0ze Jul 31 '17 at 15:28
1
\$\begingroup\$

EDIT


Meanwhile the problems have been resolved:

  1. Since it was my first VHDL project, I thought it was be a good idea to combine combinatorial logic with synchronous logic in order to reduce the circuit's propagation delay. The combinatorial part had a bug in it, but it still simulated sucessfully because I didn't set the sensitivity list correctly.

Solution: avoid using combinatorial circuits whenever possible.

  1. I was doing some calculations in compile time, which worked fine in the simulation (probably computed with 64 bit), but it led to an overflow during synthesis (probably computed with 32 bit). As a result of the overflow the optimizer removed most of my project, but it left the part that I was looking at with the debug LED un touched...

Solution: configure the module manually rather than setting it up in compile time.

This solves my core issues, but it doesn't explain the inconsistent behavior that I observed in Vivado while trying to narrow down the issue.


BEFORE EDIT


Unfortunately the issue was not resolved, but I promised to get back and report on how it went.


The short answer:

  • Start with a small manageable project.
  • Check your triggers
  • Make sure you're XDC file is fine.
  • Don't try all the instructions at once
  • Try to reproduce your problems on someone else's work bench if can get the opportunity.

The long answer:

The triggers were not the problem in my project. I kept cutting out pieces of my project to narrow down on the cause of the problem - till I was left with a simple counter!

So I implemented a counter driving the LED in a test project and analyzed the signal successfully. Strangely this was not reproducible with an identical counter when it was copied into the test project from my actual project!

Someone else who has the same FPGA and a slightly newer version of Vivado did exactly what I did and he successfully analyzed the project at his workbench. After sending he sent the modified test project back to me, I was able to create the debug core and it functioned as intended.

Conclusion: I ended up blaming version 2014.03 of Vivado.

\$\endgroup\$
  • 3
    \$\begingroup\$ And Vivado claims another victim. Seriously though, why were you using such an old version of Vivado? \$\endgroup\$ – alex.forencich Aug 10 '17 at 22:35
  • \$\begingroup\$ @alex.forencich it looks like I was also to blame because I hadn't thought of the potential overflow. I was given 2014.03 because the license has already been purchased and apparently 2014.03 is the latest version that the KC705 FPGA supports... \$\endgroup\$ – Chandran Goodchild Oct 9 '17 at 13:37
  • \$\begingroup\$ @ChandranGoodchild I've also worked on KC705 with the license of 2014.x version but i was successfully able to apply it to for 2016.1 updates as well. Also it told me that i will be getting update till 2017.1. you can try it. \$\endgroup\$ – Sourabh Tapas Nov 26 '17 at 9:18
  • \$\begingroup\$ Thanks! I'm no longer working on this project, but I heard that they upgraded to a newer version :-) \$\endgroup\$ – Chandran Goodchild Nov 26 '17 at 9:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.