使用invs对数据库进行routing的时候（routeDesign），在某些情况下会出现全局分布式的大量short，此时用户可能需要进一步的分析，而非数据库、routing resource或layer scheme的问题，这里用一个典型案例对此进行说明，闲言少叙，ICer let's GO！
第一次绕线：CTS routing
invs的APR flow里边，工具第一次auto routing介入的点是在CTS阶段，ccopt_design 唤起NanoRoute ，完成所有的top/trunk/leaf的绕线，并视情况，完成所有或部分ck pin的routing。 譬如下图的Std-cell 的pin access的routing完成：
连接关系：M1 -> M2 -> M3
在CTS完成后，这个绕线没有任何疑问，DRC的检查也是和合理的。
Note：这是一个标准的借用了double via（defualt NanoRoute setting）连接方式：尽量使用更多的double via完成绕线
但是这里的double VIA2 的面积非常大，会把左边的D pin 的一部分位置占用，这给后期的处理埋下了一些隐患：
最终绕线
在route阶段，使用routeDesing命令，完成所有的时钟（优先级更高）和信号的绕线。这个时候，针对上述的情况，invs尝试给D pin 做绕线，就会形成下列的问题：
D pin 绕线：
绕线分解 per-layer： M1 -> M2 -> M3
工具在D pin access的时候，由于之前CTS的绕线的存在，已经不能完全保证M1 pin上的access VIA1 完全被pin shape 包裹了（enclosed）。但是这里的VIA1，因为有M2的 via-hang，所以必然会和CTS的routing 产生两类short，
- VIA2 short
- M2 short VIA hang上的M2 形成的M2 metal
由于这个普遍的std-cell的pin access问题，导致整个数据库，在route结束后，会产生非常多的short（5K+），如下：
解决之道
针对这类pin access的问题，invs通过配置给出了一些解决方案，通常不是绕线资源的问题，因为可以观察到仅仅是pin access的点位背普遍影响到，invs在尝试使用double via的时候，会对周边的pin access形成影响，这个时候用户需要使用一些NanoRoute的配置尝试解决，反而，增加绕线资源，降低std-cell 利用率等常规方法是没法产生收益的。
在setNanoRouteMode里边有两个选项可以配置工具的std-cell pin access行为：
为了解决std-cell pin access区域的short问题，这里可以将上述两个选项都设定为true：
setNanoRouteMode -routeWithViaOnlyForStandardCellPin true -routeWithViaInPin true
这样NanoRoute会仅仅使用被pin shape完全包裹的via access方式访问std-cell pin。
经过修改，可以看到，CP和D pin的访问完全独立了，并且没有产生任何short了
NanrRoute 严格使用了via access （via1) 这两个pin，并且via1也完全放置在了pin shape内部，这种被pin shape 完全包裹的VIA1，并不会对周边的std-cell pin access产生影响。
通常的std-cell 构建的时候，MOS pin的访问：diffusion -> AA_via ->poly -> CO_via -> M1，pin一般都会放在M1。如果一个std-cell 有很多pin， M1会被大量的占用，如下图：std-cell M1
这里想通过M1 routing shape 直接访问pin D和CP，基本是不可能的，进行必要的限制，反而可以指导NanoRoute使用合适的访问方式进行std-cell pin access，譬如这里的via access方式
【敲黑板划重点】
从理论上来讲，越是先进的工艺M1/M0的可用的绕线资源就越少，使用via access的方式访问std-cell pin是一个比较合理的做法，通过这样的限制，工具在pin access的选择变少了，反而质量提高了，通过VIA可以非常高效的在M1/M0密布的std-cell区域，将pin access就地解决，从而进入到更高层的实际绕线阶段。
参考资料
Cadence Innovus Text Command Reference