集成电路自诞生以来正如莫尔定律所预言的一样每隔18个月集成度就翻一番目前的集成电路设计已经由早期的几十μm减小到0.15μm进入到了深亚微米级

　　在器件的特征尺寸降到深亚微米级的同时器件的物理特性和电学特性也发生了很大的变化器件本身固有延迟大大减小而互连线所引起的延迟在整个单元延迟中所占的比例越来越大因而时序不收敛是深亚微米集成电路设计中最常见的问题在深亚微米集成电路设计中传统的分析方法使前端的逻辑设计与后端的物理设计很难保持一致在逻辑设计中仿真分析后功能和时序都正确的网表却由于布线设计后芯片空间和连线的限制造成互连引线延迟与逻辑设计中使用的模型不一致使得时序不再满足约束要求导致逻辑设计和物理设计循环不收敛从而使设计周期大大加长因此传统的分析方法在复杂的SOC设计面前显得无能为力而成为整个设计流程中的瓶颈

　　在这种情形下静态时序分析应运而生它不仅可以根据设计规范的要求对设计进行检查同时还能对设计本身做全面的分析静态时序分析是相对于动态时序分析而言的动态时序分析时不可能产生完备的测试向量覆盖门级网表中的每一条路径因此在动态时序分析中无法暴露一些路径上可能存在的时序问题;而静态时序分析可以方便地显示出全部路径的时序关系因此逐步成为集成电路设计签字认可的标准

　　本文以100M以太网卡芯片的设计为基础以静态时序分析工具PrimeTime为参考工具以Verilog语言为参考硬件描述语言，探讨100M以太网卡芯片设计中的静态时序分析流程及其时序问题

　　1 100M以太网卡的结构

　　100M以太网卡是一块高集成度的快速以太网控制器它支持IEEE802.3和802.3u协议及PCI v2.2总线接口协议还支持10M/100M自适应功能此芯片包括PCI接口模块、两个2KB的FIFO模块、发送DMA控制模块、接收DMA控制模块、IEEE 802.3协议规定的MAC模块和10/100M 集成物理层(PHY)模块此外还提供了EEPROM接口和扩展BootROM接口从整体来看它是包含数字电路和模拟电路的混合型集成电路芯片它采用的是0.25μm工艺四层金属层图1是该100M以太网卡的结构框架图

　      2 100M以太网卡设计的静态时序分析

　　100M以太网卡芯片的时钟关系如图2所示pmapmd是网卡芯片物理层的模拟电路部分digital是网卡芯片物理层的数字电路部分core则是指网卡芯片除物理层之外的部分纯模拟模块pmapmd通过晶振产生五个时钟:f125m、f20m、f50m、t100rxc、 t10rxc，提供给digital;digital提供PRXC、PTXC、clk_10Hz;clk_1kHz四个时钟给core模块 pci_clk是外部时钟通过PCIPAD提供给digital和core;同时pci_clk还通过一个PCIbuffer产生一个与 pci_clk相位不同但频率相同的时钟PADCLK提供给core

　　

　   由于该100M以太网卡芯片比较复杂同时还要满足一些特殊的功能需要所以在该网卡的设计过程中存在许多时序分析问题需要解决首先该网卡的大部分PAD都是双向的在有些模块中外部输入输出接口的时序限制是参照内部时钟进行限定的其次为了省电在该网卡内部设有许多选通时钟 (Gate Clock)和内部时钟多个时钟之间的信号连接会带来相应的麻烦

　　 图3是100M以太网卡静态时序分析流程图

　　

　　2.1 时钟的定义

　　在静态时序分析中时钟的定义是设定限制的最重要的一个步骤因为静态时序分析本来就是基于时序进行分析的而绝大多数的时序路径的计算又都是以时钟为基础的所谓时钟定义是指对于设计中所用到的时钟设定名称、周期、相位、占空比在Primetime中用如下命令来实现:

　　create_clock -name  [NAME] -period [P] -wave [rising_time falling_time] object_name

　　由于100M以太网卡芯片的门数较多时钟关系也比较复杂所以对不同关系的时钟定义方法也不一样图4给出三个不同关系的时钟

　　(1)CLK1和CLK2有两种关系:一种是CLK1和 CLK2来自网卡外部毫无联系的晶振其相位关系是不确定的根本无法通过Primetime正确地检查它们之间的时序关系但是可以正确地检查单独经过 CLK1或是CLK2的路径的时序另一种是CLK1和CLK2是频率不一致的时钟例如通过RxDMA控制写RxFIFO和读RxFIFO的时钟频率是不一样的MII通过R xDMA控制写RxFIFO的频率为25MHz，而PCI通过RxDMA控制读RxFIFO的频率是33MHz对于这样的异步设计一般不是通过Primetime的报告保证其时序关系而应该在写代码时就必须保证该部分的时序关系正确所以若碰到这种情况做静态时序分析时一般要进行如下处理;
　　set_false_path -setup-from CLK1 -to CLK2

　　(2)CLK3是由CLK1通过组合逻辑产生的其相移就是这些组合逻辑的延时经过第一遍综合之后该延时便可从时序报告中得出这样就可以根据此延时对这两个时钟的关系给出正确的设定在Primetime中，有以下两种方法可以设定:

　　一种方法是分别定义时钟CLK1和CLK3并将其rising_time、period和占空比设为相同然后再通过时钟延时的设定来区分两者的不同相位当然时钟延时的差值应该由所提之的组合逻辑延时决定

　　另一种方法是只定义时钟CLK1，再用如下命令定义CLK3：

　　create_generated_clock -name CLK3 -source  P1 -

　　divide_by 1  DFF3/ck

　　这样在布局布线之后做静态时序分析时CLK1被设为propagated_clock， Primetime就可以根据两时钟之间的延时关系来算出CLK3的特性(包括时钟延时、时钟抖动等)无需再另行推算而前一方法比较适用于布局布线之前的静态时序分析因为这时所有的时钟都被设为理想的其时钟延时、时钟抖动和时钟传输时间等都是根据实际情况来设定的只有当源时钟为 propagated_clock时Primetime才会自动推算CLK3的特性否则仍需要设置

　　2.2 边界时钟

　　由于100M以太网卡某些模块涉及到边界时钟所以必须考虑边界时钟引起的时钟延时问题所谓边界时钟是指某模块的输入输出和时序限制是以某个特定的时钟作基准的而该时钟是由外部时钟分频得到的

　　但在布局布线之后做静态时序分析时并不用费心去计算边界时钟引起的时钟时延而是把它交给Primetime完成正如前面所提到的当源时钟为propagated_clock时Primetime会自动计算所生成时钟的相关延时

　　2.3 输入输出延时的声明

　　做静态时序分析时，要根据端口时序图声明输入输出延时而不是根据内部延时确定端口时序下面给出延时声明和端口时序声明之间的简单计算公式假设时钟周期为T时钟从端口到寄存器的延时是Tx数据从端口到寄存器的延时是Ty工艺给定的setup_time是Tsetuphold_time是Thold端口时序声明给出的输入数据在时钟采样沿之前保持有效的最小时间是Tsu输入数据在采样时钟沿之后保持有效的时间是Tkeep端口时序声明给出采样时钟沿到输出数据有效的最长时间是Tdelay在做静态时序分析时应保证以下关系成立:

　　Tsu+Tx-Ty>Tsetup              (1)

　　Tkeep-Tx+Ty>Thold         (2)

　　根据输入延时和输出延时的定义和公式(1)和(2)可以得出最大输入延时是:

　　Tinput_delay=T-Tsu            (3)

　　最大输出延时是:

　　Toutput_delay=T-Tdelay         (4)

　　根据公式(3)以及图5的端口时序图可以定义图5的最大输入延时是:

　　Tinput_delay=Tclk-q + TM       (5)

　　根据公式(4)以及图5的端口时序图可以定义图5的最大的输出延时是:

　　Toutput_delay=TS+Tsetup        (6)

　　2.4 时序报告分析

　　静态时序分析是采用穷尽分析方法来提取出整个电路存在的所有时序路径计算信号在这些路径上的传播延时检查信号的建立和保持时间是否满足时序要求通过对最大路径延时和最小路径延时的分析找出违背时序约束的 错误因此分析静态时序分析的报告是非常必要的

下面是以100M以太网卡地址识别逻辑模块作静态时序分析时所产生的报告的一部分

　　*******************************************

　　Report ： timing

　　        -path full

　　        -delay max

　　        -max_paths 1

　　Design ： ARLcore

　　Version： 2000.05-1

　　Date   ： Fri Nov 21 15：38：25 2002

　　*******************************************

　　Startpoint： ARLdp/n_DAValidsN_reg

　　(falling edge-triggered flip-flop clocked by TXC)

　　Endpoint： ARLsm/Cstate_reg[3]

　　(rising edge-triggered flip-flop clocked by TXC)

　　  Path Group： TXC

　　  Path Type： min

　　       Point                       　Incr    　Path

　　   　——————————————————————————

　　clock TXC (fall edge)               5.00      15.00

　　clock network delay

　　(ideal)                           　1.00      16.00

　　ARLdp/n_DAValidsN_reg

　　/CPN (dfpfb1)                       0.00      16.00 f

　　ARLdp/n_DAValidsN_reg/Q

　　(dfpfb1)                            0.56      16.56 f

　　ARLdp/U394/Z (an02d1)               0.25      16.80 f

　　ARLdp/n_DAValids (ARLdp)         &nbs p;  0.00      16.80 f

ARLsm/n_DAValids (ARLsm)            0.00      16.80 f

　　ARLsm/U260/Z (an04d1)               0.27      17.08 f

　　ARLsm/U294/Z (aor21d1)              0.27      17.34 f

　　ARLsm/U291/Z (aor21d1)              0.30      17.64 f

　　ARLsm/Cstate_reg[3]/D

　　(dfcrq2)                            0.00      17.64f

　　data arrival time                             17.64

　　clock TXC (rise edge)               20.00     20.00

　　clock network delay

　　　 (ideal)                              1.00      21.00

　　ARLsm/Cstate_reg[3]/CP

　　　 (dfcrq2)                             0.00      21.00r

　　library hold time                   0.50      21.50

　　data required time               &n

bsp;            21.50

　　　........................................................

　　    ……

　　data required time                            21.50

　　data arrival time                             -17.64

　　   ————————————————————————————

　　slack (MET)                                   3.86

　　从报告中可以看出它非常详细地报告了从Startpoint：ARLdp/n_DAValidsN_reg到 Endpoint：ARLsm/Cstate_reg[3]这条路径的时序关系并且这条路径是满足保持时间的

　　静态时序分析在不同阶段的侧重点是不一样的在布局布线前往往更重视建立时间检查而忽视保持时间检查如果违背了建立时间就必须重新优化至于违背了保持时间可以通过在布局布线后手工加入一定的延时来解决在布局布线后应重点检查保持时间

　　在100M以太网卡芯片设计中通过做静态时序分析确认了其设计的可靠性为设计获得签字认可起到了保证性的作用

　　静态时序分析是分析、诊断和确认设计的时序特性的方法它不需要输入向量就能穷尽所有的路径且运行速度很快、占用内存较少不仅可以对芯片设计进行全面的时序功能检查而且还可利用时序分析的结果来优化设计因此静态时序分析已经越来越多地被用到数字集成电路设计的验证中

　　参考文献

　　1 Barual Tuck..Deep Submicron Changes the Face of Verification[J].Computer Design， 1995(10):20

　　2 Musgrave G etal. User Experience with High Level Formal  Verification. In：ACM Proceedings of the35th Design Automation Conference.San Francisco:ACM，1998:327