我用ChatGPT設(shè)計了一顆芯片

　　編者按

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

　　以下為文章正文：

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

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

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

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

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

　　設(shè)計方法

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

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

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

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

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

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

　　設(shè)計什么？

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

　　這些是我們提出的基準(zhǔn)：

　　每個基準(zhǔn)測試都有一個簡短的規(guī)范來描述它及其 I/O，以及正確的預(yù)期行為。

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

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

　　設(shè)計提示：

　　我們在這個環(huán)節(jié)設(shè)計的提示詞看起來像這樣：

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

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

　　這個代碼是有用的。

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

　　同樣有用。

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

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

　　4.再看一下HuggingChat

　　從以上代碼看來，它似乎已經(jīng)瘋了。

　　測試平臺（Testbenches）

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

　　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生成的回復(fù)。我們首先問:

　　得到的回復(fù)如下：

　　以下是代碼的快速細(xì)分：

　　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}`).

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

　　接下來我又問：

　　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.

　　然后得出下面的回答：

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

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

　　使用交替位進(jìn)行移位：移位交替位模式并檢查輸出。

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

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

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

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

　　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!

　　然后，我們得出以下回應(yīng)：

　　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:

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

　　基本結(jié)果

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

　　命名法（ Nomenclature）：

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

　　相反，如果這些操作中的任何一個報告錯誤，它們就會反饋到模型中，并要求“請?zhí)峁┬迯?fù)。”，稱為工具反饋 (TF：tool feedback)。

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

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

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

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

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

　　幾種故障模式是一致的，一個常見的錯誤是在設(shè)計或測試平臺中添加了 SystemVerilog 特定的語法。例如，它經(jīng)常嘗試typedef為 FSM 模型創(chuàng)建狀態(tài)，或?qū)嵗�化向量�?shù)組，而這兩種情況在 Verilog-2001 中均不受支持。

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

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

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

　　觀察結(jié)果

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

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

　　更復(fù)雜的東西：QTcore-A1

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

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

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

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

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

　　開始，我問道：

　　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?

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

　　構(gòu)建對話

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

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

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

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

　　盡管如此，從結(jié)果表中的“# Restart”列可以看出，隨著我使用 ChatGPT-4 的經(jīng)驗越來越豐富，重新啟動的次數(shù)趨于減少，與主題 08-18 相比，主題 00-07 的重新啟動次數(shù)為 57 次只有 8 次。在主題 04(控制信號規(guī)劃)中，單條消息的最高個體重啟次數(shù)為 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.

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

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

　　我們發(fā)送以下對話：15 - SHIFT REGISTER BUG FIX

　　然后得到下面的回復(fù)：

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

　　之后得到了下面的回復(fù)：

　　現(xiàn)在，代碼將正確處理 WIDTH 設(shè)置為 1 的情況。

　　之后我繼續(xù)說：

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

　　然后得到了下面的回復(fù)：

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

　　開發(fā)指令集架構(gòu)（ISA）

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

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

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

　　只有一條具有立即數(shù)據(jù)編碼的指令。

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

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

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

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

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

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

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

　　我嘗試使用 OpenLane 進(jìn)行合成，但糟糕的是，該設(shè)計不適合 1000 個標(biāo)準(zhǔn)單元(standard cells)!最簡單的事情就是不斷調(diào)整內(nèi)存，我一遍又一遍地這樣做，直到我最終達(dá)到了神奇的數(shù)字，并設(shè)法獲得了僅 17 字節(jié)的數(shù)據(jù)和指令內(nèi)存組合。

　　經(jīng)過 OpenLane 綜合后，GDS 如下所示：

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

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

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

　　更多設(shè)計細(xì)節(jié)

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

　　值得一提的是，我們還決定利用這個設(shè)計去參賽，因為該參賽對內(nèi)核有一些規(guī)定。

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

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

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

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

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

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

　　新的指令集架構(gòu)：

　　當(dāng)我提出設(shè)計變更時，ChatGPT 最終選擇了這種 ISA：

　　▪️具有可變數(shù)據(jù)操作數(shù)的指令

　　▪️即時數(shù)據(jù)操作指令

　　▪️控制/狀態(tài)寄存器操作指令

　　▪️固定控制和分支指令

　　▪️變量操作數(shù)分支指令

　　▪️數(shù)據(jù)操作指令

　　▪️數(shù)據(jù)路徑

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

　　以下是完整的詳細(xì)信息：

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

　　程序計數(shù)器：8位寄存器，包含程序的當(dāng)前地址

　　段寄存器：4位寄存器，包含用于數(shù)據(jù)存儲器指令的當(dāng)前段

　　指令寄存器：8位寄存器，包含當(dāng)前要執(zhí)行的指令

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

　　存儲體：256 個 8 位寄存器，用于存儲指令和數(shù)據(jù)。

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

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

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

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

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

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

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

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

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

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

　　使用匯編程序的示例編程

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

　　向匯編器提供程序：

　　程序以以下格式呈現(xiàn)[address]: [mnemonic] [optional operand]

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

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

　　存儲器包含指令和數(shù)據(jù)。

　　示例程序：

　　在此程序中，觀察我們?nèi)绾瓮ㄟ^ SETSEG 讀寫 I/O、定時器和數(shù)據(jù)存儲器。我們還通過 CSW 將內(nèi)存段設(shè)置為可執(zhí)行，然后跳轉(zhuǎn)到不可執(zhí)行的段以使處理器崩潰。如圖所示：

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

　　基本測試和圣誕節(jié) LED 顯示屏！

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

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

　　很難描述在我面前有一塊我參與設(shè)計的工作硅片是多么令人驚奇，特別是因為我以前從未真正設(shè)計過任何流片。如果沒有像 ChatGPT 這樣的LLM來激勵我去嘗試，我也許也不會這么做。

　　我又做了一些實驗，發(fā)現(xiàn)芯片可能存在一些問題，包括運行 HALT 命令后不想重新啟動的問題(很煩人，因為我喜歡 HALT 來指示程序已完成運行!)。

　　我最終創(chuàng)建了一個簡單的計數(shù)器程序，與 caravel 處理器握手，類似于之前的 LED 閃爍程序，然后，我們終于得到了節(jié)日的圣誕樹盛宴。

　　我們的 QTCore-C1 設(shè)計是一個基于 8 位累加器的架構(gòu)，可以充當(dāng)主 Caravel 核心的一種可預(yù)測協(xié)處理器。它可以執(zhí)行基本的數(shù)學(xué)和邏輯運算，與多個輸入/輸出線交互以及使用內(nèi)部計數(shù)器測量時間，并且可以向主處理器發(fā)送和接收值以及中斷請求。

　　自 2020 年以來，我一直與硬件LLM合作，因為我相信它們在簡化、民主化和加速硬件開發(fā)方面具有巨大潛力，特別是與 OpenLane 和 Caravel 提供的開源設(shè)計流程結(jié)合使用時。

　　我也不認(rèn)為我是*持這種觀點的人。近幾個月來，RapidSilicon 宣布了 RapidGPT，NVIDIA 推出了 ChipNeMo，Cadence 宣布了 JedAI，Synopsys.AI 也已推出。所有這些都是現(xiàn)實世界的商業(yè)企業(yè)，旨在將LLM帶入硬件領(lǐng)域。

　　我對接下來發(fā)生的事情感到非常興奮。