目录
1.hardMacro及仿真模型
2.后防该怎么做及遇到的问题
1.hardMacro及仿真模型
在芯片设计中在使用第三方IP时 会有vonder提供hard Macro IP的情况。什么是hard Macro呢？就是vonder最终提供的是GDS(设计版图)文件给后端。
GDS文件包含了芯片实现的所有信息，包括使用的元器件，布局，布线芯片结构、形状和层次结构等信息。
比如常见的各种第三方PHY，vonder都是以GDS交付的，所以后面就以PHY为例说明。除了GDS文件，为了仿真，vonder一般会提供：
- xxx_gtech.v
用于前防的verilog仿真模型，通常不是RTL的形式而是gtech网表的形式。【gtech是一种和工艺无关的通用网表】
这种网表没有延迟信息(即没有specify语句),也不可综合。
- xxx_gate_level.v + xxx.sdf
这两个文件用于验证后防。gate_level.v 是有specify的且和sdf匹配。但是这种门级的网表是不可综合的。
上面提到给仿真提供的文件，实际上给后端的除了GDS文件，还会给lib文件(lib可自行转db)。为什么要给lib文件呢？
是因为后端要用lib里的信息完成PHY与设计中外围的数字逻辑的布线和收timing。所以会看到在后端给的final netlist+sdf里 会有PHY的部分。sdf中PHY的部分仔细看就会发现只有PHY的pin与外部逻辑的延迟信息，常见的包含两部分：
DELAY：IOPATH的delay 这些都是phy pin input--->output的feedthrough path的延迟【feedthrough path是可以包含组合逻辑的】
TIMINGCHECK：input信号的WIDTH，input clk和对应寄存器之间的SETUPHOLD等信息。
2.后防该怎么做及遇到的问题
上面提到了多个仿真模型和多个sdf文件【后端吐出来的和vonder提供的】，那么后防究竟该用哪些文件呢？答案如下：
- phy的gate_level仿真模型
- vonder提供的和phy gate_level仿真模型匹配的sdf【这里的匹配说的是和仿真模型specify匹配】
- subsys的netlist+sdf【后端吐出来的sdf】
- 工艺相关的stdCell+mem的仿真模型【这些模型只有gate_level级verilog】
即使采用了正确的后防文件 在sdf反标的过程中还是会出现无法反标的情况，经过查看无法反标的都是PHY的IOPATH。说明后端根据PHY的lib吐出了这类IOPATH的delay，但是phy的gate_level仿真模型没有对应的specify语句。既然IOPATH的delay是实际存在的，后防无法反标是否有风险？
在IOPATH delay无法反标的情况下 仔细去看后端的sdf发现有些IOPATH delay全部为0，vonder给出的答案是这部分delay会用 path margin来cover。因为IOPTAH在PHY分析的时候是一条完整的path，但在subsys来看并不是完整的path，用了path margin就会在包含PHY IOPATH这一段的完整path上体现delay。
一般情况下 后端在做和PHY的接口时候 都会设置path margin。上面这种情况是vonder要求我们用path margin来cover，否则timing有可能过于乐观。
但还是会发现有IOPATH delay不为0的情况，【这种情况下无论后端加不加path margin 后端timing都是ok的，实现上是没有风险，IOPATH delay反标不上只会影响后防】这种情况下个人猜测仿真时候是vonder把这部分delay分散到PHY sdf的其他部分了【这个没有得到确认】。但基本情况下path margin是比vonder提供的IOPATH delay要大的，所以即使没有反标上，后防也没有问题。
