第一节,介绍了target_library的作用，以及dc打开、读入verilog、指定target_library、读入约束文件、
进行compile、输出结果这个过程。
第二小节: 从输出的mapped.v开始。如果想迭代的进行综合,那么读入上一次的输出netlist,进行再修改时最好的。
第一步:
看起来和读入verilog差不多。
第二步:
设置target_library 并 直接进行compile.
我们可以看到,它直接报错了, 并有Warning提示说 有两个例化找不到. 哪两个呢? 我们看下 mapped.v文件,如下
为什么找不到呢? 这要从link说起。
当读入了所有的verilog-file_list之后，dc并不进行层层例化. 只有执行link命令时,才对其进行层层例化.
就跟变形金刚一样,只有启动按钮,才会咔咔咔的变身,丰满羽翼.
怎么执行层层例化? -----去 link_library里面找。
显然link_library应该包括： 所有读进来的verilog_module，还有比如padRAMFlash
等model模型的db文件。还有target_library.
一一介绍: 首先用 * 通配所有读进来的模块、
pad amflash,使用其.db文件
target_library 适用于读入netlist这种情况。
* 通配文件 : 当例化时，发现verilog module对应的，就直接例化就好了，这本来就是设计好的。
pad.db文件: 为什么不直接用verilog文件? 我们知道，在SOC设计中，RAM、PAD、FLASH的这些verilog
都是模型 因为PAD是模拟电路，放一个模型是为了仿真、RAM也是模型.里面有setup仿真检查。
所以这些verilog文件，我们都是放在 model_file_list里面的,不会放到正宗的verilog_file_list里面
不把他们读入dc,是因为它们不一定能综合。因为里面有太多的不可综合语句..
所以用其真正的db文件替代(工艺厂提供)。
$target_library ：link_library包括这个db库，纯粹是为了读入netlist考虑的。因为回读mapped.v ，里面例化的
都是stdcell, 这些都在 $target_library里面,所以是必须包含的.
语法 : set link_library " * ram.db $target_library "
第三步 :
设置link_library，进行设置，并进行compile
可以看出结果是对的.
search_path的作用
在我们以上的设计中，无论读入、还是set变量都使用了 路径+文件名这种方式。其实DC支持省略路径的写法。
前提是,我们把所有的路径信息汇总到一个变量search_path里面去。dc每次都进行匹配就好了。
步骤
从上图中. 我们不用再一一的指定路径了,其实这种方式在脚本语言中应用比较好,
在dv里面，加相对路径，有table补全，也挺实用。