后端面试每日一题总结hazzm02.docx
《后端面试每日一题总结hazzm02.docx》由会员分享，可在线阅读，更多相关《后端面试每日一题总结hazzm02.docx（33页珍藏版）》请在冰点文库上搜索。
后端面试每日一题总结hazzm02
找工作准备
set_dont_touch_network可以穿过logic，可以用于clocks,pins,或ports。
当你对设计不十分熟悉时，这个属性可能会传到你不希望的地方去。
set_ideal_net=set_ideal_network-no_propagate
clk在创建的时候，会默认为idealnet的，但当clk接入到datapath的时候，D端就会考虑我clk上的负载，但并不会影响clk的idealnet的属性。
假如我的clk需要门电路做gating，gating后的时钟也有很大的扇出，那我为了忽略掉延迟，是不是需要在gating后重新给clk定义idealnet?
因为idealnet不能穿过逻辑。
如果你的CG集成好的标准单元，它会自动继承ideal的属性
上面这几句话中涉及到：
set_dont_touch_network和set_ideal_network，而实际上我们在综合时用的是set_dont_touch_network
虞希清是怎么讲的呢？
P60
虞希清书中给的时钟建模语句既不包含idealnetwork语句，也不包含donttouchnetwork语句
衍生时钟什么时候用？
应该是分频的时候用？
061的启示：
CTS之后时序变好还是变差
061的实验基于：
smic65工艺下的源和后处理。
使用icc，所在目录icc_MACRO
setup
CTS之后，in2reg的时序如何变换？
变好还是变差？
CTS后，inputport的captureclock由于时钟树的存在，会有延时；而inputport的launchclock仍然保持不变，故inputport的setup时序会变好。
左上图为Place后的时序报告，右上图的CTS后的时序报告。
虽然已经CTS过，但是其inputport到达时间中的clocknetworkdelay仍然是ideal，仍然为0.
inputport的到达时间中的clocknetworkdelay即使一直到PnR步骤完成，仍然是ideal的，即为0.这并不符合实际情况，因为inputport上的信号不可能比时钟提前到，该信号和时钟是同一时间到达的。
故后端面试每日一题061问了：
howtofixit
一种做法是对所有的inputdelay增加一个worstcaseinsertiondelay。
另一种做法是创建一个与系统时钟同频同相的虚时钟，然后使inputdelay相对于虚时钟。
可以看到cts之后，slack由1.4增加到1.77.
再来看reg2out的情况：
可以猜测，CTS之后，reg2out的setup变差。
因为到达时间中的clocknetworkdelay增加。
而要求时间中的clocknetworkdelay保持不变：
最后来看reg2reg的情况：
reg2reg的变化不大。
综上，CTS之后，INPUT的setup变好。
那OUTPUT的setup呢？
变差。
那INPUT的hold呢？
变差
那OUTPUT的hold呢？
变好
虚拟时钟
创建一个虚拟时钟以解决CTS后的IOdelay的问题。
这需要创建一个和实际时钟同频同相的时钟。
怎么创建一个同频同相的时钟呢？
不仅需要知道周期，还需要知道insertiondelay.
接着把inputdelay和outputdelay的参考时钟都切换到新创建的虚拟时钟上：
此时再执行report_timing，时序报告如下：
062的启示:
根据时序报告分析问题
062PT的时序报告不大看得懂。
尤其是一个标准单元在时序报告中占了两行难以理解。
为此，我们找一个简单的时序报告看看。
基于tutpt/ocv_post_cppr
正常的时序报告
可以看到：
所有输入脚上的延时增加值都为0。
上一级的输出transition等于下一级的输入transition
net没有transition和延时值
前两个特点其实是等价的。
由于我们见到的时序报告都是满足要求的时序报告，故见到明显不符合要求的时序报告反而不知如何分析。
如何分析未达标的时序报告
从这题得到的启示是，必须把fanout、capacitance、inputpins都列出来才利于进行时序分析。
分析的思路如下：
1.看incr一列，0和非0间隔出现才正常。
出现连续非0的行肯定存在问题。
从这里可以看到有两个地方存在问题。
找到问题后，再来分析原因：
第一处：
原因在于fanout太大。
fanout为50，导致上一级的outputtransition比较大（1.32），最严重的是，导致下一级的inputtransition很大（3.02）
第二处：
fanout只有一个。
但是Cap很大。
上一级的outputtransition为0.88，而下一级的inputtransition却为3.88.由此可知，其原因在于导线太长。
2.查看clockskew。
clockskew应该为10ps级别。
这里的周期为10ns，而skew=1ns，算是比较大的了。
这也是一个原因。
059的启示：
slew的传播模式
059虽然猜对了答案，但一开始并没有真正理解。
好在陈涛给了一句话：
PrimeTime里面把这个叫做PathBaseAnalysis.而我在《PrimeTimeAdvancedTimingAnalysisUserGuide.pdf》中查找AdvanceOCV时刚好看到这几个字。
碰巧把这道题弄懂了。
slew传播模式
首先问这么一个问题：
我们都知道一个门的delay取决于inputtransition和outputload。
我们以一个AND门为例，pinA的inputtransition和pinB的inputtransition很可能是不同的。
此时如何计算其delay呢？
可能有人会说，使用最差的transition——这种情况称之为worstslew；
也可能有人会说，哪个信号最晚到，就用该信号的transition——这种情况称之为worstarrival。
从实际情况来说，worstarrival更符合实际情况。
PrimeTime默认是使用worstslew模式。
因为作为一个signoff的STA工具，必须得有点悲观才行。
虽然worstarrival更符合实际情况，但是可能会偏向乐观。
Primetime中相关的设置变量为timing_slew_propagation_mode，可选值为worst_slew和worst_arrival.
更为折衷的方法
worst_slew偏向悲观，worst_arrival过于乐观。
于是PT提供了一种折衷的方法，称之为Path-BasedTimingAnalysis（要注意的是，这里Path-Based与通常所说的Path-Based并不相同，通常我们把静态时序的分析方式称为Path-Based，即基于时序路径的分析方式，与Block-Based相对）。
该方法在分析某一条路径时，slew只考虑该条路径实际经过的slew。
以下图为例：
我们要分析的路径通过了S2，则S2之后的timingarc的延时只取决于S2，与S1、S3无关。
回到原题目
两个与门，单单看CLK端的inputtransition和outputload都相同。
从PT静态时序分析的角度来看：
只有在PBA模式下，CLKàLOADA的延时和CLKàLOADB的延时才相等。
更可能的情况是不会相等。
时序约束训练
训练的题目从虞希清书中的例子选取。
1.inputdelay设置：
2.outputdelay设置：
3.异步时钟约束
4.datapath上的多周期时钟约束：
5.clockdomain上的多周期时钟约束，虞希清的书上没有，先略过
6.二选一时钟
7.分频时钟
原生时钟的1.5latency和衍生时钟的0.5latency如何设置呢？
8.快时钟到慢时钟的时钟约束
图中从DES_B到DES_A如何约束？
书中给的约束如下：
但是我觉得不对。
因为这涉及到多时钟周期的问题。
091：
什么是MultisourceCTS
什么是MultisourceCTS？
陈涛给的图似乎想表达MultiClockonthesamesource，即同一个引脚上添加了多个时钟。
陈涛后端的面试题，有的地方该题是有答案的，但只有一句话：
结合clockmesh做的cts，乍看一下难以明白。
但实际一查，发现MultisourceCTS是个全新的概念。
文章《IntroductiontoMultisourceClockTreeSystems》是2012.02.10出来的。
ICC2010估计还不支持该功能，故在其userguide中无法搜索到。
ICC2012.06开始，才支持MultisourceCTS.
其好处是结合了clockmesh和clocktree的优点。
clocktree的优点：
功耗低，流程简单。
clockmesh的优点：
skew小，抗OCV
multisourcects是clocktree和clockmesh的一个折衷。
其特点如下：
skew比传统的CTS小
抗OCV能力比传统的CTS大
功耗比纯粹的clockmesh小
流程比clockmesh简单
参考文章：
《IntroductiontoMultisourceClockTreeSystems》
《What’sTheDifferenceBetweenCTS,MultisourceCTS,AndClockMesh?
》
008的启示：
衍生时钟latency
本题
陈涛后端面试每日一题的第008题问到了衍生时钟与主时钟的latency关系。
说：
假设有两个时钟，原始为clka，生成的时钟为clkb，
在没有时钟树的网表中，clka的networklatency会自动传递到clkb上吗？
clkb的latency如何描述？
在生成时钟树的网表中，如何处理networklatency?
clkb的latency又如何描述？
第二个问题很好回答，生成时钟树之后，时钟的networklatency可以直接从时钟网络所经过的路径计算出来。
只要：
把networklatency去掉，并set_propagted_clock即可。
工具会自动计算主时钟和衍生时钟的latency.
第一个问题陈涛给的答案是：
在pre-CTS时，clka的networklatency会自动传到clkb上。
但在PT中实测，衍生时钟有自己的clocksourcelatency和clocknetworklatency。
这些latency值与主时钟无关。
不会自动传播。
虞希清书中
在虞书中：
原生时钟的1.5latency和衍生时钟的0.5latency如何设置呢？
虽然这些命令能把IntClk前面的延时情况表达对，但是无法把ExtClk的情况描述清楚。
因为在版图前STA时，衍生时钟和主时钟的clocklatency没有任何关系。
参考文献
在EETOP上找到如下文章，该文章来自Synopsyssolvnet。
故还是有很强的官房性质的。
从该文章中我们可以看到，在pre-CTS时，衍生时钟确实不会继承主时钟的延迟。
分享一篇Synopsyssolvnet上面的文章
Question:
Howisthetotalclocklatencycalculatedunderdifferentconditionsofgeneratedclockandthemaster/sourceclock?
Hereistheclockcircuitinquestion,whichhasaclockdividerflip-flop（U1）thatdrivesanotherflip-flopU2.Themasterclockisnamed'MCLK'andthegeneratedclockisnamed'GCLK'.
Answer:
ThetotalclocknetworklatencycalculatedbyPrimeTimedependsuponthenatureofthemasterandgeneratedclock--whetheridealorpropagated,thenetworklatencies,andwhetherthereisauser-specifiedsourcelatencyforthegeneratedclock.Thefollowingtablesummarizeshowthelatenciesofthemasterclockandthegeneratedclocksareusedindifferentnetworkconditionstocalculatethetotalclocknetworklatency.
MasterClock
SourceClock
GeneratedClockSourceLatency（GCSL）
Totalclocknetworklatency（TNL）
Propagated
Propagated
NotSpecified
MCSL+MCNL+GCNL
Propagated
Propagated
UserSpecified
GCSL+GCNL
（MCSLandMCNLareignored）
Propagated
Ideal
NotSpecified
MCSL+MCNL+GCNL
Propagated
Ideal
UserSpecified
GCSL+GCNL
（MCSLandMCNLareignored）
Ideal
Propagated
NotSpecified
GCNL
（MCSLandMCNLareignored）
Ideal
Propagated
UserSpecified
GCSL+GCNL
（MCSLandMCNLareignored）
Ideal
Ideal
NotSpecified
GCNL
（MCSLandMCNLareignored）
Ideal
Ideal
UserSpecified
GCSL+GCNL
（MCSLandMCNLareignored）
Legend:
MCSL:
MasterClockSourceLatency
MCNL:
MasterClockNetworkLatency
GCSL:
GeneratedClockSourceLatency
GCNL:
GeneratedClockNetworkLatency
Highlightsofthesummary:
1.User-specifiedGeneratedClockLatencycontrolswhetherornotthemaster clocklatencywillbeusedforcalculationoftotalclocknetworklatency. User-specifiedSourceLatencyongeneratedclockisloatesthegenerated clocknetworkfromthelatenciesofthemasterclocknetwork.
2.Ifmasterclockisdeclaredideal,thelatenciesinthemasterclock netowrkwillnotcomeintocalculationoftotalnetworklatency.For example,ifyoudeclaremasterclockideal,andannotateadelayonthe masterclocknetwork,theannotateddelaywillnotbeusedincalculation oftotalnetowrklatency.
3.Settinglatencyonapropagatedclockmakesitanidealclock.Removingthe latencydoesnotautomaticallymakeapropagatedclockanidealclock.
4.Ifbothmasterclockandgeneratedclockaredeclaredpropagated,thetotal networklatencywillbesumoflatenciesinthemasterclocknetworkand latenciesinthegeneratedclocknetwork,aslongasthereisnouser- specifiedsourcelatencyonthegeneratedclocknetwork.Incasetheuser hasspecifiedasourceclocklatencyonthegeneratedclock,thelatencies inthemasterclocknetworkwillbeingnoredandonlylatenciesinthe generatedclockwillbeusedfortotalnetworklatencycalculation.
5.Userscanspecifysourcelatencybythecommandset_clock_latency-source.
6.Usefulcommandsforanalyzingclocknetworkandlatenciesare:
（a）report_clock-attributes-skew
（b）report_clock_timing-typelatency-verbose
7.Specifiyingsourcelatencysetsthestartpointfordelaycalculationin thenetwork.
060的启示:
对PLL建模
题目如下：
有一个PLL的时钟，jitter是50ps，dutycycle有5ps的漂移。
设计中需要同时用到时钟的上升沿和下降沿，如何把那个50ps和5ps写到约束文件里？
陈涛给了两种答案：
但实际上这两个答案是不匹配的。
稍微有点区别。
其区别就在于jitter的理解上。
jitter=50ps指的是什么含义？
如果指的是时钟周期的变化范围为50ps（即正负25ps），则第二个答案是对的；如果指的是时钟周期的变化范围为100ps（正负50ps），则两个答案都是错的。
下面先分析uncertainty与skew,jitter的关系。
uncertainty与skew,jitter的关系
有一个基本的常识，就是skew和jitter在preCTS时都使用uncertainty进行估计。
很少有人细问：
skew=50ps时，uncertainty应该设置为多少？
答案是50ps
jitter=50ps时，uncertainty应该设置为多少？
答案是100ps
这里采用的约定是：
jitter=50ps，表示的是周期的变化范围为2*jitter，即正负50ps。
为了验证这一结论，我们考虑一条路径，在未设置uncertainty时，该路径的时序报告如下：
setup
hold
当skew=50ps时，我们设定uncertainty为0.05
setup应该恶化0.05，因为launchclock固定不变，而captureclock向前有个50ps的skew.
hold应该恶化0.05，因为launchclock固定不变，而captureclock向后有个50ps的skew
setup
hold
当jitter=50ps时，
setup应该恶化0.10，因为最坏的情况是：
launchclock滞后50ps到，而captureclock提前50ps到。
但由于时序报告中都是默认launchclock保持不变，captureclock变化uncertainty的值。
故我们设定uncertainty为100ps，即captureclock提前100ps到。
hold应该恶化0.10，因为最坏的情况是：
launchclock提前50ps到，而captureclock滞后50ps到。
但由于时序报告中都是默认launchclock保持不变，captureclock变化uncertainty的值。
故我们设定uncertainty为100ps，即captureclock滞后100ps到。
setup
hold
如何转换成uncertainty
回到题目本身，首先需要把jitter和dutycyclevariation转化为uncertainty。
jitter转化为uncertainty上文已经说明过。
如果频率变化范围为正负50ps，那么jitter=50ps,clockuncertainty为100ps.
占空比的变化对clockuncertainty有影响吗？
我们以一个实例进行说明：
例：
假设时钟周期为1000ps,jitter为50ps，则时钟周期的范围为（950ps,1050ps）。
我们以T=950ps为例，其高电平时间为475ps.dutycyclevariation为5ps时，则高电平时间最短为470ps，最长为480ps。
表现在波形中，如下图所示：
可以看到，占空比的变化并不影响上升沿。
当高电平时间为470ps时，下降沿为左红线；当高电平时间为480ps时，下降沿为右红线。
通常而言，我们只用到正边沿DFF，这种情况下，高电平时间是470ps，还是480ps并没有影响，只要高电平时间超过最小脉宽即可。
但是如果使用了负边沿DFF，下降沿可能提前5ps到，也可能滞后5ps到。
这个数值如何反映在uncertainty中呢？
这一数值相当于在jitter上叠
升级会员 