Showing results for 
Show  only  | Search instead for 
Did you mean: 
Registered: ‎10-16-2013

MARK_DEBUG attribute distort logic behavior


I use the MARK_DEBUG attribute to tag signals for debugging, so that they show up in the debug setup dialog in Vivado.

Now, I have encountered the following issue:
When a signal is tagged with MARK_DEBUG, the logic behaves differently than when the attribute is not set, regardless of whether an ILA-Core is in the design or not, only setting the MARK_DEBUG attribute makes the change.

The situation in my design is comparable with the following small lines of vhdl-code:

attribute mark_debug : string;
attribute mark_debug of s_axis_tvalid : signal is "true";
attribute mark_debug of s_axis_tvalid_reg : signal is "true";


  if(rising_edge(clk)) then
    s_axis_tvalid_reg <= s_axis_tvalid;
  end if;
end process;

In the case that any signal within the architecture is marked as debug, the signal s_axis_tvalid_reg does not change when the signal s_axis_tvalid changes (same clock). The signal s_axis_tvalid_reg stays constant zero. This has been observed by probing the two signals with an ILA core as well as extern probing with an digital oscilloscope. In the case that the signal is not marked as debug and no ILA-core is instantiated, the extern probing shows the expected results: s_axis_tvalid_reg follows s_axis_tvalid.


In most cases mark_debug works as expected, but with this phenomenon, the ila-core debugging is not helpful, rather the contrary.


Does anyone have ideas on what might be the cause?

Many Thanks,

0 Kudos
3 Replies
Registered: ‎06-05-2013

@voco-mannheim Can you open the implemented design and look for connectivity of the signal s_axis_tvalid_reg? Please post screenshot if it is correct.


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
Registered: ‎10-16-2013

@pratham, thanks for your reply.


I have attached the requested screenshot of the implemented design view, showing the connectivity for the problemativ signal (signal tagged with MARK_DEBUG attribute). No arrows/lines show up for the problematic signal, which is the case for other signals.


The connectivity tables (signal properties tab) for the signals are as follows (I've shortened some of the signal names)


Table for s_axis_tvalid_reg:


Name Cell Pin Cell Cell Pin Count Net Delay (ps)
TEST_1_OBUF_inst I OBUF 2  
*/a_reg[2]_i_1 I1 LUT5 6  
*/a_reg[3]_i_1 I1 LUT5 6  
*/a_reg[4]_i_1 I1 LUT5 6  
*/counter[3]_i_5 I1 LUT2 3  
*/sync[1]_i_1 I1 LUT5 6  
*/reset_pipe[0]_i_1 I1 LUT4 5  
*/reset_pipe[1]_i_1 I1 LUT4 5  
*/reset_pipe[2]_i_1 I1 LUT4 5  
*/reset_pipe[3]_i_1 I1 LUT4 5  
*/enable_i_1 I2 LUT5 6  
*/counter[16]_i_6 I3 LUT6 7  
*/a_reg[0]_i_1 I4 LUT6 7  
*/a_reg[1]_i_1 I4 LUT6 7  
*/counter[16]_i_1 I4 LUT5 6  
*/s_axis_tvalid_reg_reg Q FDRE 5  
*/dN.need_fast_input.dN.d_tmp[0]_i_1 I1 LUT2 3  


Table for s_axis_tvalid_reg


Name Cell Pin Cell Cell Pin Count Net Delay (ps)
TEST_0_OBUF_inst I OBUF 2  
*/s_axis_tvalid_reg_reg D FDRE 5  
*/buffer_out_tready_inferred_i_1 I1 LUT2 3  
*/b_inst/m_axis_tvalid_i_reg[1] Q FDRE 5  
*/ram_empty_fb_i_i_1 I0 LUT6 7  
*/ram_full_fb_i_i_1 I0 LUT6 7  





The connectivity table is filled, but no arrows are visable for the signal in the other view.


Recap: Only setting the MARK_DEBUG attribute to signals in a VHDL architecture cause the problem, not even necessarily the problematic must be marked, others will cause the same effect. No further changes in the project.


By the way, is there a maximum number of signals which can be marked as debug (not necessarily connected to an ILA-Core)? If that is the case, will Vivado print a warning in the log files? Are there any other restrictions?


Best regards,




0 Kudos
Registered: ‎11-18-2013

I have seen similar results using vivado 2016.2 and maybe also 2016.1 this was one of the reason I had stayed with 2015.4. But now again I'm trying to go with 2016.2.   What version of vivado are you using?   Try using Performance_ExporePostRoutePhysOpt strategy in the  implementation this may take care of it for now.    Please let me know it this works,  also does Xilinx have any info relating to this situation?  Thanks. 

0 Kudos