UPGRADE YOUR BROWSER

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!

cancel
Showing results for 
Search instead for 
Did you mean: 
4,589 Views
Registered: ‎01-22-2015

DONT_TOUCH basics

Jump to solution

With regards to the DONT_TOUCH attribute for HDL signals, I understand that synthesis logic optimization affects only combinational logic and not registers?   So, if a signal in my HDL results from combinational logic operations, then this signal could be removed from the netlist when synthesis combines combinational logic blocks (eg. LUTs) during optimization.   However, if a signal in my HDL is the output of a register then this signal will always appear in the netlist because optimization cannot remove/combine registers?

 

Ug901 says that DONT_TOUCH can help with writing timing constraints by ensuring that signal names used in the constraints are not optimized out.   However, I thought that timing constraints almost always use register names or port names and these are never optimized out?

 

So many questions – sorry!   I guess I’m looking for examples and explanation of when and when-not to use DONT_TOUCH.

0 Kudos
1 Solution

Accepted Solutions
Explorer
Explorer
6,073 Views
Registered: ‎03-31-2016

Re: DONT_TOUCH basics

Jump to solution

@markg@prosensing.com wrote:

With regards to the DONT_TOUCH attribute for HDL signals, I understand that synthesis logic optimization affects only combinational logic and not registers?  

 


Totally untrue, Synthesis will optimize registers.

 

DONT_TOUCH will prevent any optimizations to that object.  It is often necessary when manually replicating a register for fanout reasons.

 

KEEP is a related attribute that only impacts combinational signals.

 

Timing constraints are ultimately for the path between registers (or  external pins) but can be specified in ways that include net names.

 

You should avoid using DONT_TOUCH(or KEEP) unless you are having problems to let the tools optimize as much as possible.  For the most part the basic timing constraints will be written with tcl commands getting the objects so you don't have to be too concerned with optimizations changing the names.

Tags (1)
9 Replies
Explorer
Explorer
6,074 Views
Registered: ‎03-31-2016

Re: DONT_TOUCH basics

Jump to solution

@markg@prosensing.com wrote:

With regards to the DONT_TOUCH attribute for HDL signals, I understand that synthesis logic optimization affects only combinational logic and not registers?  

 


Totally untrue, Synthesis will optimize registers.

 

DONT_TOUCH will prevent any optimizations to that object.  It is often necessary when manually replicating a register for fanout reasons.

 

KEEP is a related attribute that only impacts combinational signals.

 

Timing constraints are ultimately for the path between registers (or  external pins) but can be specified in ways that include net names.

 

You should avoid using DONT_TOUCH(or KEEP) unless you are having problems to let the tools optimize as much as possible.  For the most part the basic timing constraints will be written with tcl commands getting the objects so you don't have to be too concerned with optimizations changing the names.

Tags (1)
Scholar jmcclusk
Scholar
4,563 Views
Registered: ‎02-24-2014

Re: DONT_TOUCH basics

Jump to solution

Registers can be removed during optimization too, either collapsing duplicate registers, or by register retiming.    If you apply DONT_TOUCH to a signal that is a register output, the DONT_TOUCH property will also migrate to the register cell in the netlist, preventing it from being moved or eliminated.    DONT_TOUCH is also a Synopsys property, so it's one of a very few attributes that can be claimed to make code "Non-portable", since most Vivado attributes are ignored by other tools.

 

Examples:

attribute dont_touch : string;
attribute dont_touch of example_dt_vhd : entity is “true|yes”;
attribute dont_touch of sig1 : signal is “true”;
attribute dont_touch of my_comp : component is “yes”;
attribute dont_touch of rtl : architecture is “yes”;

attribute keep : string;
attribute keep of sig1 : signal is “true”;

 The major difference between DONT_TOUCH and KEEP is that KEEP only applies during synthesis, and evaporates once the design is handed off to place and route.   MARK_DEBUG has a similar property to KEEP, preventing a net from being removed.

 

Don't forget to close a thread when possible by accepting a post as a solution.
Scholar ronnywebers
Scholar
4,562 Views
Registered: ‎10-10-2014

Re: DONT_TOUCH basics

Jump to solution

@necare81, thanks for the explanation.

 

can the tools be instructed to 'replicate' a specific register (without writing it in code and using DONT_TOUCH?), to fix a large fanout problem? 

** kudo if the answer was helpful. Accept as solution if your question is answered **
Scholar jmcclusk
Scholar
4,551 Views
Registered: ‎02-24-2014

Re: DONT_TOUCH basics

Jump to solution

Driver replication should NEVER be done during synthesis!   There's a very good reason for this.. it MUST be done AFTER placement!    The synthesis tools have absolutely no idea about placement, or distribution of loads for a high fanout net.   The proper place to replicate drivers is after placement,  during the phys_opt_design pass.    At this point, once everything is placed, then phys_opt_design has a very good idea how to split the high fanout net, and to insert new drivers at good locations.   I've seen reset nets with 10 or 11 drivers,  all placed nicely after phys_opt_design does it's work.

 

To force driver replication on a target net, phys_opt_design can be called like so:

phys_opt_design -force_replication_on_nets  [get_nets -hier some_target_net]

Don't forget to close a thread when possible by accepting a post as a solution.
4,533 Views
Registered: ‎01-22-2015

Re: DONT_TOUCH basics

Jump to solution

Thanks guys!

 

@necare81  You should avoid using DONT_TOUCH(or KEEP) unless you are having problems...

@jmcclusk   DONT_TOUCH is also a Synopsys property, so it's one of a very few attributes that can be claimed to make code "Non-portable"...

 -in general, DONT_USE  DONT_TOUCH - got it !

 

@ronnywebers Thanks for prompting jmcclusk to talk about phys_opt_design - an important related topic.

 

@jmcclusk  Registers can be removed during optimization too, either collapsing duplicate registers...

I understand from necare81 that "replicated registers for fanout reasons" is an example of duplicate registers that may be collapsed/combined during optimization.  Can you speak a little more about "collapsing duplicate registers" and give other examples?

 

@jmcclusk  What is indication from Vivado that forced use of phys_opt_design is needed?

 

Tags (1)
0 Kudos
Scholar jmcclusk
Scholar
4,515 Views
Registered: ‎02-24-2014

Re: DONT_TOUCH basics

Jump to solution

Duplicate registers occur naturally in designs with hierarchy, typically when a signal is distributed to multiple modules that all sample the signal with a register on the module input.  They can also occur in the RTL, if the designer is a little careless, and creates multiple copies of a registered signal, usually with different names, so it's not obvious.

 

Regarding the usage of phys_opt_design to split a driver net,  the most obvious indication is a setup timing failure on a high fanout net.   Sometimes the timing failure will be occasional, other times more frequent.   Explicitly calling phys_opt_design in a compilation script usually enhances the chances of timing closure on difficult designs.

Don't forget to close a thread when possible by accepting a post as a solution.
Highlighted
4,500 Views
Registered: ‎01-22-2015

Re: DONT_TOUCH basics

Jump to solution

I started commenting out my many (usually incorrect) uses of DONT_TOUCH.  As necare81 says, synthesis optimization now finds lots of things to improve.  As jmcclusk says, parallel registers were found and combined - usually in unexpected places.  Some XDC constraints needed to be rewritten because of these register combinations.

 

Such great answers from everyone - so happy - many thanks!!
0 Kudos
Explorer
Explorer
3,582 Views
Registered: ‎11-13-2009

Re: DONT_TOUCH basics

Jump to solution

@jmcclusk

 

I have a situation that I thought the "KEEP" was preventing replication.  But after reading your entry I am not so sure.  I am using V2017.4.  

 

I have a net which I believe would be helped by replication.  It is loaded about 1000 but shows up in this one critical math segment for the entire 33-bit bus.  Yes funny sized math.  I have used physopt replication successfully before on other project but this one is kind of stumping me.

 

Is there a way to get more of a explanation about why physopt didn't replicate?  Some of the other signals it indicates were marked with DONT_TOUCH which I now understand to be bad.

 

Finally anyone know a way to remove the DONT_TOUCH attribute either post_synthesis or pre_implementation?  I can narrow down to just the design portion in question.

 

TomT...

 

0 Kudos
Scholar jmcclusk
Scholar
3,572 Views
Registered: ‎02-24-2014

Re: DONT_TOUCH basics

Jump to solution

I believe that a DONT_TOUCH attribute would prevent phy_opt from replicating drivers, but KEEP normally evaporates after synthesis, and has no further effect.   

 

If you want to try some netlist wrangling and remove the DONT_TOUCH attributes post-synthesis, this can be done in TCL easily enough.   Just run a post-synth TCL script that searches for the attribute in the cell list.  i.e.

 

[get_cells -hier -filter { DONT_TOUCH == "true" } ]

 

and once you find the ones you want..

 

set_property DONT_TOUCH false $some_cell_list

Don't forget to close a thread when possible by accepting a post as a solution.
0 Kudos