# SDC
<font color="#1936C9">**電路中定義constrain的重要文件提供時序約束通常使用在以下三種場合**</font>

1. Synthesis (Design Complier)
2. STA(Primetime)
3. Place and Route (Innovus)

## <font color="#1936C9">Create clock</font>
> create_clock -name CLK1 -period 10 [get_ports clk]

## <font color="#1936C9">Max/Min delay</font>
主要用於約束內部資料路徑（Data Path）的延遲，適合需要對特定路徑進行時序控制的情況

### Max delay(setup time)
設定信號從起點到終點的最大允許延遲，目的是避免建立時間（Setup Time）違規。

信號在傳遞到接收時脈域的建立時間窗口內需要保持穩定，否則接收器可能無法正確鎖存數據，確保延遲不會超過允許的範圍確保信號能夠在設定的時序約束內傳遞到接收端，以避免違反建立時間（setup time）要求。

> set_max_delay [-datapath_only] [-from <node_list>][-to <node_list>][-through <node_list>]

### Min delay(hold time)
設定信號從起點到終點的最小延遲，目的是避免保持時間（Hold Time）違規。

如果信號到達接收端的速度過快（即延遲過短），可能會破壞接收時脈域的保持時間要求，確保信號在傳遞過程中不會因延遲過短而觸發保持時間（hold time）違規

>set_min_delay [-from <node_list>] [-to <node_list>][-through <node_list>]

reference https://blog.csdn.net/weixin_41230430/article/details/141886987

## <font color="#1936C9">Input/Output Delay</font>
主要用於描述設計與外部環境的接口行為，幫助工具理解輸入和輸出的延遲需求，也就是io接口描述
### **Input delay:**
設計接收到輸入信號的時間與時鐘邊緣之間的延遲
外部設備 ---> (2.0ns 延遲) ---> 設計內部
> set_input_delay -max 2.0 -clock [get_clocks CLK1] [get_ports data_in]

### Output delay:
輸出信號到達外部設備的時間點相對於時鐘邊緣的延遲。
設計內部 ---> (3.0ns 延遲) ---> 外部設備

>set_output_delay -max 3.0 -clock [get_clocks CLK1] [get_ports data_out]

## <font color="#1936C9">Min/Max Delay vs Input/Output Delay</font>
### <font color="#1936C9">通常有時候會寫在一起</font>

| | Max/Min Delay | Input/Output Delay |
| -------- | -------- | -------- |
| 目的 | Data path的訊號傳輸之間需要滿足的timing constrain | 設計與外部接口（I/O）之間信號傳遞的時序限制|
| 主要限制目標| setup/hold time violation | 設計內部訊號與外部傳輸時避免time violation |
* Max Delay：避免資料到達下一級寄存器太晚，導致 Setup Violation。
* Min Delay：避免資料到達下一級寄存器太早，導致 Hold Violation。

## <font color="#1936C9">False path</font>
**<font color=red>False Path 僅用於跨時鐘域或無效路徑，不要將真正需要滿足時序的路徑誤設為 False Path，否則會導致設計失效</font>**
False Path 是指在設計中存在的數據路徑，雖然工具會進行時序分析，但實際上這些路徑不會影響電路的正確功能。因此，這些路徑可以忽略時序檢查，從而減少不必要的時序違規報告和設計約束的壓力。
例如afifo 中的第一個dff一定會time violation 這時候就可以設定false path 不去檢查

> set_false_path -from [get_ports clk1] -to [get_ports clk2]

## <font color="#1936C9">asynchronous group</font>
適用於CDC，告訴工具不要分析兩個異步時鐘域的時序。
EDA不分析兩個時域之間的時序，但需要執行完整的TIMEING 分析
相比於false path，完全忽略掉指定的時序(需要自行確認忽略的時序是否正確)

> set_clock_groups -name group1 -asynchronous -group {clk1} -group {clk2}

## <font color="#1936C9">Multicycle path</font>
設計中某些路徑需要多個時鐘週期完成資料傳遞，這些路徑的時序要求可以適當放寬，避免工具按照單個時鐘週期進行時序檢查，通常用於運算延遲較大的路徑，例如乘法器、除法器或複雜的組合邏輯。

假設一個跨時鐘域的同步器需要 3 個時鐘週期完成穩定化
> set_multicycle_path 2 -setup -from [get_pins A] -to [get_pins B]
> set_multicycle_path 1 -hold -from [get_pins A] -to [get_pins B]

## <font color="#1936C9">False Path vs Multicycle Path 比較</font>
| | false path | Multicycle Path|
| -------- | -------- | -------- |
| 目的 | 排除某些不影響功能的時序路徑，例如跨時鐘域（CDC）中的同步寄存器(就是第一個DFF) | 有些設計需要多個時鐘週期才能完成資料傳遞（如乘法器、除法器等運算模組），此時可以設置 Multicycle Path，延長 STA 工具對該路徑的時序檢查週期 |
| 主要限制目標 | 完全忽略指定路徑的時序檢查，避免無效的違規報告 | 告知工具該路徑的時序要求應延長多個時鐘週期以匹配設計需求 |

## <font color="#1936C9">Clock Uncertainty</font>
Clock Uncertainty 是時鐘信號的不確定性，來自 Clock Jitter 和 Clock Skew，在STA，它直接影響 Setup 和 Hold 的檢查，對設計性能有重要影響。
這裡要補充一下
在Prelayout階段因為我們沒有CTS所以也無法預估skew是多少，因此在這個階段會設定clock 沒有skew，但因為uncertainty包含一些margin 和 jitter 所以還是需要設定，而在POSTLAYOUT階段因為已經實際上有CTS了，這時候的skew會被提出來另外計算，因此我們可以下一個結論，以STA的角度來說，uncertainty內只有包含jitter and margin

> set_clock_uncertainty 0.2 [get_clocks CLK1]

#### <font color=red> minus uncertainty is for setup time</font>
#### <font color=red> plus uncertainty is for hold time</font>

### Clock Jitter

clock來源是晶片外部腳位引入或是內部PLL產生的。 兩個時脈週期之間存在的差值，佈線對其沒有影響

reference https://www.cnblogs.com/zeushuang/archive/2012/07/04/2575849.html

### Clock Skew

Clock Skew 是指同一時鐘信號在不同元件（例如 Flip-Flops 或 Memory Cells）之間的到達時間差異。

### How to fix clock skew

解決 Clock Skew 的核心方法是通過 時鐘樹綜合（CTS） 和物理設計優化來平衡時鐘信號的延遲。同時，使用 STA 工具和物理設計工具進行反覆分析和修正，確保設計在高性能和高速條件下仍能穩定運行

## <font color="#1936C9">Clock Transition Time</font>
時鐘信號從低電平轉換到高電平（上升時間）或從高電平轉換到低電平（下降時間）所需的時間

# SDF
<font color="#1936C9">**作為 STA 和模擬的輸入文件，用於分析延遲和驗證時序**</font>

* 邏輯合成後生成初步 SDF
dc_shell> read_verilog design_rtl.v
dc_shell> read_lib timing.lib
dc_shell> write_sdf design_initial.sdf

* 佈局佈線後生成 RC 提取的 SDF
icc_shell> read_netlist design_netlist.v
icc_shell> write_parasitics design.spef
icc_shell> write_sdf design_layout.sdf

* PrimeTime 生成最終 SDF
pt_shell> read_verilog design_netlist.v
pt_shell> read_lib timing.lib
pt_shell> read_spef design.spef
pt_shell> write_sdf design_final.sdf

### 總結:

.SDF 文件生成的方式取決於設計流程中的階段：

邏輯綜合工具生成粗略的 SDF。
佈局佈線工具生成基於 RC 提取的 SDF。
靜態時序分析工具生成最終精確的 SDF。

生成的工具與指令：

dc_shell：write_sdf
IC Compiler：write_sdf
PrimeTime：write_sdf

## Negative Timing Check

## EDA Tool
### 1. Design Complier: 用來Synthesis
輸入:

RTL
.SDC
.LIB ..

輸出

Netlist.v
Design Constraint(DC後的.sdc)

### 2. Primetime: 檢查時序違反，還提供詳細的延遲路徑、slack 報告，以及對設計的優化建議
輸入:

Netlist.v
.sdc(DC後的.sdc)
.sdf(STA的primetime產生)

輸出

時序分析報告（如 setup/hold violations）。
優化建議。

## 有寫錯的地方請聯絡
[e-mail]