cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
ch.goodchild
Visitor
Visitor
5,590 Views
Registered: ‎07-30-2017

How to successfully trigger an ILA core in Vivado

Jump to solution

Hi,

 

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?

 

Thanks in advance!

0 Kudos
1 Solution

Accepted Solutions
ch.goodchild
Visitor
Visitor
6,248 Views
Registered: ‎07-30-2017

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.

View solution in original post

0 Kudos
8 Replies
florentw
Moderator
Moderator
5,546 Views
Registered: ‎11-09-2015

HI @ch.goodchild,

 

You may want to follow the tutorials from UG936. It will help you to set up the ILA and change the triggers.

 

My guess is that your trigger condition is not correct. So the ILA never fail into the condition

 

Regards,

 

Florent


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
arpansur
Moderator
Moderator
5,543 Views
Registered: ‎07-01-2015

Hi @ch.goodchild,

 

  1. Is the design meeting timing?
  2. What are the frequencies of the signal being probed and ILA clock frequency?
  3. What is JTAG frequency?
  4. Are you able to see the expected behavior on the signals in post-impl timing simulation?
Thanks,
Arpan
----------------------------------------------------------------------------------------------
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.
----------------------------------------------------------------------------------------------
ch.goodchild
Visitor
Visitor
5,483 Views
Registered: ‎07-30-2017

Hi,

 

thanks for the quick and helpful replies.

 

@florentw, I am already following that tutorial. So far I only tried Lab 2 from the user guide (p. 25 - 28 and p. 51 - 66). I will try Lab  1 (p. 11 - 24) in the next synthesis run and let you know how it goes.

 

@arpansurYour questions revealed a lot of issues in my design and I am not sure how to resolve them. My synthesis is currently out of date so I will remove the VIO core that created errors in the post implementation simulation and I will do the steps in 1 from UG936. I will let you know if there I make any progress...

Is the design meeting timing?

There are a lot of critical warnings...

timing_tmp.JPG

The "unconstrained_internal_endpoints" are not a surprise, because my project has a lot of output signals that are not connected to any physical pins yet. Previously I had connected all my open ended signals to the ILA core, but I reduced the signals that I am measuring to an absolute minimum now so that it becomes easier to identify the problem...

 

Is it possible that the "no clock" warnings are caused by asynchronous or VHDL statements? How can I best locate the cause of these problems?

 

What are the frequencies of the signal being probed and ILA clock frequency?

My entire project is driven by the internal 200 Mhz clock with an IBUFDS module to convert it into a single ended clock. The ILA and VIO entities that I created are also being driven by this clock.

 

The "Set up debug summary" also states that it found 1 clock.

found_1_clock.PNG

 

I did however find "unconstrained" clock networks. It's a bit concerning that it says CLK_P is unconstrained. I have the following lines in my .xdc file:

 

set_property PACKAGE_PIN K28 [get_ports CLK_P]
set_property IOSTANDARD LVDS_25 [get_ports CLK_P]

 

unconstrained_clock_tmp.PNG

 

What is JTAG frequency?

The JTAG frequency is locked to 15000000

 

I tried modifying it, but I couldn't:

set_property PARAM.FREQUENCY 10000000 [get_hw_targets */xilinx_tcf/Digilent/210203339821A]
ERROR: [Labtoolstcl 44-127] hw_target property 'PARAM.FREQUENCY' is read-only.

 

Are you able to see the expected behavior on the signals in post-impl timing simulation?

Unfortunately not:

ERROR: [VRFC 10-619] entity port probe_in0 does not match with type std_logic of component port [H:/.../multiplier_tb.vhd:119]
ERROR: [VRFC 10-664] expression has 9 elements ; expected 1 [H:/...multiplier_tb.vhd:119]
ERROR: [XSIM 43-3321] Static elaboration of top level VHDL design unit multiplier_tb in library work failed.

 

The error message says that the expression has 9 elements, but that is not true:

vio_tmp_3.PNG

 vio_tmp.PNG

vio_tmp2.PNG

 

How can I proceed in order to minimize the amount of synthesis/implementation runs that I need to perform?

 

Thanks for your patience!

Chandran

 

0 Kudos
arpansur
Moderator
Moderator
5,459 Views
Registered: ‎07-01-2015

Hi @ch.goodchild,

 

There are no create_clock constraints in the design.

So please go through the xdc file of the UG936 it will give you an idea of the clock constraints.

I am also attaching a counter code file here. Please use this as a reference and modify your design.

Thanks,
Arpan
----------------------------------------------------------------------------------------------
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.
----------------------------------------------------------------------------------------------
ch.goodchild
Visitor
Visitor
5,437 Views
Registered: ‎07-30-2017

Hi @arpansur,

 

Thanks for the example code. There were a lot of problems with my .xdc file.

 

I noticed that the following command works in the pure VHDL implementation of my project

 

connect_debug_port u_ila_0/clk [get_nets [list clk_BUFG]]

 

 

While this command works in the equivalent block diagram implementation

 

connect_debug_port dbg_hub/clk [get_nets clk]

 

 

Meanwhile I managed to run the post implementation simulation in the pure VHDL version of this project.

signals.PNG

 

I believe this is because there is no hardware to drive CLK_P and CLK_N in the simulation.

 

The timing report also doesn't look so good:

timing.PNG

 

Since the post implementation simulation now executes I tried running the binary file on real hardware. Unfortunately the trigger still doesn't work...

 

I have attached my XDC file just in case it helps. How do you think I should proceed?

 

Thanks in advance!

Chandran

0 Kudos
ch.goodchild
Visitor
Visitor
5,435 Views
Registered: ‎07-30-2017

So please go through the xdc file of the UG936 it will give you an idea of the clock constraints.

Do you mean the "sinegen_demo_kc705.xdc", which is listed under "required files"?

Unfortunately I didn't find it on the internet...

0 Kudos
ch.goodchild
Visitor
Visitor
6,249 Views
Registered: ‎07-30-2017

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.

View solution in original post

0 Kudos
ch.goodchild
Visitor
Visitor
4,870 Views
Registered: ‎07-30-2017

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.

0 Kudos