以上编写的脚本有实际的限制。多数设计有许多层次体系，不需独立编译。当编译体系层次的接口时，高层的编译有个优点。设计编译器能反复定义接口两边的逻辑，它不受don't_touch的限制。
BSDO方法说明了较高层的编译也能产生高质量的结果。这种现象依赖于设计。通过隔离关键的路径，低层编译可能进行较快的设计。或通过屏蔽交叉体系边界的关键路径，它们也可能进行较慢地设计。正如在BSDO中AM2910所演示的例子一样，当同等价的低层编译比较时，高层的编译也可能进行较小规模的设计。认识到这个效果，许多设计者想在CRWC脚本中限制树贯串的深度，以便在体系结构中仅高层的设计特征化（编译）。
遗憾是，层次level的属性不能特别借来很好地改进这种算法。低层设计可能在设计体系的高层独占存在。为增强CRWC脚本，限制体系结构的贯穿深度，需要一种属性表明每个设计的层次深度（从顶至下计算），弥补层次的属性。Top体系结构的属性标志如下：
作设计深度标志的规则必需同设计层次的赋值规则相反。设计的深度是同设计相关体系结构的最高层的深度（或等价，有设计实例存在的最高体系级别）。在这个体系结构中设计A的深度为1，尽管它存在于深度为1和2的设计体系中。Top深度为0，A和B的深度为1，1和2的深度为2。
一个增强的 label_hierarchy脚本，它可以在设计树中设置层次和深度属性。由于定义了深度属性，“深度首先”
（depth-first）和“宽度首先”（breadth-first）脚本仅需作细小的修改就可在具体的深度“到底”（bottom out）-停止层次贯串。
上面虽然介绍了计算机科学术语深度首先（depth-first）和宽度首先（breadth-first）,执行搜寻的脚本还是命名为根首先（root-first）和叶首先（leaf-first）。深度首先（depth-first）和宽度首先（breadth-first）保留用作增强的脚本，它是按深度而不是层次贯串，因增强的算法和典型的计算机科学的定义深度首先（depth-first）和宽度首先（breadth-first）更加一致。
两套脚本对于不同的应用是有用途的。增强的搜寻脚本继承原来脚本的优点而不是荒废它。在这些脚本中，变量depth_limit用来辨别搜寻的深度。对于不同的设计有不同的depth_limit是合适的，设计中设置limit属性表明每个设计有适当的depth_limit。深度首先（depth-first）和宽度首先（breadth-first）的脚本分别命名为DFS.scr和BFS.scr。
一般而言，每次一个子设计变化就要重新编译整个设计体系是不令人满意的。使用CRWC容易进行重新编译单个的设计。简单地把修改的设计读进设计编译器，其中设计的write_script文件采用前面修改的约束，它是由CRWC脚本的设计体系所衍生的。接着发出一个编译命令。可以编写文件自动执行这个过程。虽然提出这个方法，许多设计者从来没有使用过compile_hierarchy脚本。
通过删除最后的5行命令，compile_hierarchy脚本可以变成charactrize_hierarchy脚本。许多设计者发现使用这种方法是有益的，它可以解耦原来compile_hierarchy脚本的特征化和编译的步骤。这些脚本可以工作在设计体系的所有的层次，，去耦使得执行必要的特征化、编译的步骤很容易。
在应用说明的结尾增强的脚本似乎有价值，但它们不是实现CRWC最高效的方法。对于规模大的设计而言，特征化一个设计要求的时间限制了CRWC方法的优点。幸运的是，特征化单个设计的时间同特征化一系列设计所需的时间差的不多。
为改进CRWC方法的运行时间，重写characterize_active_design路线，以便特征化仅按每层去做而不是按每个设计去做。发展一种新的机理（如用户定义的属性），处理非特化的设计，或者在体系结构中发出uniquify的命令。用单个命令特征化整个设计体系如：
characterize –constraints filter(find(-hierarchy cell,“*”)，\\“is_hierarchical==true”）
减少特征化时间数并不是改进CRWC方法的性能的唯一的途径。原先charactrize/write_script/compile方法的用户将会记得，这个技术超过charactrize/compile的优势是在编译低层设计前具有移开高层设计的能力。
改进存储器的利用总是好的主意。由于当今的工作战中I/O操作明显慢于CPU，当设计进出存储器交换时，特征化和编译的时间显著增加。修剪设计，有几种方法解决这个问题。设计应该是否，何时，怎么样从存储器中移开/装载，这种决定由用在项目的设计管理程序引导。对于CRWC方法，从存储器中移开高层的设计是不必要的。这种提高对读者而言是一个练习。
如果你一这种方式选择增强脚本，记住当设计从存储单元移开时，设计从变量移开。用一个目标类型变量存储设计，对于未来的参量用字符串变量存储其名字。 6-5-8 结论
这个应用说明介绍了一些dc_shell命令，可以帮助Synopsys用户认识设计编译器的功能和灵活性。详细阐述了设计目标，变量，属性，别名，控制流命令。
在介绍了dc_shell的基本特性后，使用dc_shell脚本发展了一种体系编译的方法。这种characterize/revise_script/write_script/compile(CRWC)方法建立在由Mikael Hakansson和David Gregory介绍的思想之上。
CRWC脚本解决了体系编译的难题，对于宽广范围的设计，任意设计的体系都可客户化，可操作化。在CRWC脚本介绍后，几个可能的脚本的增强和扩展的方法强调简单的事实，即没有一个通用的编译脚本适合所有的应用。这就是为什么dc_shell脚本有如此强的能力。
脚本允许设计者自动进行他们自己指定的设计或者指定方法的dc_shell的程序。创造性，你可能发现更简单，不一般的更适合你自己的设计方法。
在这个应用说明中解释了几个常见的错误，没有适当地警告就排除掉是不负责任的。使用dc_shell脚本你可能陷入麻烦。无限的while循环是一个好的例子。在等待无限脚本的完成，设计者浪费了宝贵的时间。
这儿常见的陷阱不完全。还有许多其它的陷阱可以避免。当写脚本时，遵循着合理的软件设计实践。文件化你的编码。用list和echo表明你的改进。若你在特定的结构上遇到困难，再尝试一次。发现每个命令的细微的差别可能要花一段时间。