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: 
Highlighted
Explorer
Explorer
7,052 Views
Registered: ‎11-23-2009

SCOPED_TO_REF, DONT_TOUCH, and opt_design

I have entities with clock domain crossing and found it very helpful to put the required constraints into a xdc file which is marked SCOPED_TO_REF. Very modular and reliable.

 

Than I found in the project directory a file called dont_touch.xdc with lines like

  # XDC: .../cdc_pulse.xdc
  set_property DONT_TOUCH TRUE [get_cells -hier \
       -filter {REF_NAME==cdc_pulse || ORIG_REF_NAME==cdc_pulse}]

 

actually one such line for each entity with a SCOPED_TO_REF xdc.

 

The manual states

DONT_TOUCH: The DONT_TOUCH works the same way as the KEEP. However unlike the KEEP, DON’T_TOUCH is forwarded-annotated to place and route to prevent logic optimization.

 

Does that mean that all entities which have a SCOPED_TO_REF xdc are automatically excluded from optimization, that opt_design for example ignores them ?

 

That would be quite a heavy restruction given that opt_design for most entities reduces logic size quite bit and also given that SCOPED_TO_REF'ed xdc are the recommended way of stating constraints for cores.

 

Looking forward to comments.

 

 

0 Kudos
3 Replies
Xilinx Employee
Xilinx Employee
7,023 Views
Registered: ‎09-20-2012

Re: SCOPED_TO_REF, DONT_TOUCH, and opt_design

Hi @wfjmueller

 

DONT_TOUCH on the module just avoids boundary optimizations. It is same as KEEP_HIERARCHY in ISE. The module is still optimized internally.

Thanks,
Deepika.
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (the star on the left)
Xilinx Employee
Xilinx Employee
6,966 Views
Registered: ‎09-20-2012

Re: SCOPED_TO_REF, DONT_TOUCH, and opt_design

Hi @wfjmueller

 

Did that answer your query?

Thanks,
Deepika.
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (the star on the left)
0 Kudos
Explorer
Explorer
6,216 Views
Registered: ‎11-23-2009

Re: SCOPED_TO_REF, DONT_TOUCH, and opt_design

@vemulad

 

I did some tests and varied for a modest sized design the -flatten_hierarchy setting and and/or applied DONT_TOUCH, KEEP and KEEP_HIERARCHY constraints to the top level or all non-primitive cells of the design. Also enabled/disabled the opt_design stage. Results are summarized in the following table with should self-explaining

 

  flop  lutl  lutm  bram  slic     WNS   flatten  DONT  KEEP  KEEP_H  opt_design
  2648  4963   150  11.0  1594 0.244ns   rebuilt    no    no    no     on
  2641  5255   154  11.0  1669 0.422ns      none    no    no    no     on
  2648  4927   150  11.0  1600 0.359ns      full    no    no    no     on
  2693  4962   150  11.0  1652 0.333ns      full    no    no    no    off
  2714  5304   150  11.0  1701 0.424ns   rebuilt   top    no    no     on
  2648  4955   150  11.0  1613 0.393ns   rebuilt    no   all    no     on
  2675  5345   154  11.0  1739 0.431ns   rebuilt    no    no   all     on
  2675  5345   155  11.0  1739 0.431ns   rebuilt    no   all   all     on

 

So the impact of a DONT_TOUCH to all top level non-primitive cells is about the same as a KEEP_HIERARCHY.

 

Nevertheless is the documentation not very clear. UG901 states

 

DONT_TOUCH
   Use DONT_TOUCH attribute in place of KEEP or KEEP_HIERARCHY and works in 

   the same way as these attributes. However, unlike KEEP and KEEP_HIERARCHY,  
   DONT_TOUCH is forward annotated to place and route to prevent
   logic optimization.

 

KEEP
   Use the KEEP attribute to prevent optimizations where signals are either 
   optimized or absorbed into logic blocks. This attribute instructs the
   synthesis tool to keep the signal it was placed on, and that signal is placed

   in the netlist.

 

KEEP_HIERARCHY
   KEEP_HIERARCHY is used to prevent optimizations along the hierarchy
   boundaries. The Vivado synthesis tool attempts to keep the same general  
   hierarchies specified in the RTL, but for QoR reasons it can flatten or
   modify them.

 

From that it is clear that KEEP and KEEP_HIERARCHY are quite different things, KEEP more tuned to act on the nets and cells within on entity, while KEEP_HIERARCHY acts on the interface between entities.

 

UG901 states "Use DONT_TOUCH attribute in place of KEEP or KEEP_HIERARCHY", and the "or" suggests that it actually does both, first at synthesis level, and by forward annotation, enforces this in later optimization.

 

The automatic generation of DONT_TOUCH'es for all SCOPED_TO_REF xdc suggests that this is done as sort of 'brute force' method to guarantee that constraints can be set on all cells and nets seen after elaboration.

 

That's a bit more that what I read out of the statement "just avoids boundary optimizations".

 

With best regards,  Walter

 

 

0 Kudos