我用ChatGPT設計了一顆芯片

2023年12月27日 09:29:38 Hammond來源：微信公眾號：半導體行業觀察

　　編者按

　　過去一年多以來，ChatGPT引發的AI浪潮席卷全球。最近，本文作者也通過與 OpenAI 的 GPT-4 對話合作，實現了一個擁有 8 位微架構設計，其每個組件和每個信號都是由 GPT-4 的作者創建的。我們甚至在測試過程中發現 GPT-4 錯誤后對其進行了修補，并提供了對 ISA 本身設計的見解。

　　以下為文章正文：

　　今年早些時候，我(指代本文作者)正在紐約大學從事博士后工作，其中之一是探索Verilog 大型語言模型的使用。我們對使用 ChatGPT 等 LLM 來設計硬件的各種不同應用程序進行了基準測試，包括規范解釋、設計以及錯誤檢測和修復。我們是這個領域的先行者之一，早在 2020 年就開始使用 GPT-2 和 Verilog。

　　我立即對上述帖子產生了興趣，但由于實際流片的成本過高，我們一直使用 FPGA 和模擬。但是，模擬與現實之間總是存在差距，因此表明LLM和人工智能確實可以生產芯片可能對我們的研究領域來說是一個福音。我們能否使用免費流片的Tiny Tapeout 作為實現此目的的工具，并使用LLM不僅編寫 Verilog，還為真正的芯片設計 Verilog?

　　我與我的導師和其他幾位博士生進行了交談，我們集思廣益了一些想法。Tiny Tapeout 非常小，只有 1000 個標準單元左右，這意味著設計會受到很大限制，但我們都非常喜歡這個想法，特別是因為似乎還沒有人做到過，所以如果我們行動迅速，我們可能會能夠做到世界*!

　　所以，我們決定去做。但現在，還有很多其他事情需要考慮。鑒于設計空間如此之小，我們應該提交什么?還有其他問題。我們從我們自己之前的工作中知道，LLM可以編寫像 Verilog 這樣的硬件設計語言，但他們只是不太擅長，與 Python 等更流行的語言相比，語法或邏輯錯誤的發生率要高得多，這就是為什么我我的團隊已經為 Verilog 制作了自己的LLM的原因。

　　因此，我們需要決定，如果我們確實想使用LLM來制造芯片，(1)我們應該使用哪個LLM?(2)我們應該給它多大的幫助?(3)我們應該嘗試什么prompting strategy?

　　設計方法

　　我們首先決定了LLM。我們不會使用到目前為止我們一直在使用的“自動完成”風格的LLM，主要是 OpenAI 的 Codex 和 Salesforce CodeGen，而是使用更新、更華麗的“對話”/“指導”風格的法學碩士。我們選擇了 OpenAI 的 ChatGPT 3.5 和ChatGPT 4 版、Google 的 Bard 以及開源的 HuggingChat。

　　然后我們想出了兩種方法。*種方法是嘗試讓LLM在一種反饋循環中完成所有事情，從而為LLM提供一個規范，然后為該設計生成設計和測試。然后，人類將在模擬器 (iVerilog) 中運行測試和設計，然后將任何錯誤返回給LLM。

　　然而，我們從經驗中知道，LLM有時也相當愚蠢，并且可能會陷入循環，他們認為自己正在解決問題或改進輸出，而實際上他們只是迭代相同的數據。因此我們推測有時我們可能需要回饋“人類援助”。

　　通過一些初步實驗，我們決定了一個如下所示的初始流程：

　　理想情況下，人類不需要提供太多輸入，但這還有待觀察。

　　在硬件流片方面，我們的目標是 Tiny Tapeout 3，它將基于 Skywater 130nm。它有一些限制：前面提到的 1000 個標準單元，以及只有 8 位輸入(包括任何時鐘或復位)和 8 位輸出。Tiny Tapeout 使用 OpenLane，這意味著我們也僅限于可綜合的 Verilog-2001。

　　設計什么？

　　在這個實驗的早期階段，我們對與對話式LLM交互的標準化和(理想情況下)自動化流程的潛力感興趣，該流程將從規范開始并產生該設計的硬件描述語言。鑒于我們有 8 位輸入，我們決定使用其中 3 位來控制設計選擇多路復用器，以適應 8 個小型基準測試。如果這些進展順利，我們就會致力于更雄心勃勃的事情。

　　這些是我們提出的基準：

　　每個基準測試都有一個簡短的規范來描述它及其 I/O，以及正確的預期行為。

　　然后，紐約大學博士后Jason Blocklove 與四個選定的LLM(ChatGPT-3.5、ChatGPT-4、Bard 和 HuggingChat)坐在一起，執行前面描述的過程，引導LLM首先生成設計，然后生成測試平臺，然后將它們一起模擬，并反饋任何錯誤。

　　有時，談話中需要考慮特殊情況。由于模型在一次響應中可以給出的輸出量受到限制，文件或解釋通常會被中斷;在這些情況下，模型將提示“請繼續”。continue 之后的代碼通常從較早消息的最后一行之前開始，因此當代碼被復制到文件中進行編譯和模擬時，它會被編輯以形成一個內聚塊。然而，這個過程沒有添加額外的 HDL。同樣，有時響應中會包含讓用戶添加自己的代碼的注釋。如果這些注釋會阻止功能，例如留下不完整的值數組，則將重新生成響應，否則將保持原樣。

　　設計提示：

　　我們在這個環節設計的提示詞看起來像這樣：

　　在試過之后，我們發現返回的設計質量參差不齊，我們發現只有 ChatGPT-4 可以可靠地生成設計。以下是每個LLM的*個設計(移位寄存器)的示例：

　　1、首先我們看一下ChatGPT 4.0生成的反饋：

　　這個代碼是有用的。

　　2.我們再試一下ChatGPT 3.5，生成的結果如下：

　　同樣有用。

　　3.我們再試一下BARD，得出以下結果。

　　這是行不通的!請注意輸入定義中的錯誤。

　　4.再看一下HuggingChat

　　從以上代碼看來，它似乎已經瘋了。

　　測試平臺（Testbenches）

　　一旦我們有了設計，我們就必須提示建立一個測試平臺，在這里，我們將用以下提示詞：

　　Can you create a Verilog testbench for this design? It should be self-checking and made to work with iverilog for simulation and validation. If test cases should fail, the testbench should provide enough information that the error can be found and resolved.

　　以下是完整的對話事例：

　　1.我們先看一下ChatGPT 4.0生成的回復。我們首先問:

　　得到的回復如下：

　　以下是代碼的快速細分：

　　1.Define the `shift_register` module with the specified inputs and outputs.

　　2.Create an always block that responds to the rising edge of the clock (`posedge clk`) or the falling edge of the active-low reset (`negedge reset_n`).

　　3.Within the always block, check if the reset signal is low (`!reset_n`). If so, clear the 8-bit output register (`data_out <= 8'b0`).

　　4.If the reset signal is not low, check if the shift enable signal is high. If so, shift the data in the output register to the left and insert the new data bit at the least significant bit position (`data_out <= {data_out[6:0], data_in}`).

　　該設計滿足給定的規格，并提供具有所需輸入和輸出的 8 位移位寄存器。

　　接下來我又問：

　　然后得出下面的回答：

　　該測試平臺涵蓋四個測試用例：

　　簡單移位(shift)：將 1 移入寄存器并檢查輸出。

　　使用交替位進行移位：移位交替位模式并檢查輸出。

　　沒有shift_enable 的移位：驗證移位寄存器在沒有shift_enable 信號的情況下不會移位。

　　移位操作期間復位：檢查移位操作期間寄存器是否正確復位。

　　如果任何測試用例失敗，測試臺會提供錯誤消息。如果所有測試用例都通過。

　　接下來，我們又問了一個問題：

　　When running the simulation it gives the following output. Please provide fixed code.

　　Error: Test case 1 failed. Expected: 10000000, Received: 01111111

　　Error: Test case 2 failed. Expected: 10101010, Received: 01010101

　　Error: Test case 3 failed. Expected: 10101010, Received: 01010101

　　All test cases passed!

　　然后，我們得出以下回應：

　　Apologies for the confusion. It appears that the test cases are failing due to incorrect output expectations. I made a mistake in the test case expectations. Let's correct the test cases and update the testbench code:

　　我根據移位寄存器的正確行為更新了測試用例 1、2 和 3 的預期輸出。現在，當您運行模擬時，它應該顯示“所有測試用例已通過!” 沒有任何錯誤。而事實上，它也確實通過了，沒有任何錯誤!

　　基本結果

　　總體而言，只有 ChatGPT-3.5 和 ChatGPT-4 可以可靠地生成設計，因此我們最終只分析了這兩個模型，并將 Bard 和 HuggingChat 從我們的結果中排除。使用兩個 OpenAI 模型，我們完成了全套基準測試 3 次，得到了以下結果：

　　命名法（ Nomenclature）：

　　如果沒有報告錯誤，則設計通過，無需反饋 (NFN：no feedback necessary)。

　　相反，如果這些操作中的任何一個報告錯誤，它們就會反饋到模型中，并要求“請提供修復。”，稱為工具反饋 (TF：tool feedback)。

　　如果相同的錯誤或類型的錯誤出現三次，則用戶會給出簡單的人工反饋(SHF：simple human feedback)，通常是通過說明 Verilog 中的哪種類型的問題會導致此錯誤(例如聲明信號時的語法錯誤)。

　　如果錯誤繼續存在，則提供中等人類反饋 (MHF：moderate human feedback)，并向工具提供稍微更有針對性的信息以識別特定錯誤。

　　如果錯誤仍然存在，則提供高級人類反饋 (AHF：advanced human feedback)，該反饋依賴于準確指出位置錯誤是什么以及修復它的方法。一旦設計經過編譯和仿真且沒有失敗的測試用例，就被認為是成功的。

　　然而，如果高級反饋無法修復錯誤，或者用戶需要編寫任何 Verilog 來解決錯誤，則測試將被視為失敗。如果對話超過 25 條消息(符合 OpenAI 每 3 小時 ChatGPT-4 消息的速率限制)，則測試也被視為失敗。

　　由此可見，ChatGPT-4表現良好。大多數基準測試都通過了，其中大多數只需要工具反饋。ChatGPT-4 在測試平臺設計中最需要的人工反饋。

　　幾種故障模式是一致的，一個常見的錯誤是在設計或測試平臺中添加了 SystemVerilog 特定的語法。例如，它經常嘗試typedef為 FSM 模型創建狀態，或實例化向量數組，而這兩種情況在 Verilog-2001 中均不受支持。

　　總的來說，ChatGPT-4 生成的測試平臺并不是特別全面。盡管如此，通過隨附測試平臺的大多數設計也被認為是合規的。兩個不合規的“passes”是Dice Rollers，它不產生偽隨機輸出。

　　測試集 T1 中的Dice Rollers將在一次roll中輸出 2，然后在所有后續roll中僅輸出 1，無論選擇何種die。同時，Dice Roller T3 會改變值，但僅限于快速重復的一小部分(取決于所選die)之間。為了閉合設計循環，我們從 Tiny Tapeout 3 的 ChatGPT-4 對話中合成了測試集 T1，添加了由 ChatGPT-4 設計但未經測試的包裝器模塊(wrapper module )。整個設計需要 85 個組合邏輯單元、4 個二極管、44 個觸發器、39 個緩沖器和 300 個抽頭來實現。

　　ChatGPT-3.5的表現明顯比 ChatGPT-4 差，大多數對話都導致基準測試失敗，并且大多數通過自己測試平臺的對話都是不合規的。ChatGPT-3.5 的故障模式與 ChatGPT-4 相比不太一致，每次對話和基準測試之間都會引入各種各樣的問題。與 ChatGPT-4 相比，它需要更頻繁地修正設計和測試平臺。

　　觀察結果

　　只有 ChatGPT-4 能夠充分滿足編寫 Verilog 的目的，盡管它仍然需要人類反饋才能使大多數對話成功并符合給定的規范。修復錯誤時，ChatGPT-4 通常需要多條消息來修復小錯誤，因為它很難準確理解哪些特定的 Verilog 行會導致 iverilog 發出錯誤消息。它所添加的錯誤也往往會在對話之間經常重復出現。

　　ChatGPT-4 在創建功能測試平臺方面也比功能設計付出了更多努力。大多數基準測試幾乎不需要對設計本身進行修改，而是需要修復測試平臺。對于 FSM 來說尤其如此，因為該模型似乎無法創建一個測試平臺來正確檢查輸出，而無需有關狀態轉換和相應預期輸出的重要反饋。另一方面，ChatGPT-3.5 在測試平臺和功能設計方面都遇到了困難。

　　更復雜的東西：QTcore-A1

　　在基準測試期間，我是 ChatGPT-4 的學生，現在我已準備好接受更大的挑戰，并著手讓它為微控制器創建組件。我想知道非結構化對話是否可以提高模型的性能水平，使用一種共同的創造力來更快地編寫設計。

　　在這里我要指出的是，我是一位在小型玩具/學術處理器設計方面經驗豐富的工程師，曾在奧克蘭大學、紐約大學以及現在我所在的澳大利亞悉尼南威爾士大學教授該領域的學生多年。

　　這就是我想要 ChatGPT-4 構建的。知道我們面臨著極端的空間限制，我決定采用基于 8 位累加器的架構。使用馮諾依曼設計(共享程序和數據內存)可以節省額外的空間，然后將共享內存限制為僅 32 字節是我對合適的東西的猜測。

　　我決定用 ChatGPT-4 編寫每一行功能性 Verilog，但考慮到我們在驗證和測試平臺方面遇到的困難，我將生成這些內容并運行和解釋模擬等。

　　為什么要進行這種設計而不是 RISC-V 之類的設計?眾所周知，ISA 的開源處理器有很多實現，例如 RISC-V 和 MIPS。問題是，這意味著 GPT-4 在訓練期間已經看到了這些設計。對于這項工作，我不想簡單地探索 ChatGPT-4 發出其訓練過的數據的能力。相反，我想看看它在制作更新穎的東西時的表現。因此，我使用 ChatGPT-4 本身提供的奇怪 ISA 來引導模型進行全新的設計，我認為這與開源文獻中提供的內容完全不同。

　　開始，我問道：

　　Let us make a brand new microprocessor design together. We're severely constrained on space and I/O. We have to fit in 1000 standard cells of an ASIC, so I think we will need to restrict ourselves to an accumulator based 8-bit architecture with no multi-byte instructions. Given this, how do you think we should begin?

　　微處理器設計過程首先定義指令集架構 (ISA)，然后實現 ISA 所需的組件，最后將數據路徑中的這些組件與控制單元組合起來進行管理，通過模擬和測試來發現錯誤并進行修復。

　　構建對話

　　對話線程(Conversation threading:)：鑒于 ChatGPT-4 與其他 LLM 一樣具有固定大小的上下文窗口，我們假設提示模型的*方法是將較大的設計分解為子任務，每個子任務都有自己的“對話線程”界面。這使總長度保持在 16,000 個字符以下。當長度超過此值時，專有的后端方法會執行某種文本縮減，但其實現的細節很少。

　　由于 ChatGPT-4 不在線程之間共享信息，人類工程師會將相關信息從前一個線程復制到新的*條消息中，從而形成一個“基本規范”，慢慢地定義處理器�；疽幏蹲罱K包括 ISA、寄存器列表(累加器ACC、程序計數器PC、指令寄存器IR)、存儲體、ALU 和控制單元的定義，以及處理器在每個周期中應執行的操作的高級概述。本規范中的大部分信息由 ChatGPT-4 生成，并由人工復制/粘貼和輕微編輯。

　　主題(Topics)：每個線程一個主題對于處理器的早期設計階段效果很好(有一個例外，其中 ALU 是在與多周期處理器時鐘周期時序計劃相同的線程中設計的)。然而，一旦處理器進入模擬階段并在其上運行程序，我們就發現了規范和實現中的錯誤和錯誤。設計工程師沒有開始新的對話線程并重建先前的上下文，而是選擇在適當的情況下繼續先前的對話線程。我們在下面的流程圖中對此進行了說明，其中“Cont. T. ID”列指示他們是否“Continued”前一個線程(如果是，則為哪個線程)。

　　重新啟動（Restarts）：有時 ChatGPT-4 會輸出次優響應。如果是這樣，工程師有兩個選擇：(1) 繼續對話并推動它修復響應，或者 (2) 使用界面強制 ChatGPT-4“重新啟動”響應，即通過假裝先前的結果來重新生成結果答案從未出現。在這些之間進行選擇需要權衡并需要專業判斷：繼續對話允許用戶指定先前響應的哪些部分是好的或壞的，但重新生成將使整個對話變得更短、更簡潔(考慮到有限的上下文窗口，這是有價值的)尺寸)。

　　盡管如此，從結果表中的“# Restart”列可以看出，隨著我使用 ChatGPT-4 的經驗越來越豐富，重新啟動的次數趨于減少，與主題 08-18 相比，主題 00-07 的重新啟動次數為 57 次只有 8 次。在主題 04(控制信號規劃)中，單條消息的最高個體重啟次數為 10，其中包含以下消息：

　　This looks excellent. According to this list, please produce the module definition for a control unit in Verilog which could operate the processor datapath. Please comment the purpose of each I/O. If a signal is for controlling a multiplexer, please also comment what each possible value should correspond to in the datapath.

　　這是一個困難的提示，因為它要求提供具有大量細節的特定類型的輸出，但最終產生了令人滿意的答案，如下所示：

　　Bug修復：遇到錯誤后，我們會使用ChatGPT-4來修復它們。這里給出了一個例子。這是基于對話 15，并演示了如何解決移位寄存器原語中的錯誤。

　　我們發送以下對話：15 - SHIFT REGISTER BUG FIX

　　然后得到下面的回復：

　　然后我又說：Unfortunately, it doesn't work if the WIDTH is set to 1. Can you fix it?

　　之后得到了下面的回復：

　　現在，代碼將正確處理 WIDTH 設置為 1 的情況。

　　之后我繼續說：

　　Thanks! Can you also make it so scan_enable has a higher priority than the normal enable?

　　然后得到了下面的回復：

　　現在，“scan_enable”信號比“enable”信號具有更高的優先級。當兩個信號都為高電平時，移位寄存器將工作在掃描模式而不是正常模式。同時我們也證明了，這個錯誤修復也有效!

　　開發指令集架構（ISA）

　　下表列出了在對話 00 中與 ChatGPT-4 共同生成的 ISA(并在 10 中更新)：

　　這是一種相對簡單的基于累加器的設計，具有一些顯著的特征：

　　考慮到大小限制，內存訪問“帶有可變數據操作數的指令”僅使用 5 位來指定內存地址，這意味著處理器將被限制為** 32 字節內存。

　　只有一條具有立即數據編碼的指令。

　　這些指令使用完整的 256 種可能的字節編碼。

　　JSR指令使得實現子例程調用成為可能，盡管有點笨拙(沒有堆棧指針)。

　　分支指令有限制但很有用。向后跳過兩條指令可以實現高效輪詢(例如加載輸入，屏蔽相關位，然后檢查是否為 0)。向前跳過 3 條指令可以跳過 JMP 或 JSR 所需的指令。這些是經過多次迭代設計的，包括后來的修改(對話 10-12，“分支更新”)，它將向前跳轉從 2 條指令增加到 3 條，在模擬過程中我意識到我們無法輕松地在中編碼 JMP/JSR只需 2 條說明。

　　LDAR 指令允許對內存加載進行類似指針的取消引用。這使我們能夠有效地使用內存映射中的常量表(在對話 17 中添加)將二進制值轉換為 7 段顯示器的 LED 模式。

　　當嘗試在其中編寫程序時，感覺就像是用于 PIC 微控制器系列的程序的變體。ChatGPT-4 實際上也為我編寫了匯編程序，我可以做得更好(它確實用起來很糟糕，但它確實有效 - 請參閱對話 09)。

　　我將該處理器的實現稱為 QTCore-A1(cutie core)。

　　這是最終產生的數據路徑(控制信號用虛線表示 - 使用摩爾型多周期(moore-type multicycle ) FSM 來控制它們)。在設計處理器時，我確保每個寄存器也通過掃描鏈連接(也是由 ChatGPT-4 設計的!)。這意味著我可以在實現后對設計進行編程，這也是我在模擬期間加載測試程序的方式。

　　我嘗試使用 OpenLane 進行合成，但糟糕的是，該設計不適合 1000 個標準單元(standard cells)!最簡單的事情就是不斷調整內存，我一遍又一遍地這樣做，直到我最終達到了神奇的數字，并設法獲得了僅 17 字節的數據和指令內存組合。

　　經過 OpenLane 綜合后，GDS 如下所示：

　　我編寫了一些測試程序，很快意識到我需要一些重復出現的常量值。玩了之后我還發現，內存映射中的常量值并沒有寄存器占用那么多空間!因此，我設法將一些常量輔助值(包括“1”和“0”)放入內存映射中。

　　這意味著我可以用該死的匯編語言為我下載到 FPGA (CMod-A7) 的處理器編寫這個小程序。盡管我還必須實現一個編程器，我使用的是 STM32!

　　在實際測試中，該設計是工作的。所以我很高興，它在模擬和 FPGA 上都能工作，所以我很高興地將它發送到 Tiny Tapeout進行流片。

　　更多設計細節

　　該項目于 2023 年 6 月 2 日上線，并(相對)受到了很多關注!EDA 領域的許多不同公司也與我們聯系，其中包括一些您肯定聽說過的公司。

　　值得一提的是，我們還決定利用這個設計去參賽，因為該參賽對內核有一些規定。

　　所以在QTcore-A1上，我們修改了微控制器，以便它能夠占用平臺中更大的可用區域(僅使用一個可用空間的一部分)。

　　這就碰到了一些主要的問題：

　　盡管這是基于 OpenLane 的，就像 Tiny Tapeout 一樣，但它是一個更加手動和復雜的過程，并且沒有一個簡單的基于 Github 操作的工作流程。我必須在我的筆記本電腦上安裝很多東西!

　　模擬需要比 Tiny Tapeout 更加穩健，并且考慮到您的設計需要與 caravel 核心一起進行驗證，因此需要更長的時間。我最基本的模擬仍然需要超過 45 分鐘，而 Tiny 的模擬大約需要 10 秒流片。

　　這是一場競賽，參賽作品的評判標準是它們的文檔記錄、可使用性、對開源的貢獻等。所以我還必須確保這方面的一切都很好!

　　然后，我決定讓 ChatGPT-4 對 QTCore-A1 進行以下更改。首先，內存大小將升級為256字節共享指令/數據內存，分為16字節頁面;其次，我會添加一些外設：一個 16 位定時器、一些 I/O 端口，并且考慮到我的日常工作是硬件安全研究員，我還決定添加 2 個八位“內存執行保護”控制寄存器為 16 個頁面中的每個頁面提供“執行”位，并更新原始的、被詛咒的分支邏輯。

　　新的指令集架構：

　　當我提出設計變更時，ChatGPT 最終選擇了這種 ISA：

　　▪️具有可變數據操作數的指令

　　▪️即時數據操作指令

　　▪️控制/狀態寄存器操作指令

　　▪️固定控制和分支指令

　　▪️變量操作數分支指令

　　▪️數據操作指令

　　▪️數據路徑

　　從這個設計可以看到，里面有了很多的變化!例如觀察現在有一個段寄存器，它與部分指令連接在一起，以解碼具有可變數據操作數的指令的地址。

　　以下是完整的詳細信息：

　　控制單元：用于驅動處理器的2周期FSM(3位one-hot編碼狀態寄存器)

　　程序計數器：8位寄存器，包含程序的當前地址

　　段寄存器：4位寄存器，包含用于數據存儲器指令的當前段

　　指令寄存器：8位寄存器，包含當前要執行的指令

　　累加器：8位寄存器，用于數據存儲、操作和邏輯

　　存儲體：256 個 8 位寄存器，用于存儲指令和數據。

　　控制和狀態寄存器：8 個 8 位寄存器，用于特殊功能，包括定時器、I/O、內存保護、發送中斷以及接收和發送信號到更大的 Caravel 處理器。

　　控制/狀態寄存器 (CSR) 及其地址：

　　SEGEXE_L (000)：8 位 - 表示指定為可執行文件的內存段的下半部分。寄存器中的每一位對應內存空間下半部分的一個段。如果某個位設置為 1，則相應的段被標記為可執行。

　　SEGEXE_H (001)：8 位 - 表示指定為可執行文件的內存段的高半部分。寄存器中的每一位對應內存空間上半部分的一個段。如果某個位設置為 1，則相應的段被標記為可執行。

　　IO_IN (010)：8 位 - UART(或任何通用 I/O 設備)操作的輸入寄存器。這用于從外部設備讀取數據。

　　IO_OUT (011)：8 位 - UART(或任何通用 I/O 設備)操作的輸出寄存器。這用于將數據寫入外部設備。

　　CNT_L (100)：8 位 - 16 位計數器寄存器的低 8 位。這可用于存儲計數值的下半部分，可用于計時操作或編程中的循環等。

　　CNT_H (101)：8 位 - 16 位計數器寄存器的高 8 位。這可用于存儲計數值的上半部分，類似于 CNT_L 寄存器。

　　STATUS_CTRL (110)：8 位 - 用于保存 CPU 中不同操作狀態的控制寄存器。這些位是：{SIG_OUT[7:2], CNT_EN[1], IRQ_OUT[0]}。SIG_OUT 位用于向較大的 Caravel 處理器發送信號(6 位)。CNT_EN 位用于使能計數器。IRQ_OUT 位用于向較大的 Caravel 處理器發送中斷。

　　SIG_IN (111)：8 位 - 這里的 8 位可以來自更大的 Caravel 處理器。這可用于向 CPU 發送信號，例如作業開始、作業結束等。

　　使用匯編程序的示例編程

　　GPT-4 生成的匯編器簡化了為 QTCore-C1 編寫匯編程序的過程。

　　向匯編器提供程序：

　　程序以以下格式呈現[address]: [mnemonic] [optional operand]

　　有一個特殊的元指令稱為 DATA，它后面跟著一個數字。如果使用的話，只需將該號碼放在該地址即可。

　　程序不能超過內存的大小(在QTCore-C1中，這是256字節)。

　　存儲器包含指令和數據。

　　示例程序：

　　在此程序中，觀察我們如何通過 SETSEG 讀寫 I/O、定時器和數據存儲器。我們還通過 CSW 將內存段設置為可執行，然后跳轉到不可執行的段以使處理器崩潰。如圖所示：

　　然后，我們終于拿到了這個芯片。

　　基本測試和圣誕節 LED 顯示屏！

　　我需要測試的*件事是我實際上可以與我的芯片對話，就像我在模擬中所做的那樣。我啟動了我為原始競賽截止日期編寫的程序，并將其放入 Caravel，然后意識到它僅根據模擬器檢查值“通過” - 即處理器實際上沒有發出任何東西!因此，我必須更新 RISC-V 程序以支持 UART，幸虧有 caravel 文檔，這非常簡單。

　　經過一次毀滅性的實驗，沒有發生任何事情，我認為芯片無法工作，我意識到我需要執行一個額外的配置步驟來啟用 caravel 用戶空間叉骨總線，然后我運行程序，終于正常工作了。