We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Showing results for 
Search instead for 
Did you mean: 
Registered: ‎08-04-2018

On marking nets for debugging

Hey everybody, first post here.

I'm developing HDL for an Ettus SDR, and I'm currently using the ILA to debug some behaviors. I see Ettus recommends using the attributes mark_debug and dont_touch to identify nets being connected to ILA cores, but Xilinx's User Guide does not mention dont_touch at all. Is the dont_touch attribute necessary?

And also, including ILA cores in my design has sometimes caused my timing to fail: would using mark_debug only make it easier for timing closure to be achieved by the tool (and still be able to see the signals properly)?

Thanks in advance!




Edit: I'm developing on Vivado 2017.4 for a Kintex 7 device, btw.

0 Kudos
2 Replies
Registered: ‎10-05-2010

Re: On marking nets for debugging

in Verilog and SystemVerilog, I only use mark_debug.



Joe Samson

Tags (2)
0 Kudos
Registered: ‎02-09-2017

Re: On marking nets for debugging

Hi @pollo_vignolo,


The mark_debug is purely for allowing Vivado to know that you will want to connect those nets to an ILA using the Set Up Debug option. So when you start the Set Up Debug Wizard, all those nets will automatically be shown to make it easier to connect. It will also prevent Vivado from optimizing out those nets.


In most cases, that's all you need to do. In some corner cases, during the Synthesis and Implementation process, Vivado might still rename some of the nets with mark_debug (it will not remove the nets, but they might have it's name changed). If that happens and is an issue for you, you can also apply the dont_touch to make sure absolutely no modifications are made to the nets and to the parent nets.


The mark_debug will not help you in anyway with meeting timing closure.


When you insert the ILA and your design fails timing, are the failing nets related to the ILA (some ILA internal paths) or are they some other random nets? 


If it's somewhere else in the design, it's probably because your device is too full (or is placing all the logic in a small space instead of spreading it out). If it's inside the ILA, you might be able to set_false_path those errors.


There's some good information about timing on this thread.




Please let us know if that helps you.



Andre Guerrero

Product Applications Engineer

Don’t forget to reply, kudo, and accept as solution.