<DC guide ---5>

我们知道dc是为了约束.可是要约束谁? 怎么能把位置描述清楚.?

DC在读入所有的verilog文件,link、check_design后,把整个current树分成了一下几个组成:

所有吃进来的module,都称为design. 只有current-design的 in/out 被称为Port

内部所有的例化,统一称呼为cell,cell的in/out称为pin.

剩余的连接线, 统一称呼为net.  通过这些,基本上就能细分了. 至于clock是特殊的一种.先不讲 .

在这幅图中 design 有 { TOP ENCODER REGILE }    INV因为是stdcell,不是verilog描述的,所以不能算design

cell有 { u1 u2 u3 u4}

需要详细的了解下:  design\port\cell\pin\net\clock的用法,   以get_designs为例子     这6个有一个共同的称呼:  Object 对象.

get_designs

get_designs : 返回所有的design名字。 包括current-design、以及所有吃进去的verilog module

get_designs -h  :  把current_design剔除掉,只是其他的designs

-quiet :  压住warning信息不报.

-regexp  进行正则匹配,而不是使用dc内部的简单匹配。

-nocase  不区分大小写

-exac  :  貌似是不匹配简单项目,

-filer expression  :  先get出结果,然后用expression对所有的结果进行过滤。得到最终的结果

pattern   匹配表达式.

使用 -regexp 选项, 此时使用的是TCL的正则表达式.  最好用 {} 括起来.这个时候   *表示任意数量  . 表示一个字符  ?表示0/1数量。

不适用 -regexp   * 代表任意多个字符   ?代表1个任意字符

看下下面的例子:   get_designs获得所有。

get_designs -h  剔除current_design

-nocase -regexp 选项搭配。

还需要注意一点 , get-designs 返回值不是list. 是一个collection.  本节最后,会将collection到底是什么.

虽然从dc界面上看像是一个list.但其实是一个collection.可以套接在 collection命令上.

常见的collection命令有:  add_to_collection    remove_from_collection  quiet_objects  sizeof_collection   filter_collection

我们知道 get_*  获得的是collection,然后可以对其使用  add_to_collection    remove_from_collection  quiet_objects  sizeof_collection   filter_collection

这些命令进行 更细致的操作,从而得到想描述的object.

set foo [get_designs *]

set  foo   [ add_to_collection  $foo [get_ports *] ]    在foo的基础上增加ports

set foo [remove_from_collection $foo [get_designs *] ]  在foo的基础上剔除掉designs,只剩下ports了

sizeof_collection  $foo 得到是ports的个数。

quiery_objects $foo 得到ports的列表.

filter_collection 是依据 collection元素的属性进行筛选的. 简化变成get_* 的   -filter expression选项了。

需要理解一点: collection是集合, 很多元素的集合. 而且这些元素还有不同的属性, dont_touch、is_mapped、is_cell、is_hierarchical等等。

我感觉整个collection是这样的一个结构.

collection由元素组成,元素又有各种不一样的属性。   我们综合时,就是要找到元素,确认其属性,对其增加属性。

DC综合时,也需要去根据我们 设置的属性,  当然 prots\pin\design\cell\net\colck\自己本身的attribution都不一样。

我们可以使用  list_attribute -class cell 查看cell的attribution。

我们约束的语法: 增加\删减 每个attribution,达到我们的综合目的.

后面的章节我们就要学习: 要去设置哪些属性

我理解进行约束的过程,可以分成以下三步

(1)  get_*  粗略获得object、

(2) collection命令 微调object、

(3) 对目标object,  增加\删减 attribution.

通过这三步,我们就能把约束,添加到目标位置.  达到了精确制导.  所有的语法都是为这个目的服务的.

时间: 2024-08-03 20:30:43

<DC guide ---5>的相关文章

CI框架源码阅读笔记3 全局函数Common.php

从本篇开始,将深入CI框架的内部,一步步去探索这个框架的实现.结构和设计. Common.php文件定义了一系列的全局函数(一般来说,全局函数具有最高的加载优先权,因此大多数的框架中BootStrap引导文件都会最先引入全局函数,以便于之后的处理工作). 打开Common.php中,第一行代码就非常诡异: if ( ! defined('BASEPATH')) exit('No direct script access allowed'); 上一篇(CI框架源码阅读笔记2 一切的入口 index

IOS测试框架之:athrun的InstrumentDriver源码阅读笔记

athrun的InstrumentDriver源码阅读笔记 作者:唯一 athrun是淘宝的开源测试项目,InstrumentDriver是ios端的实现,之前在公司项目中用过这个框架,没有深入了解,现在回来记录下. 官方介绍:http://code.taobao.org/p/athrun/wiki/instrumentDriver/ 优点:这个框架是对UIAutomation的java实现,在代码提示.用例维护方面比UIAutomation强多了,借junit4的光,我们可以通过junit4的

Yii源码阅读笔记 - 日志组件

?使用 Yii框架为开发者提供两个静态方法进行日志记录: Yii::log($message, $level, $category);Yii::trace($message, $category); 两者的区别在于后者依赖于应用开启调试模式,即定义常量YII_DEBUG: defined('YII_DEBUG') or define('YII_DEBUG', true); Yii::log方法的调用需要指定message的level和category.category是格式为“xxx.yyy.z

源码阅读笔记 - 1 MSVC2015中的std::sort

大约寒假开始的时候我就已经把std::sort的源码阅读完毕并理解其中的做法了,到了寒假结尾,姑且把它写出来 这是我的第一篇源码阅读笔记,以后会发更多的,包括算法和库实现,源码会按照我自己的代码风格格式化,去掉或者展开用于条件编译或者debug检查的宏,依重要程度重新排序函数,但是不会改变命名方式(虽然MSVC的STL命名实在是我不能接受的那种),对于代码块的解释会在代码块前(上面)用注释标明. template<class _RanIt, class _Diff, class _Pr> in

CI框架源码阅读笔记5 基准测试 BenchMark.php

上一篇博客(CI框架源码阅读笔记4 引导文件CodeIgniter.php)中,我们已经看到:CI中核心流程的核心功能都是由不同的组件来完成的.这些组件类似于一个一个单独的模块,不同的模块完成不同的功能,各模块之间可以相互调用,共同构成了CI的核心骨架. 从本篇开始,将进一步去分析各组件的实现细节,深入CI核心的黑盒内部(研究之后,其实就应该是白盒了,仅仅对于应用来说,它应该算是黑盒),从而更好的去认识.把握这个框架. 按照惯例,在开始之前,我们贴上CI中不完全的核心组件图: 由于BenchMa

CI框架源码阅读笔记2 一切的入口 index.php

上一节(CI框架源码阅读笔记1 - 环境准备.基本术语和框架流程)中,我们提到了CI框架的基本流程,这里这次贴出流程图,以备参考: 作为CI框架的入口文件,源码阅读,自然由此开始.在源码阅读的过程中,我们并不会逐行进行解释,而只解释核心的功能和实现. 1.       设置应用程序环境 define('ENVIRONMENT', 'development'); 这里的development可以是任何你喜欢的环境名称(比如dev,再如test),相对应的,你要在下面的switch case代码块中

Apache Storm源码阅读笔记

欢迎转载,转载请注明出处. 楔子 自从建了Spark交流的QQ群之后,热情加入的同学不少,大家不仅对Spark很热衷对于Storm也是充满好奇.大家都提到一个问题就是有关storm内部实现机理的资料比较少,理解起来非常费劲. 尽管自己也陆续对storm的源码走读发表了一些博文,当时写的时候比较匆忙,有时候衔接的不是太好,此番做了一些整理,主要是针对TridentTopology部分,修改过的内容采用pdf格式发布,方便打印. 文章中有些内容的理解得益于徐明明和fxjwind两位的指点,非常感谢.

CI框架源码阅读笔记4 引导文件CodeIgniter.php

到了这里,终于进入CI框架的核心了.既然是"引导"文件,那么就是对用户的请求.参数等做相应的导向,让用户请求和数据流按照正确的线路各就各位.例如,用户的请求url: http://you.host.com/usr/reg 经过引导文件,实际上会交给Application中的UsrController控制器的reg方法去处理. 这之中,CodeIgniter.php做了哪些工作?我们一步步来看. 1.    导入预定义常量.框架环境初始化 之前的一篇博客(CI框架源码阅读笔记2 一切的入

jdk源码阅读笔记之java集合框架(二)(ArrayList)

关于ArrayList的分析,会从且仅从其添加(add)与删除(remove)方法入手. ArrayList类定义: p.p1 { margin: 0.0px 0.0px 0.0px 0.0px; font: 18.0px Monaco } span.s1 { color: #931a68 } public class ArrayList<E> extends AbstractList<E> implements List<E> ArrayList基本属性: /** *

dubbo源码阅读笔记--服务调用时序

上接dubbo源码阅读笔记--暴露服务时序,继续梳理服务调用时序,下图右面红线流程. 整理了调用时序图 分为3步,connect,decode,invoke. 连接 AllChannelHandler.connected(Channel) line: 38 HeartbeatHandler.connected(Channel) line: 47 MultiMessageHandler(AbstractChannelHandlerDelegate).connected(Channel) line: