quartus使用timequest時序分析TimeQuest需要讀入布局布線后網(wǎng)表才能進行

Nets：同一個Cell中，從輸入Pin到輸出Pin經(jīng)過的邏輯。特別注意：網(wǎng)表中雖然連接兩個相鄰Cell的連線不被看作Net，但是這個連線還是有其物理意義的，等價于 Clockpaths：ClockPortclockPinCellPin。PinCellPin。LaunchEdge：LatchEdge：后級寄存器捕獲數(shù)據(jù)對應的時鐘沿，使時序分析的終點。有了上述的諸多概念，我們就可以得到時序分析的基本項了DataArrivalTime：LaunchEdgeClockpathCellPinPinNet（uTco）DatapathDataRequiredTime：LatchEdge+Clockpath（uTh）或（-uTsuClockArrivalTime：LatchEdge+后級寄存器ClockpathClockysis部分。DataRequiredTime（Slack）。當時序余量為負值時，就發(fā)生了時序（TimingViolation）（SetupTime）Launchedge的數(shù)據(jù)輸入Pin的速度不能太慢，時間不能太長，否則會后級寄存器數(shù)據(jù)輸入Pin相對LatchedgeDataRequirededge）。顯然，在建立時間檢查中，DataArrivalTimeDataRequiredTime，否則就會造成建立時間。也就是說，DataRequiredTime是DataArrivalTime的最ClockSetupSlack=DataRequiredTime–DataArrivalDataArrivalTime=LaunchEdge+ClockNetworkDelaySourceRegister+Register-to-RegisterDataRequiredTime=ClockArrivalTime–μtsu–SetupClockArrivalTimeLatchEdgeClockNetworkDelaytoDestinationRegisterClockSetupSlackTime=DataRequiredTime–DataArrivalumDelayofPin+Pin-to-RegisterDelayDataRequiredTime=ClockArrivalTime–ClockArrivalTime=LatchEdge+ClockNetworkDelaytoDestination3)（Register-to-Pin）ClockSetupSlackTime=DataRequiredTime–DataArrival+Register-to-PinDataRequiredTime=ClockArrivalTime–OutputumDelayofPinClockArrivalTime=LatchEdge+ClockNetworkDelaytoDestinationRegister的第一項是相同的；ClockArrivalTime的是相同的。所以，第一組可以歸納如下：ClockSetupSlackTime=DataRequiredTime–DataArrivalDataArrivalTimeDataRequiredTime其中，后兩個的第二項在其他情況下適當修改即可。這就和一些書中講到時序分析時采用的一致了report_timing-from[get_registersreg1]-to[get_registersreg2]--npaths1-panel_name"Report（HoldTime）LatchedgeDataDataTime，否則就會造成保持時間。也就是說，DataRequiredTime是DataArrivalTime晚了，會造成下一個時鐘沿的建立時間，當前時鐘沿發(fā)送的數(shù)據(jù)不能被下一個時鐘沿捕獲；早了，會造成上一個時鐘沿發(fā)送的數(shù)據(jù)保持時間，上一個時鐘沿發(fā)送的數(shù)據(jù)不能被二者在計算上的區(qū)別在于Slack計算中減數(shù)與被減數(shù)關系ClockHoldSlack=DataArrivalTime–DataRequired+RegistertoRegisterDataRequiredTime=ClockArrivalTime+μtH+HoldClockArrivalTimeLatchEdgeClockNetworkDelaytoDestinationRegisterClockSetupSlackTime=DataArrivalTime–DataRequiredMinimumDelayofPin+PintoRegisterDelayDataRequiredTime=ClockArrivalTime+ClockArrivalTime=LatchEdge+ClockNetworkDelaytoDestination3)（Register-to-Pin）ClockSetupSlackTime=DataArrivalTime–DataRequired+RegistertoPinDataRequiredTime=ClockArrivalTime–OutputMinimumDelayofPinClockArrivalTimeLatchEdgeClockNetworkDelaytoDestinationRegister需要注意的是，上面中的LatchEdge實際對應的是上一個LaunchEdge。所以，當LaunchClock和LatchClock是同一個時鐘時，上述中的LatchEdge等于0；當前LatchEdge1-panel_name"ReportTiming"（RecoveryTime）Latchedge和相應的建立時間之間，否則會導致寄存器的建立時間，數(shù)據(jù)輸出進入亞穩(wěn)態(tài)。即從前級寄存器的Launchedge開始計時，經(jīng)過一系列的時序路徑，前級寄存器數(shù)據(jù)輸出到達后級寄存器異步從上述定義，可以得到和建立時間檢查類似的RecoverySlackTime=DataRequiredTime–DataArrival+RegistertoRegisterDataRequiredTime=ClockArrivalTime–ClockArrivalTimeLatchEdgeClockNetworkDelaytoDestinationRegisterRecoverySlackTime=DataRequiredTime–DataArrivalDataArrivalTime=LaunchEdge+umInputDelay+PorttoRegisterDelayDataRequiredTime=ClockArrivalTime–μtSUClockArrivalTime=LatchEdge+ClockNetworkDelaytoDestinationreport_timing-from[get_portsasync_rst]-to[get_registersreg2]--npaths1-panel_name"Report（RemovalTime）Latchedge和相應的保持時間之間，否則會導致寄存器的保持時間，數(shù)據(jù)輸出進入亞穩(wěn)態(tài)。即從前級寄存器的Launchedge開始計時，經(jīng)過一系列的時序路徑，前級寄存器數(shù)據(jù)輸出到達后級寄存器異步從上述定義，可以得到和保持時間檢查類似的RemovalSlackTime=DataArrivalTime–DataRequiredofSourceRegister+RegistertoRegisterDataRequiredTime=ClockArrivalTime+ClockArrivalTime=LatchEdge+ClockNetworkDelaytoDestinationRemovalSlackTime=DataArrivalTime–DataRequiredDataArrivalTime=LaunchEdge+InputMinimumDelayofPin+MinimumPintoRegisterDelayDataRequiredTime=ClockArrivalTime+ClockArrivalTime=LatchEdge+ClockNetworkDelaytoDestinationreport_timing-from[get_portsasync_rst]-to[get_registersreg2]--npaths1-panel_name"Report五、多周期路徑（MulticyclePaths）獲；LaunchedgeLatchedgeLauchedgeLatchedge。這一設計意圖不照單周期路徑檢查的方式執(zhí)行，往往會誤報出時序。不設置多周期路徑約束的有兩種一是按照單周期路徑檢查的結果虛報時序；本應該多個周期完成的操作，造成過約束（Over-Constrain）。過約束會本應該讓位于其他邏輯的布局布線資源，有可能造成其他關鍵路徑的時序或時序余量變小。在多周期路徑的建立時間（SetupTime）檢查中，TimeQuestDataRequiredTime，放松對相應數(shù)據(jù)路徑的時序約束，從而得到正確的時序余量計算結果；在保持時間（HoldTime）檢查中，TimeQuestDataRequiredTime，仍時間對應的多周期個數(shù)。TimeQuest計算HoldTime的缺省不同于PrimeTime。在有些并多會造成保持時間檢查，需要用戶指定保持時間檢查對應的時鐘沿為Launchedge最近的時鐘沿。（西電《數(shù)字IC系統(tǒng)設計》p189）隨文附上一 ，可以采用上面令執(zhí)行并觀察結果。該實例改編 multicycle_exception。TechnologyMapViewer面的一篇文章中，給出了建立時間檢查的基本ClockSetupSlack=DataRequiredTime–DataArrivalDataArrivalTime=LaunchEdge+ClockNetworkDelaySourceRegister+μtcoRegister-to-RegisterDataRequiredTime=ClockArrivalTime–μtsu–SetupClockArrivalTimeLatchEdgeClockNetworkDelaytoDestinationRegisterClockSetupSlackTime=DataRequiredTime–DataArrivalDataArrivalTime=LaunchEdge+ClockNetworkDelaytoSourceRegister+InputumDelayofPin+Pin-to-RegisterDelayDataRequiredTime=ClockArrivalTime–ClockArrivalTime=LatchEdge+ClockNetworkDelaytoDestination3)（Register-to-Pin）ClockSetupSlackTime=DataRequiredTime–DataArrivalDataArrivalTime=LaunchEdge+ClockNetworkDelaytoSourceRegister++Register-to-PinDataRequiredTime=ClockArrivalTime–OutputumDelayofClockArrivalTime=LatchEdge+ClockNetworkDelaytoDestination兩組中，DataRequiredTime計算的第二項都是-uTsuTimeQuestreport_timing-from[get_portsdata_in]to[get_registersreg1]setupnpaths1panel_name"ReportTiming"DataRequiredTimereg1uTsu在Incr一列中，reg1的uTsu取值為0.036ns，在計算中作為正數(shù)值計入了DataRequiredTime計算正確，但是TimeQuest計算錯誤我一直傾向于后一種可能，畢竟TimeQuest是Al 后一種可能雖然更合理，但是又沒有充足的證明這一點，這一數(shù)據(jù)是Al TimeQuest下面，讓我們通過輸出引腳的建立時間檢查（3）來證明一下：仍然以兩級級聯(lián)寄存器為例，計算重寫如下：3)（Register-to-Pin）ClockSetupSlackTime=DataRequiredTime–DataArrivalDataArrivalTime=LaunchEdge+ClockNetworkDelaytoSourceRegister++Register-to-PinDataRequiredTime=ClockArrivalTime–OutputumDelayofClockArrivalTime=LatchEdge+ClockNetworkDelaytoDes