注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

paul.mcdean的博客

 
 
 

日志

 
 

High Performance Synthesis -(7)  

2007-05-06 18:57:15|  分类: Digital |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

Implicit dont_touch’s

If a cell is found which has an abnormally high delay, check to see if the highest drive strength is being used.  If not, the reason is often an implicit dont_touch.  An implicit dont_touch is a dont_touch that was not explicitly placed on an object (via the set_dont_touch or set_attribute commands).  A dont_touch (whether implicit or explicit) on a cell will prevent sizing of the cell.  There are several causes of implicit dont_touch’s.

Causes of Implicit dont_touch’s

Comments

set_disable_timing

A set_disable_timing on a cell puts a dont_touch on the cell

-through timing exceptions

A –through on a cell’s pin puts a dont_touch on the cell

create_clock

A create_clock on a cell’s pin puts a dont_touch on the cell

set_dont_touch_network

Places a dont_touch on all nets and mapped combinational cells within the fanout cone of the set_dont_touch_network object

set_dont_touch on a net

Places a dont_touch on all mapped cells connected to the net

combinational feedback loops

Design Compiler automatically breaks the loop similar to doing a set_disable_timing on a cell; this places a dont_touch on the cell

path segmentation (set_input_delay or set_output_delay on a cell’s pin).

Places a dont_touch on the cell.  Largely an obsolete technique since the release of 1998.02’s –through switch.


An explicit dont_touch can be confirmed by performing a get_attribute on the object (e.g. ‘get_attribute u100 dont_touch’).  To find implicit dont_touch’s run a report_cell or report_net on the object.  To find the cause, redirect a write_script report to a file and search for ‘dont’.  An implicit dont_touch can not be removed via remove_attribute; to remove the implicit dont_touch, remove the cause.

Look at the DesignWare implementations selected

Design Compiler evaluates DesignWare implementations during full and incremental compiles.  Even so a report should be run to identify the implementations used for DesignWare parts along the failing paths.  This is done via the report_resources command.  To report this data throughout the hierarchy, use the find_dw_implementations.scr script found in Solvit article Synthesis-312.

If a RPL adder or CSA multiplier is found, verify that the faster DesignWare components are enabled as discussed in Section 4.8.  Also be sure that good selections were made before ungrouping any DesignWare components.  set_implementation will force Design Compiler to use the specified implementation during subsequent compiles (full or incremental).

Direct where Design Compiler focuses

Sometimes the critical paths of a design fall along the top-level I/O’s.  When this occurs the I/O delay constraints should be re-examined to verify they are realistic.  I/O constraints are often developed early in a project and may end up being highly unrealistic.  If this is the case Design Compiler will focus on these paths and not attempt to improve the register-to-register paths.  If the I/O constraints are unrealistic, the solution is to re-negotiate the constraints with the owner of the interfacing blocks or ASIC’s.  However in the meantime the designer may wish to direct Design Compiler to focus on the register-to-register paths.  Creating new path groups for the I/O paths will do this.

group_path -name in_paths  -critical_range 0.0 -from all_inputs()

group_path -name out_paths -critical_range 0.0 -to   all_outputs()

By default a path group exists for each clock domain.  Creating separate path groups for the I/O’s leaves the register-to-register paths in the original path group(s).  Since Design Compiler attempts to optimize the worst violator of each path group it will now work on the register-to-register paths in addition to the I/O’s.  The -critical_range  switch is optional.  Here it is being used to override any global critical range that has been set.  This will direct Design Compiler to devote less time to the I/O paths.

Update the sub-block drive and loading constraints

If Design Budgeting is not being used, it is difficult and time consuming to update the time budgets of sub-blocks.   However it is still easy to update the sub-block drive and load constraints.  This can be done with the characterize command.  First each sub-block is characterized, then all of the drive and load constraints are separated out.  Solvit article Methodology-47 contains a script, which characterizes each sub-block at the top of the hierarchy and separates out the drive and load constraints via a Perl script.

  评论这张
 
阅读(26)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017