【芯片設計】系統(tǒng)中的可維可測狀態(tài)記錄寄存器設計

倒序瀏覽 · 發(fā)表于 2024-12-4 12:01:00

仍舊是在交付過程中的總結輸出，本篇旨在討論下在系統(tǒng)和模塊中設置可維可測寄存器的方案與經驗。為什么為什么要寫可維可測寄存器呢？先扯一扯虎皮，隨著電子技術的飛速發(fā)展，芯片設計已成為現(xiàn)代電子系統(tǒng)的核心。在這一領域，芯片的復雜性和集成度不斷提高，對設計者提出了更高的要求。其中，可維護性和可測試性是確保芯片長期穩(wěn)定運行和快速定位問題的關鍵因素。芯片設計不僅僅是電路的布局和邏輯的實現(xiàn)，它還涉及到系統(tǒng)的整體性能、可靠性和成本效益。一個優(yōu)秀的設計能夠在保證功能與性能的同時，降低維護成本和提高系統(tǒng)的可靠性。而狀態(tài)寄存器作為芯片設計中的關鍵組件，它記錄了系統(tǒng)或模塊的實時狀態(tài)信息。這些信息對于故障診斷、性能監(jiān)控和系統(tǒng)恢復至關重要。一個設計良好的狀態(tài)寄存器系統(tǒng)可以顯著提高系統(tǒng)的可維護性和可測試性。
扯完了回到咱們的正題可維可測寄存器設計上來。對于一個系統(tǒng)而言，這類寄存器出現(xiàn)目的是什么呢？無非就是反饋系統(tǒng)內部的狀態(tài)，輔助軟件或驅動等使用者計算時間和效率等各項指標，以及重要的在出現(xiàn)問題時能夠定位問題所在以及原因。畢竟不管是芯片已經流片回來了還是在FPGA上進行原型測試，看波形都是過于癡人說夢了，這個時候定位問題靠啥呢？只能靠我們聰明的大腦以及不睡覺通宵想，還有就是各種可維可測寄存器了。
做什么根據(jù)上面的討論，也就能夠明確可維可測寄存器（這個名字聽起來像法國人呢）的需求從哪里來了：
1.架構師以及設計者對系統(tǒng)內部狀態(tài)進行記錄的天然動力；
2.軟件驅動等使用者對問題定位以及功能性能檢測而提出的設計需求；
3.設計者出于甩鍋目的避免出問題時自己背鍋的考慮而添加的保護性狀態(tài)記錄；
明確需求來源之后再來討論下一個問題：什么時候來規(guī)劃可維可測寄存器？到目前為止個人一共經歷了三種情況：
1.所有寄存器包括狀態(tài)寄存器均在項目初期規(guī)劃完成，開發(fā)過程中按部就班將對應的信號接入寄存器單元，后期基本沒有改動順利交付；
2.在feature開發(fā)階段并未對所有可維可測狀態(tài)進行規(guī)劃，在代碼開發(fā)過程中設計人員識別需要哪些信號與狀態(tài)需要體現(xiàn)在狀態(tài)寄存器中，則伴隨代碼交付進程進行同步開發(fā)；
3.在EDA測試、FPGA測試、上板驅動測試等各個測試環(huán)節(jié)，根據(jù)測試反饋以及新的檢測需求在原有feature上進行狀態(tài)寄存器的補充；
從個人角度和體驗而言，我覺得可維可測寄存器越早規(guī)劃越在項目開始初期明確，在之后的開發(fā)中工作量以及反復迭代修改的代價是越小的。比如一個狀態(tài)開始并沒有規(guī)劃在寄存器中記錄，后面代碼開發(fā)時發(fā)現(xiàn)需要接出去，那么就需要①從信號所在的層級一層層的向上增加接口 ②寄存器描述文檔中增加寄存器 ③重新生成寄存器模型和RTL ④完成信號的互連修改。這么一套下來其實工作量不說多大但是還是有的，因此必然是越早規(guī)劃越好。但實際情況大家也都能理解，誰又能一上來就能想的面面俱到呢，尤其很多信號是在RTL實現(xiàn)的過程中才出現(xiàn)或者在軟件測試定位問題時才發(fā)現(xiàn)需要。剛剛所說的第一個項目之所以能做到項目初期完成全部可維可測寄存器規(guī)劃，也是因為其本身是繼承性項目有前代導入和商用的經驗了。
怎樣做OK鋪的差不多了，最后咱們來分門別類的聊一聊哪些信號應該或者可以做到可維可測狀態(tài)寄存器中。先聲明一下以下的內容都是繼續(xù)一個模塊或者系統(tǒng)級視角來看的，畢竟也沒交付過整芯片。
對外接口信號對外的接口信號是一定要放在狀態(tài)寄存器里的，典型的比如握手信號valid/ready、使能與反壓信號enable/xoff、選通信號sel等。這些信號可以在出現(xiàn)掛死等問題時排查問題出現(xiàn)在哪里，比如一個任務始終無法完成可以排查系統(tǒng)對外的數(shù)據(jù)通路接口，如果發(fā)現(xiàn)系統(tǒng)對外的awvalid/wvalid記錄寄存器為1而awready/wready記錄為0，則可以明確此時SOC對該系統(tǒng)進行了反壓導致數(shù)據(jù)無法寫出。
內部模塊間接口信號模塊間的接口記錄目的和上面差不多，真的甩不出去鍋了那就必須開始定位，定位顧名思義就是找到問題出在哪是什么問題，因此內部模塊間的接口狀態(tài)記錄就能夠派上用場了。
計數(shù)器和內部指針各種計數(shù)器根據(jù)其重要程度均可以加入可維可測寄存器中，很多計數(shù)器會在任務、指令等維度結束時清零，其他的也大多是有預期值的，因此在常規(guī)維護以及錯誤定位時，計數(shù)器信息大多能派上用場。而且在我們平時仿真環(huán)境的搭建時，end_of_check部分同樣也會對各種計數(shù)器進行結束檢查，道理都是一樣的。
內部的指針等各類ptr信號也是類似，在任務結束或者發(fā)生錯誤時大多有合理的狀態(tài)可以預期。比如說讀寫緩存模塊，如果一讀寄存器發(fā)現(xiàn)讀指針都跑到寫指針前面去了，那不掛死才是真的難了。
busy/emtpy狀態(tài)系統(tǒng)以及內部模塊的busy或者empty狀態(tài)，以及區(qū)分維度比如通道、任務、指令、讀寫的busy/empty狀態(tài)是非常能夠自證清白的，放到寄存器里絕對不吃虧。而且這類信號也不難做，一般就是把內部的enable/valid信號都或在一起再加入ptr/depth/cnt等輔助判定就可以。
FIFO空滿fifo接口、空滿、半空半滿和深度記錄（如果有的話）等信息都是適合上報寄存器的，作為結構里的數(shù)據(jù)緩沖中心，能夠如實的反饋上下游的很多信息。
總線相關記錄典型的比如當前的ostd值、數(shù)據(jù)讀寫響應最大延遲（ar-r、aw-b的時間）都可以記錄在案，當然了像總線超時那些本身一定要上報的就不多提了。此外還可以記錄很多與總線相關的信息，比如一段時間內握手拍數(shù)和反壓拍數(shù)來計算有效的帶寬甩鍋性能問題，記錄不同id的響應時間定位NOC問題等等。
任務與能效記錄任務或者指令的起始時間、完成時間、總耗時以及指令的耗時與切換時間用以檢測任務執(zhí)行情況。指令內運算單元的工作時間、數(shù)據(jù)讀寫時間來計算硬件效率�；蛘叨ㄏ虻挠涗浤承┤蝿盏暮臅r、事件的發(fā)生頻率（次數(shù)/觀測事件）、流量與credit功能等都是很常見的，這部分就根據(jù)架構師和軟件同事的意見規(guī)劃即可，本質上可以視為RTL功能的一部分。

系列文章入口——

【芯片設計】SoC 101（一）：緒論

【芯片設計】FIFO漫談（零）從無處不在的FIFO開始說起

【芯片設計】計算機體系結構（一）虛擬內存

【芯片設計】深入理解AMBA總線（零）緒論

【芯片設計】握手協(xié)議的介紹與時序說明

【芯片設計】復位那些小事 —— 復位消抖

【芯片設計】快速入門數(shù)字芯片設計（一）Introduction

【芯片驗證】UVM源碼計劃（零）下定決心讀源碼前的自測環(huán)節(jié)

【芯片設計】異步電路碎碎念（一）到底什么是異步電路

【芯片設計】從RTL到GDS（一）：Introduction

其他文章鏈接——

【芯片驗證】sva_assertion: 15道助力飛升的斷言練習