高手进来：关于余量slack的一点思考

各位前辈，近日在思索关于建立/保持时间余量(也就是slack)的一点问题。书上或者官方文档都说，时序分析器会依据自身模型计算reg-reg路径的建立和保持时间余量，如果两者任中之一为负，则表示存在时序违规，将给应用带来潜藏的危机。那么是否意味着只要slack为正，就万事大吉?
      在一些项目中，我有时限于时间压力，直接使用优化将少量负的slack勉强调节到正数，但绝对值很小。虽然实验中并没有发生错误，但心里仍不踏实，担心这么小的余量会被外界环境的波动所抵消。想请教各位前辈，老鸟们，你们认为我的担心是多余的吗?或者说只要综合后的时序报告里slack全为正就够了?如果不是这样，那么slack至少应达到一个什么水平才可以认为保险呢?

关注中，也遇到同样的问题！

如果你把所要的时钟约束都加上了且正确，应该不会有什么问题。例如利用set_input_delay和set_output_delay分析IO时序，利用set_clock_uncertainty模拟时钟抖动等
如果设置的时钟频率比实际的高那么5%~10%，那么应该什么问题都没有了。
PS：我也不是什么高手

谢谢cuichenhust 的回复。
但有一点想请教，你这么说的依据是出自于FPGA厂商吗?或者是实际应用的经验?
假设某个slack本身就很小，在遇到温度变化或者各种信号抖动（包括时钟、数据抖动）情形下都是如此吗?

用maxtype跑一下sdc文件试试

谢谢你的回复！
你说的“maxtype”是指用时序分析得出的fmax去测试代码?
原slack本身是在实际的f下得出的，尚且很微小；如果用fmax去测试，所得的setup/hold报告中slack应该更小吧，甚至为负吧

求“铁”案！

great

软件只能模拟真实情况，不同的工作环境，不同的规模，很多综合参数都会不大一样。这个应该是从经验来。
在综合阶段clock tree,连线模型都只能粗略的计算。相对来讲layout的时候更接近真实一些。
所以要是critical path的延时正好卡在你们的设计要求上，是比较危险的。
一般都要有余量，比如你富裕个10%，一般可以把那些不确定性覆盖掉。
保险的话，最好还是认真处理一下。

FPGA流程不清楚。
如果是ASIC，在综合阶段，除非你的时钟频率有足够的冗余（至少10%），否则p&r之后时许肯定达不到要求。真正的时许情况需要在p&r之后才能得到。
至于slack为正，是否在实际应用中还会出现timming问题，答案是一定的。所以一般时许分析时候的条件要比实际工作条件苛刻。
话说回来，系统设计的时候都会把工作频率往上估计，即便最后产品达不到期望的频率也可能满足设计要求，实在不行还可以加电压甚至可以选出能工作到指定频率的芯片。

    谢谢你的回复！
    我对ASIC的流程不很清楚，只用过FPGA。在FPGA中只有P&R后才能得到包含slack的时序报告。如果只进行综合，只会得出资源消耗的情况。想请教下难道ASIC在综合阶段就可以得出时钟的最高运行频率和关于slack的一个预先估计?
    另外一点，你在回复中说“至于slack为正，是否在实际应用中还会出现timming问题，答案是一定的。所以一般时许分析时候的条件要比实际工作条件苛刻。”你说的条件苛刻是指在一般时序分析时，会考虑进去信号或时钟的抖动（uncertainty）等严苛条件吗?而且你说即使具有10%的fmax余量的设计，对其中存在slack为正（微小的正?）的路径，芯片工作时仍有可能出错，那岂不意味着用户永远不能信任手中的产品?

综合之后可以得到没有连线延迟的时序信息，通过这个可以对工作频率有个大致的估计。
最终的芯片大约会有10%的废品，更何况那些达不到工作频率的芯片。不过这些都会在ATPG上挑出来。不良芯片一旦流入到客户手中损失就比较大了。

我是自己的经验和思考！STA工具缺省情况下就是用的worst-case模型进行分析的，也就是最低电压，最高温度，最慢的工艺。至于时钟的抖动什么的，我不知道，应该要自己设置，因为STA工具不可能知道外部时钟质量咋样，对吧?！
另外，我一般都会给时钟加余量，比如122.88MHz我就用130MHz分析，时钟再抖应该也不怕了。
你可以自己在timequest（quartusII）里边看看，某一条路径的时序分析，里边waveform什么的都有，看多了，你就知道工具到底分析了什么

    十分谢谢你的回复。
    关键是timequest分析出的微弱正余量与代码正常工作存在多大的必然性，是否意味着即使某路径存在微弱的正slack，但整体性能只要具有10%的fmax余量就可以高枕无忧?如果不是，那么面对存在微小正slack的路径该怎么办（假设fmax具有10%的余量），担心，恐惧，还是修改代码结构，直到slack也具有10ns左右才放心?

关注中，也遇到同样的问题

Quartus II的timequest中已经有0C和85C最慢的分析结果，如果在指定的频率下，slack为正，应该没有问题。当然个别器件出问题，那是器件的问题，如果器件有问题，频率放10%也未必能用。

    谢谢你的回复！
    你的意思是用85℃的模型，在指定频率下，只要slack为正，哪怕绝对值很小，都没有问题?

    应该没有问题。

就使用的感受而言，即使WC(worst case)下报violation，实际使用上问题也不大，我说的是实际项目上的经历。s4 820 -4 87%资源占用，wc 85下面timing report报的是93Mhz，实际使用100Mhz~110Mhz没有问题。毕竟wc分析的是极端情况，实际使用过程中很少达到。

开启fast/slow布线模式，只要两种模式下布线结果都ok就没啥好担心的

    谢谢你的回复！
     你说的“开启fast/slow布线模式，只要两种模式下布线结果都ok就没啥好担心的"中的“布线结果OK”指什么?是指各路径的slack都为正?还是fmax保有10%的余量的同时各slack均为正?

    谢谢你的回复！
    虽然实际中我也有类似的经历，但毕竟不能让设计者放心。尤其是保持时间违规时最让人头疼。

说下个人看法，对于slack为正，是否一定就能够适用任何场合，答案是很难确定的，与其想如何做一套代码，一套约束，就能应用于所有场合，不如关注与产品的使用地域条件如何，如何在选片，系统规划设计，到后面代码等等方面去下些功夫，毕竟，满足使用需求的前提下，成本最低性能最高才是我们追求的

谢谢回复，很赞同你的意见。
       不过你说的“如何在选片，系统规划设计，到后面代码等等方面去下些功夫，毕竟，满足使用需求的前提下，成本最低性能最高才是我们追求”的最终检验标准还是要看运行速率，资源消耗符合预定目标的前提下的slack余量。换句话说，所关注问题的焦点是在你“下足功夫”后，例如选择了合适的芯片，采用了良好的编码风格，构建了合理的使用环境后，slack余量要多大才恰当，才让人没有后顾之忧?关于这方面的理论或者是经验值一直困扰着我，很不爽，不知有合适的书籍吗?

综合和APR时钟频率比实际工作频率高，对应时序约束紧，Slack绝对值一般不会很大。
但如果频率比实际高出很多的话，应该可以保证时序是收敛的。

我们在设计时， 都是根据besecase worsecase下综合的， 只要你保证 besecase下的 holding ，worse case下的setup， 此时只要外面PV 条件在fdy提供的lib范围之类， 都是安全的。
不知道你明白与否

    谢谢你的回复。
    不是很明白“ 只要你保证 besecase下的 holding”这句的意思。
为什么不是worst case下的holding时间?难道最坏的holding值只能在best case情形下获得?抑或是最坏的setup值只能在worst case情形下获得?
    你想表达的就是只要达到fmax频率（最好有10%余量），且芯片工作环境满足库元件的正常工作温度范围，经best case和worst case条件分析得出的hold和setup的slack为正，哪怕绝对值很小，代工厂都会给你生产出符合设计性能的产品。不知这样看符合你的想法没有。

哥们， 你好好研究foundry的 lib， 看看 在各个case情况下， setup holding需要的条件， 然后就会知道了

    谢谢你的回复和建议！
    人生何其短，术业有专攻。我的兴趣在基于DSP和FPGA的算法分解、实现和系统设计，对于ASIC只有很笼统的看法（不涉及门级底层的东西），有时间我会去看看ASIC中不同case下，lib和setup、hold的关系。

设计时本来就必须考虑芯片的极限工作条件，比如：最高温度85°、最低电压2.5V为最差工作条件，该条件会影响芯片的建立时间；最低温度-40°，最高电压5.5v为最好工作条件，该条件会影响芯片的保持时间。其次还要有时钟误差也会影响建立时间。
设计时只要严格按照芯片的极限工作条件约束，布局/布线后时序报告的slack大于0。就表示芯片在这些极限条件以内肯定工作正常。如果有问题那就是你的约束没有加对。当然也有可能超过这些极限条件芯片仍然能工作正常的可能，那是因为软件模拟的极限条件本身有一定的余量，或者你加的约束比实际需要的还严格。