使用setup文件。
DC在invoke起来时，会顺序的执行三个setup文件。
(1) ~usr/.synopsys_dc.setup
(2) 安装路径/admin/setup/.synopsys_dc.setup
(3) DC_当前工作目录cwd/.synopsys_dc.setup
考虑到，我们每次invoke起来，都需要设置 search_path、target_library、link_library、我们可以把这些都放在一个文件里面，
放到(3)下面，这样每次启动，都自动调用了。
步骤1:
编写一个文件，名字必须为：以小数点起头 .synopsys_dc.setup 修改成其它就不会生效。
步骤2: 启动DC ，查看是否设置成功。
复杂top结构。
如下图 ： My_TOP层包括了两个verilog_module，一个ram的模型。还有两个ddc文件。
ddc文件，是一个已经综合好的文件，它包括了timingareadb等等详细的信息、当然肯定包括最基本module名字、接口信息。我们可以直接例化。
ram是一个.db文件，它有工艺厂提供，是一个真实的ram，内部包含timingareadb等等详细的信息，也必然包括ram名字、接口信息，我们也可以直接例化。
在这里，我们之所以不适用verilig文件，是因为我们不想让dc去综合这些，要把它们当成黑盒子处理。
这个时候，我们cwd是这样布局的：
首先需要把所需要的文件读进来 ： top.v A.v B.v 两个ddc文件读进来，db文件不用read命令，但是呢 我们设置targetlink的时候会指定，相当于读入了。
完毕之后，涉及到一个current_design的问题。current_design是一个指针，指向hierarchy的某一层，指向半山腰，那后续所有的行为，
山腰上面的东西都会被忽略，显然跟我们预期不符合。需要我们手动指定 set current_design my_top
link行为：
指定好之后，我们要对hierarchy建模，即层层分解例化。保证整个树干是健全的。
check_design行为：
link查看树干之后，我们还要确保连线是正确的，只能说dc比较傻，没有一步到位。
以上三步全部pass，才代表我们这个hierarchy树是枝繁叶茂的。推荐流程如下：对每一步骤都进行检查
这里我们需要特别讲下：link怎么去层层分解例化。
(1) local_library --- 这个一般没有。
(2) link_library “ * $target.db ram.db "
(3) search_path
首先，dc读入了许多verilog文件，它会自动的把他们的module名存起来，当成一个个的design来看待。 这就是 * 的意义
进行link时首先去这里找，能找到直接就用了。 如果找不到， 开始去link_library里面找。
link_library是db文件，我们知道 db----lib是对应的，lib里面有各种stdcel的名字、接口信息。dc会去匹配，看能不能找到例化所需的。
如果还没有找到，就去search_path里面去找了。search_path比较杂乱，是各种路径，dc会翻遍这些路径下的 db、ddc文件，再找不到就得报错了。
DC到底综合哪些东西？
我们知道dc第一步 把HDL翻译成gtech，然后在迭代优化映射。 那么对于dbddc文件，dc会进行怎么样的处理？
我觉得，db、ddc都是已经综合好的结果，dc应该不会对它进行操作了。只对verilog等描述型电路进行建模分析映射。 这个问题留到后面解答。
ddc文件时什么 ？
还没搞得很清楚，只知道，它比verilog文件，包含的信息更多，而且是二进制文件、不是字符型文件，方便DC快速读取。
（1） 在compile之前，预先保存一把。
(2) 在compile之后，再保存一个。供其他工具使用
初次之外，我们还会生成一个netlist.v，供后仿真用。
这里都使用了 -hierarchy 选项，即生成全部层级结构的。
实验lab2总结：
复盘: 一开始读入verilog时候，cwd出现了大量的中间文件。 查了read_vhdl也没找到怎么修改存储路径。后来在student guide里面有。
之后读入之后，link时，报错 无法read sc_max.db ，一开始以为是vhdl和verilog不一样呢。 后来才发现 search_path路径写错了，dc找不到这个文件根本。
其实应该在dc invoke的时候就报出来了，没仔细看。
之后读入vhdl、设置current-design、link、check_design、保存一个ddc文件，进行compile，再保存一个ddc。exit退出。