今天開始看特權大大的《實戰演練之時序收斂》，看到set_max_delay時跟着做了一下，設置了最大延時為3ns,然后report timing突然自動飄紅了，很意外，於是看了看瓢紅的路徑的waveform，意外的發現set_max_delay中設置的值成了latch edge time,由於E文不好google了半天也沒找到原因，於是再次祭法寶(從TimeQuest方向進行猜測)。由於report timing飄紅讓我這種初學者心里有壓力，於是先將set_max_delay設置為5ns,然后果然不飄紅了。開始找原因吧，先去data require path看看,果然latch edge time變成了5ns，也就是說latch edge time就是設置的最大延時。
再看一下data arrive path
發現上圖中的所有的時鍾延時為負的都是由PLL產生的，我理解是因為PLL自動對時鍾相位進行了負的偏移來修正走線以及其他的的延時。
再看一下Technology Map Viewer中的視圖：
從上面的圖中我們可以看到其實在這兩個節點上所謂的setup slack分析其實無非就是想說明從clk的時鍾信號經過鎖相環的變換到sr_clk輸出共花費了3.045ns,也就是說clk+走線延時+邏輯延時－（PLL修正的延時的絕對值）就是clk到sr_clk之間的輸出延時。那么為什么set_max_delay的值為什么變為latch edge time了呢，下面再看一下waveform,如圖：
這下都清晰了，其實TimeQuest是借用了register to register的setup slack的分析模型來檢查，布局布線后的延時是否大於我們set_max_delay中設置的延時。由圖可以看到，clk經過變換達到引腳sr_clk（包含PLL的相位偏移修正）共是3.045ns,這點也可以從data arrive path上看出，然后將latch edge time設置為set_max_delay的值這樣就可以檢測set_max_delay 的值是否大於clk到sr_clk的延時，也就是說其實這里僅僅巧妙的借用了setup slack的分析模型來檢測布線延時是否滿足要示。最后，一切均為猜測，沒有官方依據，如有不對請大家指出哈！