---
# System prepended metadata

title: 'Coding And Scripting Techniques For FSM Designs WithSynthesis-Optimized, Glitch-Free Outputs '

---

### 這篇文章很清楚的比較出了為什麼 output logic 用循序邏輯的方式撰寫比較適合用來做合成

![](https://hackmd.io/_uploads/rJ0RDn0d2.png)


| 撰寫方式 | 是否有可能會產生Glitch | 消耗timing cycle? |
| -------- | -------- | -------- |
| 組合邏輯     | 有   | 會 ( 因為他是組合邏輯 )     |
| 循序邏輯     | 否    | 不會     |



翻譯成中文的話也就是說，**這樣的設計方式是為了極大程度的簡化合成的難度**。
如果只是像之前使用Combinational Logic來進行Output logic的設計的話，可能會造成我們沒有辦法達到預設的Contraint，進而需要在「合成約束」這邊下更大的工夫去調整，顯然使用registered outputs來輸出我們的電路輸出是一種比較好的辦法。

![](https://hackmd.io/_uploads/rkxbdhA_n.png)


上圖就是一個比較不好的例子，利用組合邏輯輸出，導致我們後續要接其他模組的時候，往往需要考慮不同的Constarint，這樣的案例在少Module的情況還好處理，但是萬一我們的電路數以萬計，顯然會產生相當大的問題，這就是我什麼我們要鼓吹Registered outputs的做法的原因。


## BAD FSM STYLE( Outputs logic with combinational logic )  

![](https://hackmd.io/_uploads/r1cMOnAdh.png)


## GOOD FSM STYLE( Registered Outputs )

![](https://hackmd.io/_uploads/ryRXOhRu3.png)


![](https://hackmd.io/_uploads/r12NOnRun.png)



### 相較於使用組合邏輯作為Output的寫法，這樣的寫法既可以讓我們更容易符合Timing的設計，更可以降低有Glitch的風險，當然這邊我們也是採用熟悉的三段式的設計。

## 總結：這些做法告訴我們只要把狀態機寫的清楚且乾淨，輸出也用循序邏輯輸出就不會有大問題了。
