時序約束增量編譯
⑴ FPGA時序約束的幾種方法（待續）
從最近一段時間工作和學習的成果中，我總結了如下幾種進行時序約束的方法。按照從易到難的順序排列如下： 0. 核心頻率約束 這是最基本的，所以標號為0。 1. 核心頻率約束+時序例外約束 這還不是最完整的時序約束。設計者的思路還局限在FPGA晶元內部。 2. 核心頻率約束+時序例外約束+I/O約束（包括位置、外部走線延時、上下拉電阻、驅動電流強度等等） 這才是最完整的時序約束。FPGA作為PCB上的一個器件，是整個PCB系統時序收斂的一部分。FPGA作為PCB設計的一部分，是需要PCB設計工程師像對待所有COTS器件一樣，閱讀並分析其I/O Timing Diagram的。FPGA不同於COTS器件之處在於，其I/O Timing是可以在設計後期在一定范圍內調整的；雖然如此，最好還是在PCB設計前期給與充分的考慮並歸入設計文檔。 正因為FPGA的I/O Timing會在設計期間發生變化，所以准確地對其進行約束是保證設計穩定可控的重要因素。許多FPGA外部器件在FPGA重新編譯後出現不穩定的問題都有可能是由此引起的。 3. 核心頻率約束+時序例外約束+I/O約束+LogicLock LogicLock是FPGA器件內部的布局約束。從一次成功的時序收斂結果開始，把特定的一組邏輯在FPGA上實現的布局位置和范圍固定下來。相應地，其布線結果和時序收斂結果也就得到了間接的保證。需要注意的是，LogicLock不同於DesignPartition中的Post-fit Netlist。LogicLock的約束是粗粒度的，並且其精度范圍是可調整的；而引入Post-fit Netlist是精確到門級的細粒度約束。 4. 核心頻率約束+時序例外約束+I/O約束+FloorPlan+LogicLock FloorPlan也是FPGA器件內部的布局約束，是LogicLock的一種特例。成功的FloorPlan需要設計者對可能的時序收斂目標作出預計，並可以參考上一次時序成功收斂的結果。FloorPlan給了設計者對布局位置和范圍更多的控制，不能也不可能照搬上一次時序收斂後零散的布局結果，所以對設計者的要求比簡單的LogicLock要高。由於獲得了更多的自主的控制權，時序收斂結果的可重現性也就越高。 5. 核心頻率約束+時序例外約束+I/O約束+寄存器布局約束 寄存器布局約束是精確到寄存器或LE一級的布局約束。設計者通過對設計施加更精準的控制來獲得更可靠的時序收斂過程。
⑵ fpga時序約束輸入和輸出兩個約束就夠用了嗎
從系統上來看，同步時序約束可以分為系統同步與源同步兩大類。簡單點來說，系統同步是指FPGA與外部器件共用外部時鍾:源同步(SDR, DDR) 即時鍾與數據一起從上游器件發送過來的情況。在設計當中，我們遇到的絕大部分都是針對源同步的時序約束問題。所以下文講述的主要是針對源同步的時序約束。
根據網路上收集的資料以及結合自己的使用習慣，我比較趨向於下面的約束流程方式:時序約束一共包含以下幾個步驟:
1.首先約束時鍾。輸入時鍾，輸出時鍾。從種類來看不外乎以下幾種:單端輸入時鍾、差分輸入時鍾、GT或恢復時鍾(例如LVDS信號恢復出來的時鍾)、PLL產生的時鍾以及自己產生的門控時鍾。
2. I0約束。只有等待內部時鍾完全通過後，再配置input delay和output delays， 告知FPGA外部埠的數據時序關系。
3.時序例外。在約束完時鍾以及I0後，還是有時序違例的時候，注意檢查一下是否有 時序例外的情況。
⑶ Quartus II中的完全編譯包括幾個環節每個環節分別完成什麼功能
直接全編譯(Ctrl + L)就知道有哪些環節了
分析和綜合:這里主要是檢查每個源文件的語法錯誤,生成門級代碼,模塊之間的錯誤可能檢查不出來;
布局和布線:針對不同的器件進行優化,布局布線,這是關鍵步驟
匯編:產生編程文件,簡單的fpga工程就完了
完整的步驟還有時序約束,約束完再編譯,查看時序分析是否滿足條件,再修改,這是一個反復的過程,如果要用第三方的工具進行模擬還需要單獨生成對應的時序網表,包括一下模擬模型,延時輸出文件等
⑷ fpga中添加時序約束問題
去這里把官方文檔下下來：https://www.altera.com/en_US/pdfs/literature/manual/mnl_sdctmq.pdf
第167頁的解釋如圖：
看懂了沒？
就是如果說加了-expand，那麼derive_clocks等等這一類執行源時鍾關聯操作的宏指令將會在被寫入SDC文件之前就已經得以預編譯展開，而如果不勾選，則只是寫入SDC文件，不預先執行預編譯展開操作。
⑸ FPGA時序約束
https://my.oschina.net/u/4583591/blog/4455472
時序分析本質上就是一種時序檢查，目的是檢查設計中所有的D觸發器是否能夠正常工作，也就是檢查D觸發器的同步埠（數據輸入埠）的變化是否滿足建立時間要求（Setup）和保持時間要求（Hold）；檢查D觸發器的非同步埠（非同步復位埠）的變化是否滿足恢復時間要求（Recovery）和移除時間要求（Removal）。
時序分析包括靜態時序分析（STA）和動態時序分析。
靜態時序分析使用的工具：
動態時序分析使用的工具：
撰寫基本的時序約束文件，告知時序引擎一些必要的信息（比如時鍾，輸入輸出延時等）。若沒有正確的時序約束，那麼時序分析的結果是沒有意義的。
第一種，從FPGA的輸入埠到目的寄存器的數據輸入埠 。
第二種，從源寄存器的時鍾埠到目的寄存器的數據輸入埠。
第三種，從源寄存器的時鍾埠到FPGA的輸出埠。
第四種，從FPGA的輸入埠到FPGA的輸出埠。
Data Arrival time = lauch_edge + Tclka + Tco + Tdata(Tlogic+Tnet)
Data Require Time = capture edge + Tclkb - Tsu
Setup Slack= Data Require Time - Data Arrival Time
Setup Slack = （Capture edge – Launch edge）+ （destination clk delay – source clk delay）- Setup time - clk uncertainty – datapath delay
Setup Slack = Setup Requirement（一定大於0） + clk skew – Tsu – Tclk uncertainty – Tlogic – Tnet - Tco
① Setup Requirement 與實際情況不符
建立時間需求過小，這種情況通常會在同步跨時鍾域路徑中出現，在同步跨時鍾域路徑中的源時鍾頻率與目的時鍾頻率的相位關系雖然是已知的，但是時序引擎默認選擇的捕獲沿通常都是錯誤的，需要用戶通過多周期路徑約束的方式手動修正建立時間需求。比如下圖中，兩個同頻不同相的同步時鍾，時序引擎默認選擇的捕獲沿是目的時鍾第二個上升沿，導致建立時間需求非常小，最終肯定會導致時序違例。
② clk skew為負值，且很大
通常情況下，同一個時鍾下的時鍾歪斜不應該超過300ps，同步跨時鍾域路徑的時鍾歪斜不應該超過500ps，非同步跨時鍾域路徑的時鍾歪斜一般比較大，因為它們的時鍾源不同。當出現時鍾歪斜大的情況時:
③Tsu/Tco大
當設計中使用Block（DSP/Block RAM等）時，應該要注意以下問題。對於以這些Block為時序路徑的起點或終點的時序路徑，這些Block的Tsu/Th/Tco都比普通的寄存器大，而且這些Block的布線延時和時鍾歪斜比較大。所以當使用這些Block作為時序路徑的終點時，它的起點一定要是觸發器，比如說一個Block RAM的寫數據信號，輸入進Block前最好打一拍。當使用這些Block作為時序路徑的起點時，應該使用Block 內部的輸出寄存器，比如使用由Block RAM組成的FIFO時，盡量不要使用首字置出的，而使用打一拍後輸出的，使用後者可以顯著降低Tco。當時序路徑為從一個Block到另一個Block時，中間需要進行打拍操作。當使用這些Block的控制埠時，應該保證這些控制信號的低扇出，如使用由Block RAM組成的FIFO時，應該盡量降低讀/寫能信/地址信號的扇出。
④Tlogic大
一般情況下，邏輯延時與時序路徑的邏輯層級數息息相關，邏輯層級是指時序路徑的起點和終點之間組合邏輯單元（LUT）的個數，而邏輯層級多一級意味著多1個LUT的延時加1條連接LUT的網線延時。通常一級邏輯層級的延時標準是1個LUT加1根網線的總延遲為0.5ns，如果某條路徑的邏輯級數大於時鍾周期/0.5ns，那麼這條路徑就被稱為長路徑。
常用的處理長路徑的方案有兩種：
⑤Tnet大
一般情況下，布線延遲與設計整體或局部模塊的資源利用率以及擁塞程度息息相關。在正常情況下，一條網線的延時小於1ns，在發生擁塞的區域，網線的延時可能達到若干ns，導致布線延時顯著增加。為了解決布線延遲大，需要從降低資源利用率和降低擁塞程度下手，比如某個模塊使用了大量的寄存器堆，佔用了大量的資源，此時應該考慮使用Block RAM代替這些寄存器堆；某個模塊使用了大量的數據選擇器，此時應該考慮如何優化這些數據選擇器；某個模塊的控制信號扇出比較大，與其他模塊的互聯很重，此時應該考慮如何降低這些信號的扇出；某條時序路徑的起點或終點是Block，由於Block的位置比較固定，所以Block的布線延遲會大一些。最後需要強調的是，一定要額外關注高扇出的網線也會對布線延時產生影響。🔺TimeQuest時序分析（Setup）[圖片上傳失敗...(image-23b6a0-1596829289696)]
①確定保持時間要求（確定發起時鍾沿和捕獲時鍾沿）
保持時間要求是以建立時間要求為基礎的，保持時間要求有兩種：
根據所有的建立時間需求找到所有的保持時間需求，並從保持時間需求（可正可負）中找到最大的保持時間需求。
②計算數據的需求時間
③計算數據的到達時間
④計算Hold up的裕量（slack）
Data Arrival time（new data） = lauch edge + Tclka + Tco + Tdata(Tlogic+Tnet)
Data Require time = capture edge + Tclkb + Th
Hold up slack = Data Arrival time - Data Require time
Holp Slack = （lauch edge - capture edge） + （Tclka – Tclkb） + Tco + Tdata(Tlogic+Tnet) -Th
Holp Slack = Tco + Tdata(Tlogic+Tnet) -Th - Holp Requirement - clk skew
Hold up Slack為負的情況比較少見，當Setup Slack有較大裕量時，通常工具會自動插入延時來增加Hold up Slack。
①保持時間需求大於0（通常由時序引擎選擇錯誤的捕獲沿導致）
②時鍾歪斜大於300ps（通常由時鍾路徑上的組合邏輯導致）
③Th過大（通常由時序路徑終點為Block導致）
時序引擎能夠正確分析4種時序路徑的前提是，用戶已經進行了正確的時序約束。時序約束本質上就是告知時序引擎一些進行時序分析所必要的信息，這些信息只能由用戶主動告知，時序引擎對有些信息可以自動推斷，但是推斷得到的信息不一定正確。
首先用戶必須要正確的約束時鍾，時序引擎才能根據時鍾信息進行各種時序檢查。
用戶約束時鍾時，一般有兩種類型的時鍾需要約束。
①主時鍾（Primary Clock）約束
使用Create_clock進行時序約束
全局時鍾輸入引腳是ClkIn，時鍾周期10ns，占空比25%，相移90度。
②生成時鍾（Generated Clock）約束
用Create_generated_clock進行時序約束 每個生成時鍾都會對應一個時鍾源（Master_clk），這個時鍾源可以是Primary Clock或者另一個Generated Clock。在約束生成時鍾時，用戶不需要描述生成時鍾的周期和波形，只需要描述由Master_clk經過了怎樣的變化而產生的生成時鍾即可。比如經過分頻（-devide_by），倍頻(-multiply_by)，反相（-invert），相移（-edge_shift）等等操作。
當生成時鍾需要進行相移時，使用-edge_shift選項。-edge_shift不能與-divide_by/-multipl_by/-invert同時使用 。
時序引擎默認情況下會分析所有時鍾之間的時序路徑，用戶可以通過時鍾分組（ set_clock_group）命令或偽路徑（set_false_path）命來關閉一部分路徑的時序分析。
①同步時鍾（synchronous clock）
兩個時鍾之間的相對相位關系是固定的（兩個時鍾來源於同一個Primary clock），並且這兩個時鍾的頻率的最小公共周期是個整數。比如一個生成時鍾（200M）和該生成時鍾的Master_clk（100M）之間就屬於同步時鍾關系，因為這兩個時鍾的相位關系肯定是確定的，並且可以找到兩個時鍾的最小公共周期。通常情況下，一個Primary Clock和它產生的生成時鍾之間都屬於同步時鍾關系，除非找不到最小公共周期。 **屬於同步時鍾關系的兩個時鍾之間的路徑是可以進行時序分析的。
②非同步時鍾（ asynchronous clock ）
兩個時鍾之間的相對相位關系不確定。比如FPGA上兩個晶振分別產生兩個Primary clock（相對相位關系不固定），這兩個Primary clock分別從FPGA的兩個全局時鍾引腳輸入給兩個MMCM，由兩個MMCM分別產生的生成時鍾之間屬於非同步時鍾。一般情況下，不同的Primary clock之間都屬於非同步時鍾，這些Primary clock分別產生的生成時鍾之間也屬於非同步時鍾關系。 **屬於非同步時鍾關系的兩個時鍾之間的路徑無法進行正確的時序分析。
一般情況下，如果用戶不通過時鍾分組對時鍾之間的關系進行約束，時序引擎會默認所有的時鍾之間都屬於同步時鍾關系。
③不可擴寬的時鍾（unexpandable clock）
對於這類時鍾，時序引擎無法在1000個時鍾周期內找到兩個時鍾的公共周期，時序引擎就會從這1000個時鍾周期中找到建立時間需求最差的情況，並進行時序分析，然而它不一定FPGA實際允許過程中建立時間需求最差的情況，因為在1000個時鍾周期外可能還會有建立時間需求更差的情況，這樣一來，時序引擎的分析結果就無法保證該路徑一定不會出現問題，所以時序引擎的分析結果也就變的無意義。比如說由同一個Primary Clock驅動的兩個MMCM的生成時鍾分別是clk0（5.125ns）和clk1（6.666ns），雖然它們的相對相位關系是固定的，但是時序引擎無法保證對兩個時鍾之間路徑的分析屬於最差情況，這種情況和非同步時鍾之間的時序分析類似，時序分析的結果都看起來正常，但是這個結果確是不可信的。所以對這種時鍾的處理方式與處理非同步時鍾是相同的，用戶都需要進行跨時鍾域的操作。
總結：非同步時鍾和不可擴展的時鍾之間的路徑都無法進行正確的時序分析，所以在時序分析之前，需要使用set_clock_group對時鍾進行分組，從而將這些無法進行正確時序分析的路徑忽略掉。
Input delay概念
Input delay計算
Max Input Delay = Tco(Max) + Tpcb(Max) - Clk skew(Min)
Min Input Delay = Tco(Min) + Tpcb(Min) - Clk skew(Max)
Input delay約束
Output delay概念
Output delay計算
Max Output Delay = Tpcb(Max) + Tsu - Clk skew(Min)
Min Output Delay = Tpcb(Min) - Th - Clk skew(Max)
Output delay約束
時序引擎默認情況下會在建立時間需求/保持時間需求最差的情況下進行時序分析，而時序引擎選擇的這種需求不一定是用戶真正希望的，而且時序引擎默認選擇的這種需求是非常嚴苛的，甚至是根本無法滿足的。此時就需要用戶進行Multicycle約束，手動修改建立時間需求/保持時間需求。用戶希望放鬆某些路徑的約束力度，就可以通過Multicycle約束調整建立時間需求/保持時間需求。
使用set_multicycle_path命令進行約束
註：使用set_multicycle_path命令
①在源時鍾和目的時鍾相同的情況下進行Multicycle約束
②在源時鍾和目的時鍾頻率相同且有正向偏移的情況下（正向偏移0.3ns）
⑹ fpga時序約束問題,重金感謝呀。。。求大俠幫幫忙。。
這個光看這個也看不到具體信息啊 那你的那個整體報告裡面去點timing constrain ，然後找那些打了叉子或者顯示某個時鍾或者別的什麼的時鍾約束沒過有個NO，如果你做的是相對高速的東西，盡量把那些高速時鍾換成低速的，還有一些不好的編程習慣都有可能造成這樣的結果。
你可以查看一下ISE的幫助裡面有關於全部時鍾約束的類似datasheet的東西，刻意去學暫時沒必要，有什麼查什麼吧。希望對你有幫助
⑺ 關於quartus時序約束方法
占空比約束沒問題 不寫也可以 預設就是50%
雖然都是用於pin的約束 tsu/th和offset不是一回事（offset是io的數據和時鍾的延遲 tsu/th是晶元里的dff的數據和時鍾的延遲關系 不考慮clock skew的話 應該滿足offset+tsu+delay <= T） 如果是registered-in/registered-out的設計 沒必要加tsu/th約束了
原則上講hold time不需要設的 這就是工藝的一個參數 選擇了器件以及環境條件以後 工具自然獲取了該參數
不管哪個廠家的fpga 肯定hold violation都少於setup violation的
如果出現這種情況 一般都是時鍾有問題 查一下clk是否使用了全局時鍾資源 再查一下TimeQuest選項Common Clock Path Pessimism Removal是否使能
⑻ 求助，下圖中的時序約束在dc中如何實現
從最近一段時間工作和學習的成果中，我總結了如下。按照從易到難的順序排列如下：0. 核心頻率約束這是最基本的，所以標號為0。1. 核心頻率約束+時序例外約束時序例外約束包括FalsePath、MulticyclePath、MaxDelay、MinDelay。但這還不是最完整的...
⑼ 幾種進行時序約束的方法
從最近一段時間工作和學習的成果中，我總結了如下。按照從易到難的順序排列如下： 0. 核心頻率約束 這是最基本的，所以標號為0。 1. 核心頻率約束+時序例外約束 時序例外約束包括FalsePath、MulticyclePath、MaxDelay、MinDelay。但這還不是最完整的時序約束。如果僅有這些約束的話，說明設計者的思路還局限在FPGA晶元內部。 2. 核心頻率約束+時序例外約束+I/O約束 I/O約束包括引腳分配位置、空閑引腳驅動方式、外部走線延時（InputDelay、OutputDelay）、上下拉電阻、驅動電流強度等。加入I/O約束後的時序約束，才是完整的時序約束。FPGA作為PCB上的一個器件，是整個PCB系統時序收斂的一部分。FPGA作為PCB設計的一部分，是需要PCB設計工程師像對待所有COTS器件一樣，閱讀並分析其I/O Timing Diagram的。FPGA不同於COTS器件之處在於，其I/O Timing是可以在設計後期在一定范圍內調整的；雖然如此，最好還是在PCB設計前期給與充分的考慮並歸入設計文檔。 正因為FPGA的I/O Timing會在設計期間發生變化，所以准確地對其進行約束是保證設計穩定可控的重要因素。許多在FPGA重新編譯後，FPGA對外部器件的操作出現不穩定的問題都有可能是由此引起的。 3. 核心頻率約束+時序例外約束+I/O約束+Post-fit Netlist 引入Post-fit Netlist的過程是從一次成功的時序收斂結果開始，把特定的一組邏輯（Design Partition）在FPGA上實現的布局位置和布線結果（Netlist）固定下來，保證這一布局布線結果可以在新的編譯中重現，相應地，這一組邏輯的時序收斂結果也就得到了保證。這個部分保留上一次編譯結果的過程就是Incremental Compilation，保留的網表類型和保留的程度都可以設置，而不僅僅局限於Post-fit Netlist，從而獲得相應的保留力度和優化效果。由於有了EDA工具的有力支持，雖然是精確到門級的細粒度約束，設計者只須進行一系列設置操作即可，不需要關心布局和布線的具體信息。由於精確到門級的約束內容過於繁多，在qsf文件中保存不下，得到保留的網表可以以Partial Netlist的形式輸出到一個單獨的文件qxp中，配和qsf文件中的粗略配置信息一起完成增量編譯。 4. 核心頻率約束+時序例外約束+I/O約束+LogicLock LogicLock是在FPGA器件底層進行的布局約束。LogicLock的約束是粗粒度的，只規定設計頂層模塊或子模塊可以調整的布局位置和大小（LogicLock Regions）。成功的LogicLock需要設計者對可能的時序收斂目標作出預計，考慮特定邏輯資源（引腳、存儲器、DSP）與LogicLock Region的位置關系對時序的影響，並可以參考上一次時序成功收斂的結果。這一權衡和規劃FPGA底層物理布局的過程就是FloorPlanning。LogicLock給了設計者對布局位置和范圍更多的控制權，可以有效地向EDA工具傳遞設計者的設計意圖，避免EDA工具由於缺乏布局優先順序信息而盲目優化非關鍵路徑。由於模塊在每一次編譯中的布局位置變化被限定在了最優的固定范圍內，時序收斂結果的可重現性也就更高。由於其粗粒度特性，LogicLock的約束信息並不很多，可以在qsf文件中得到保留。 需要注意的是，方法3和4經常可以混合使用，即針對FloorPlanning指定的LogicLock Region，把它作為一個Design Partition進行Incremental Compilation。這是造成上述兩種方法容易混淆的原因。5. 核心頻率約束+時序例外約束+I/O約束+寄存器布局約束 寄存器布局約束是精確到寄存器或LE一級的細粒度布局約束。設計者通過對設計施加精準的控制來獲得可靠的時序收斂結果。對設計中的每一個寄存器手工進行布局位置約束並保證時序收斂是一項浩大的工程，這標志著設計者能夠完全控制設計的物理實現。這是一個理想目標，是不可能在有限的時間內完成的。通常的做法是設計者對設計的局部進行寄存器布局約束並通過實際運行布局布線工具來獲得時序收斂的信息，通過數次迭代逼近預期的時序目標。 不久前我看到過一個這樣的設計：一個子模塊的每一個寄存器都得到了具體的布局位置約束。該模塊的時序收斂也就相應地在每一次重新編譯的過程中得到了保證。經過分析，這一子模塊的設計和約束最初是在原理圖中進行的，在達到時序收斂目標後該設計被轉換為HDL語言描述，相應的約束也保存到了配置文件中 6. 核心頻率約束+時序例外約束+I/O約束+特定路徑延時約束 好的時序約束應該是「引導型」的，而不應該是「強制型」的。通過給出設計中關鍵路徑的時序延遲范圍，把具體而微的工作留給EDA工具在該約束的限定范圍內自由實現。這也是一個理想目標，需要設計者對每一條時序路徑都做到心中有數，需要設計者分清哪些路徑是可以通過核心頻率和簡單的時序例外約束就可以收斂的，哪些路徑是必須制定MaxDelay和MinDelay的，一條也不能遺漏，並且還需要EDA工具「善解人意」的有力支持。設定路徑延時約束就是間接地設定布局布線約束，但是比上述3、4、5的方法更靈活，而且不失其准確性。通過時序約束而不是顯式的布局和網表約束來達到時序收斂才是時序約束的真諦。 記得有網友說過「好的時序是設計出來的，不是約束出來的」，我一直把這句話作為自己進行邏輯設計和時序約束的指導。好的約束必須以好的設計為前提。沒有好的設計，在約束上下再大的功夫也是沒有意義的。不過，通過正確的約束也可以檢查設計的優劣，通過時序分析報告可以檢查出設計上時序考慮不周的地方，從而加以修改。通過幾次「分析—修改—分析」的迭代也可以達到完善設計的目標。應該說，設計是約束的根本，約束是設計的保證，二者是相輔相成的關系。