邏輯寫多了，有時候一些基本的錯誤忘了避免了。
昨天設計邏輯的時候就不小心觸雷了，有個訊號有激勵沒響應，後來看了時序報告，有這麼一句話。
這是 什麼呢？鎖存器啊！
最容易產生的是在always（*）語句中，最後一定是所有分支條件都要描述並賦值。
狀態機中，同樣如此，不但需要有default的狀態,每個狀態的都要有所有的分支都要賦值。
而時序邏輯綜合結果必然是觸發器，因此不用檢查時序邏輯的分支條件。所以還是那句話，能用時序邏輯，就盡量別用組合邏輯。
當然如果是老鳥，這句話可忽略。
阻塞和非阻塞，這件事情百分之九十九點九九是筆誤，沒見過開發者沒事非要冒險試一下「=」跟「<=」的區別。
很多人說這兩個沒啥區別，這兩個符號啊，沒出事就好，出事了查起來就煩了。
所以記好了，組合邏輯裡面用=，時序邏輯裡面用＜=，肯定不會錯。
硬體描述語言的坑還是很少的， 搞來搞去就是組合邏輯、時序邏輯，一些generat加for迴圈就算複雜的了，因此這塊能說的不多。
程式語言不是語言本身，而是每句邏輯之後的電路，新手入門學習的初學者一定要注意。
邏輯設計中多時鐘設計 2
在上個系列中，主要分析了單bit時鐘訊號是如何在多個時鐘域中進行同步的。概括起來只有兩點 一是通過同步器，二是將控制訊號與資料訊號合併成一組 資料 控制 匯流排，經過fifo或ram實現跨時鐘域設計。那麼在這節中，重點來分析跨時鐘域這個概念。通過這節的分析，可以知道那些型別的時鐘，在實際的處理過程中...
微服務架構中的業務邏輯設計
前言 企業應用程式的核心是業務邏輯，業務邏輯實現了業務規則。但是由於業務邏輯分散在多個服務上，因此在微服務架構中開發複雜的業務邏輯更具有挑戰性。我們需要解決兩個問題 首先，典型的領域模型是由各種類交織在一起的乙個網路。雖然這在單體應用程式中不是問題，但是在微服務架構中，類分散在不同的服務中，就需要跨...
資料庫的邏輯設計
oracle優化軟結構 能移出system表空間的東西盡量移出。將程式表和資料表分別存在不同的表空間。減少io操作 索引段不應該與其相關的表存在同乙個表空間。因為dml操作的時候同時會維護所以。alter index index name rebuild tablespace tablespace ...