摘要

現(xiàn)代硬件設(shè)計(jì)始于以自然語言提供的規(guī)范。然后，在綜合電路元件之前，硬件工程師將其翻譯成適當(dāng)?shù)挠布枋稣Z言（HDL），例如Verilog。自動翻譯可以減少工程過程中的人為錯誤。但是，直到最近，人工智能（AI）才展示出基于機(jī)器的端到端設(shè)計(jì)翻譯的能力。商業(yè)上可用的指令調(diào)優(yōu)的大型語言模型（LLM），如OpenAI的ChatGPT和谷歌的Bard，聲稱能夠用各種編程語言生成代碼；但對它們進(jìn)行硬件檢查的研究仍然不足。因此，在本研究中，我們探討了在利用LLM的這些最新進(jìn)展進(jìn)行硬件設(shè)計(jì)時所面臨的挑戰(zhàn)和機(jī)遇。我們使用一整套包含8個代表性的基準(zhǔn)，檢查了在為功能和驗(yàn)證目的生成Verilog時，最先進(jìn)的LLM的能力和局限性。考慮到LLM在交互使用時表現(xiàn)最好，我們隨后進(jìn)行了一個更長的完全對話式案例研究，該研究中LLM與硬件工程師共同設(shè)計(jì)了一種新穎的基于8位累加器的微處理器架構(gòu)。該處理器采用Skywater 130nm工藝，這意味著這些“Chip-Chat”實(shí)現(xiàn)了我們認(rèn)為是世界上第一個完全由人工智能編寫的用于流片的HDL。

1介紹

A.硬件設(shè)計(jì)趨勢

隨著數(shù)字設(shè)計(jì)的能力和復(fù)雜性不斷增長，集成電路（IC）計(jì)算機(jī)輔助設(shè)計(jì)（CAD）中的軟件組件在整個電子設(shè)計(jì)自動化流程中都采用了機(jī)器學(xué)習(xí)（ML）。在傳統(tǒng)方法試圖對每個過程進(jìn)行形式化建模的情況下，基于ML的方法側(cè)重于識別和利用可推廣的高級特征或模式——這意味著ML可以增強(qiáng)甚至取代某些工具。盡管如此，IC CAD中的ML研究往往側(cè)重于后端過程，如邏輯綜合、布局、走線和屬性估計(jì)。在這項(xiàng)工作中，我們探索了將一種新興類型的ML模型應(yīng)用于硬件設(shè)計(jì)過程的早期階段時的挑戰(zhàn)和機(jī)遇：硬件描述語言（HDL）本身的編寫。

B.自動化硬件描述語言（HDL）

雖然硬件設(shè)計(jì)是用規(guī)范語言（HDL）表示的，但它們實(shí)際上是以自然語言提供的規(guī)范（例如英語需求文件）開始設(shè)計(jì)生命周期的。將這些轉(zhuǎn)換為適當(dāng)?shù)腍DL（例如Verilog）的過程必須由硬件工程師完成，這既耗時又容易出錯。使用高級綜合工具等替代途徑可以使開發(fā)人員能夠用C等高級語言指定功能，但這些方法是以犧牲硬件效率為代價的。這激發(fā)了對基于人工智能（AI）或ML的工具的探索，使其作為將規(guī)范轉(zhuǎn)換為HDL的替代途徑。

這種機(jī)器翻譯應(yīng)用程序的候選者來自GitHub Copilot等商業(yè)產(chǎn)品推廣的大型語言模型（LLM）。LLM聲稱可以用多種語言生成代碼，以用于各種目的。盡管如此，它們還是更加專注于軟件，這些模型的基準(zhǔn)測試針對Python等語言對它們進(jìn)行評估，而不是針對硬件領(lǐng)域的需求。因此，硬件設(shè)計(jì)社區(qū)的使用仍然落后于軟件領(lǐng)域。盡管“自動完成”風(fēng)格模型的基準(zhǔn)測試步驟已經(jīng)開始出現(xiàn)在文獻(xiàn)中，但最新的LLM，如OpenAI的ChatGPT和谷歌的Bard，為其功能提供了一個不同的“對話式”聊天界面。

因此，我們提出了以下問題：將這些工具集成到HDL開發(fā)過程中的潛在優(yōu)勢和障礙是什么（圖1）？我們做了兩個對話實(shí)驗(yàn)。第一個實(shí)驗(yàn)涉及預(yù)定義的對話流和一系列基準(zhǔn)挑戰(zhàn)（第三節(jié)），而第二個實(shí)驗(yàn)涉及開放式的“自由聊天”方法，LLM在更大的項(xiàng)目中擔(dān)任聯(lián)合設(shè)計(jì)師（第四節(jié)）。

圖1 會話LLM可以用于迭代設(shè)計(jì)硬件嗎？

為了理解這項(xiàng)新興技術(shù)的重要性，進(jìn)行這樣的研究至關(guān)重要。ChatGPT在醫(yī)療保健、軟件和教育等各個領(lǐng)域也在進(jìn)行類似的研究。我們對會話LLM對硬件設(shè)計(jì)的影響的調(diào)查是很有必要的。

C.貢獻(xiàn)

本研究的貢獻(xiàn)包括：

對會話LLM在硬件設(shè)計(jì)中的使用進(jìn)行了首次研究。

制定基準(zhǔn)以評估LLM在功能硬件開發(fā)和驗(yàn)證方面的能力。

利用ChatGPT-4對硬件中復(fù)雜應(yīng)用程序的端到端協(xié)同設(shè)計(jì)進(jìn)行觀察性研究。

首次使用人工智能為流片編寫完整的HDL，實(shí)現(xiàn)了一個重要的里程碑。

為在硬件相關(guān)任務(wù)中有效利用LLM提供實(shí)用建議。

開源：所有基準(zhǔn)測試、流片工具鏈腳本、生成的Verilog和LLM對話日志都在Zenodo上提供。

2背景及相關(guān)工作

A.大型語言模型 (LLMs)

大型語言模型（LLM）是用Transformer體系結(jié)構(gòu)構(gòu)建的。早期的例子包括BERT和GPT-2，但直到GPT-3系列模型，這些模型的相對能力才變得明顯。其中包括Codex，它擁有數(shù)十億的學(xué)習(xí)參數(shù)，并在數(shù)百萬個開源軟件存儲庫上進(jìn)行了訓(xùn)練。在最先進(jìn)的技術(shù)中，有幾十種LLM（包括開源、非開源和商業(yè)），可用于通用和特定任務(wù)的應(yīng)用程序。

盡管如此，所有LLM都有一些共同點(diǎn)。它們都充當(dāng)“可伸縮序列預(yù)測模型”，這意味著給定一些“輸入提示”，它們將輸出該提示的“最有可能”的延續(xù)（將其視為“智能自動完成”）。對于此I/O，它們使用令牌，即使用字節(jié)對編碼指定的常見字符序列。這很有效，因?yàn)長LM具有固定的上下文大小，這意味著它們可以提取比通過對字符進(jìn)行操作更多的文本。對于OpenAI的模型，每個令牌代表大約4個字符，其上下文窗口的大小最多可達(dá)8000個令牌（這意味著它們可以支持大約16000個字符的I/O）。

B.用于硬件設(shè)計(jì)的大型語言模型

Pearce等人首次探索了在硬件領(lǐng)域使用LLM。他們在綜合生成的Verilog片段上微調(diào)了GPT-2模型（他們稱之為DAVE），并對“本科生級別”任務(wù)的模型輸出進(jìn)行了詞法評估。然而，由于訓(xùn)練數(shù)據(jù)有限，該模型無法推廣到不熟悉的任務(wù)。Thakur等人擴(kuò)展了這一想法，探索了如何嚴(yán)格評估生成Verilog的模型性能，以及使用不同的策略來訓(xùn)練Verilog編寫模型。其他工作探究了這些模型的含義：GitHub Copilot研究了Verilog代碼中6種類型硬件錯誤的發(fā)生率，當(dāng)探討是否可以使用Codex模型實(shí)現(xiàn)自動錯誤修復(fù)時，他們還包括Verilog中的兩個硬件CWE。

在這個行業(yè)，人們對此的興趣也越來越強(qiáng)烈：Efabless最近啟動了人工智能生成設(shè)計(jì)大賽，評委來自高通和新思等公司。RapidSilicon等新公司正在推廣RapidGPT等即將推出（但尚未發(fā)布）的工具，這些工具將在該領(lǐng)域發(fā)揮作用。

C.訓(xùn)練調(diào)優(yōu)的“對話”模型

最近，一種新的訓(xùn)練方法——“基于人類反饋的強(qiáng)化學(xué)習(xí)（RLHF）”被應(yīng)用于LLM。通過將其與特定意圖的標(biāo)記數(shù)據(jù)相結(jié)合，可以生成更能遵循用戶意圖的指令調(diào)優(yōu)模型。如果以前的LLM側(cè)重于“自動完成”，則可以對其進(jìn)行“遵循說明”的訓(xùn)練。還有一些研究提出的方法不需要人類反饋，然后可以對它們進(jìn)行微調(diào)，以便更好地關(guān)注對話式的互動。ChatGPT（包括ChatGPT-3.5和ChatGPT-4版本）、Bard和HuggingChat等模型都使用這些技術(shù)進(jìn)行了訓(xùn)練。它們?yōu)橛布I(lǐng)域的工作提供了一個令人興奮的新的潛在接口。然而，據(jù)作者所知，目前還沒有人深入探索過這種應(yīng)用。

3探索“腳本化”基準(zhǔn)

A.概覽

從本質(zhì)上講，有無數(shù)種方法可以與會話模型“聊天”。為了探索使用會話LLM實(shí)現(xiàn)“標(biāo)準(zhǔn)化”和“自動化”流程的潛力，我們在一系列基準(zhǔn)上定義了一個嚴(yán)格的“腳本化”會話流程。然后，我們使用一致的指標(biāo)評估一系列LLM，根據(jù)通過附帶testbench所需的指令水平來確定對話的相對成功或失敗。然而，盡管對話流在結(jié)構(gòu)上保持相同，但它在測試運(yùn)行之間固有地存在一些變化，這是基于評估者需要決定（a）每個步驟中需要什么反饋以及（b）如何標(biāo)準(zhǔn)化人工反饋。

B.方法

對話流程：圖2詳細(xì)介紹了與LLM進(jìn)行對話以創(chuàng)建硬件基準(zhǔn)的一般流程。圖3和圖4中詳細(xì)說明的初始提示首先提供給該工具。然后對輸出設(shè)計(jì)進(jìn)行視覺評估，以確定其是否符合基本設(shè)計(jì)規(guī)范。如果設(shè)計(jì)不符合規(guī)范，則會以相同的提示重新生成最多五次，之后如果仍然不符合規(guī)范則會失敗。

圖2 簡化的LLM對話流程圖

圖3 8位移位寄存器：設(shè)計(jì)提示

圖4 testbench提示

設(shè)計(jì)和testbench編寫完成后，將使用Icarus Verilog（iverilog）進(jìn)行編譯，如果編譯成功，則進(jìn)行模擬。如果沒有報(bào)告錯誤，則設(shè)計(jì)通過而不需要反饋（NFN）。如果這些操作中的任何一個報(bào)告了錯誤，它們會被反饋到模型中，并被要求“請?zhí)峁┬迯?fù)”，稱為工具反饋（TF）。如果相同的錯誤或錯誤類型出現(xiàn)三次，則用戶通常會給出簡單的人工反饋（SHF），說明Verilog中的哪種類型的問題會導(dǎo)致此錯誤（例如，聲明信號時的語法錯誤）。如果錯誤持續(xù)存在，則會給出適度的人工反饋（MHF），并向工具提供稍微更有針對性的信息來識別特定錯誤，如果錯誤持續(xù)，則會提供高級人工反饋（AHF），該反饋依賴于準(zhǔn)確指出錯誤的位置和修復(fù)錯誤的方法。一旦設(shè)計(jì)在沒有失敗測試用例的情況下進(jìn)行編譯和模擬，它則被認(rèn)為是成功的。然而，如果高級反饋無法修復(fù)錯誤，或者用戶需要編寫任何Verilog來解決錯誤，則該測試被視為失敗。如果會話超過25條消息，與每3小時ChatGPT-4消息的OpenAI速率限制相匹配，則該測試也被視為失敗。

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

功能提示：這個一致且對話風(fēng)格的提示構(gòu)建如下：“我正在嘗試為[測試名稱]創(chuàng)建一個Verilog模型。”然后模型將提供規(guī)范，定義輸入和輸出端口，以及所需的任何進(jìn)一步細(xì)節(jié)（例如序列生成器將產(chǎn)生的預(yù)期序列），然后是備注“我該如何編寫符合這些規(guī)范的設(shè)計(jì)？”。圖3顯示了8位移位寄存器的設(shè)計(jì)提示，該寄存器被用作每個LLM的初始評估。

驗(yàn)證提示：對于所有設(shè)計(jì)，testbench提示（圖4）保持不變，因?yàn)檎埱髏estbench不需要包含關(guān)于創(chuàng)建的設(shè)計(jì)的任何附加信息。這是因?yàn)閠estbench提示將遵循LLM生成的設(shè)計(jì)，這意味著他們可以考慮所有現(xiàn)有的會話信息。它要求所有testbench都與iverilog兼容，以便于模擬和測試，并有助于確保只使用Verilog-2001標(biāo)準(zhǔn)。

C.現(xiàn)實(shí)世界的設(shè)計(jì)約束

這項(xiàng)工作旨在研究會話生成大語言模型在現(xiàn)實(shí)世界硬件設(shè)計(jì)中的應(yīng)用，該模型具有綜合、預(yù)算和流片輸出限制。因此，在這個項(xiàng)目中，我們瞄準(zhǔn)了現(xiàn)實(shí)世界平臺Tiny Tapeout 3。這增加了設(shè)計(jì)的限制：具體來說，是對IO的限制——每個設(shè)計(jì)只允許8位輸入和8位輸出。由于標(biāo)準(zhǔn)挑戰(zhàn)基準(zhǔn)測試的目標(biāo)是同時實(shí)現(xiàn)幾個，因此為多路復(fù)用器保留了3位輸入，以選擇哪個基準(zhǔn)測試的輸出。這意味著每個基準(zhǔn)只能包括5位輸入，包括時鐘和重置。

Tiny Tapeout工具流依賴于OpenLane，這意味著我們僅限于可合成的Verilog-2001 HDL。相對較小的區(qū)域雖然不是挑戰(zhàn)基準(zhǔn)的主要問題，但確實(shí)影響了處理器的組件和接口（第四節(jié)）。

D.挑戰(zhàn)基準(zhǔn)

針對這一挑戰(zhàn)的基準(zhǔn)測試旨在深入了解不同LLM可以編寫的硬件級別。目標(biāo)功能通常在硬件中實(shí)現(xiàn)，并且通常在本科生數(shù)字邏輯課程的水平上教授。基準(zhǔn)見表一。

表一 基準(zhǔn)描述

一些基準(zhǔn)測試在初始設(shè)計(jì)之外有自己的特定要求，以幫助檢查LLM如何處理不同的設(shè)計(jì)約束。序列生成器和檢測器都被分別賦予了它們的特定模式來生成或檢測，ABRO使用一個熱態(tài)編碼，LFSR具有特定的初始狀態(tài)和抽頭位置。其他基準(zhǔn)測試，如移位寄存器，保持最低限度的描述性，以注意在約束較少的情況下，模型的輸出是否存在任何模式。

E.模型評估：度量

我們評估了四種不同的會話LLM在創(chuàng)建用于硬件設(shè)計(jì)的Verilog方面的熟練程度，如表II所示。作為初始測試，這些模型中的每一個都被提示了8位移位寄存器基準(zhǔn)提示，目的是繼續(xù)進(jìn)行第III-B節(jié)中的會話流程。每個LLM對設(shè)計(jì)提示的響應(yīng)如圖5、6、7和8所示。

表二 已評估的會話LLM

圖5 來自ChatGPT-4的8位移位寄存器嘗試。

圖6 來自ChatGPT-3.5的8位移位寄存器嘗試。

圖7 巴德的8位移位寄存器嘗試。第4行的輸入太寬。

圖8 HuggingChat的8位“移位寄存器”

（截?cái)啵袷交?/p>

這些測試中的每一項(xiàng)都被視為完整會話流的開始，因此，盡管兩個ChatGPT模型都能夠滿足規(guī)范并開始通過設(shè)計(jì)流，但Bard和HuggingChat都未能滿足規(guī)范的初始標(biāo)準(zhǔn)。根據(jù)計(jì)劃的對話流程，對Bard和HuggingChat最初提示的響應(yīng)被重新生成了五次，但都一再失敗。Bard一直未能滿足給定的設(shè)計(jì)規(guī)范，HuggingChat的Verilog輸出在模塊定義后的語法上也不正確。圖7和圖8代表了這兩個模型的最終嘗試。

鑒于Bard和HuggingChat在最初的Challenge Benchmark提示中表現(xiàn)不佳，我們決定繼續(xù)進(jìn)行僅針對ChatGPT-4和ChatGPT-3.5的全套測試，這兩個測試都能夠持續(xù)進(jìn)行對話流。對于整套基準(zhǔn)測試，我們運(yùn)行了三次這些對話，因?yàn)長LM是不確定的，并且能夠?qū)ο嗤妮斎胩崾咀龀霾煌捻憫?yīng)。因此，這種重復(fù)提供了一個基本的衡量標(biāo)準(zhǔn)，即他們能夠在多大程度上一致地創(chuàng)建不同的基準(zhǔn)和testbench，以及在給定相同初始提示的情況下，不同的運(yùn)行在實(shí)現(xiàn)中會有多大差異。

合規(guī)與不合規(guī)設(shè)計(jì)：考慮到語言模型創(chuàng)建了功能代碼和驗(yàn)證testbench，當(dāng)設(shè)計(jì)“通過”testbench時，它可能仍然“不符合”原始規(guī)范。因此，我們將每個結(jié)果總體上標(biāo)記為“符合”或“不符合”。

F.對話示例

圖9為移位寄存器T1提供了與ChatGPT-4對話的剩余部分的示例。為了簡潔起見，我們刪除了響應(yīng)中不相關(guān)的部分。這個對話流遵循圖3中的初始設(shè)計(jì)提示、圖5中返回的設(shè)計(jì)以及圖4中的testbench提示。

（a）有錯誤的8位移位寄存器testbench部分

（b）8位移位寄存器的工具反饋提示

(c) 已更正部分testbench代碼。替換的值加粗/突出顯示。

圖9 成功移位寄存器T1與ChatGPT-4對話的剩余部分。設(shè)計(jì)符合要求。

不幸的是，它生成的testbench包含錯誤的跟蹤（相關(guān)部分如圖9a所示）。模擬時，這將打印錯誤消息。使用圖9b中的消息將這些消息返回給ChatGPT-4。這將提示ChatGPT-4修復(fù)testbench，給出圖9c中的代碼。錯誤得到了解決，設(shè)計(jì)和testbench現(xiàn)在相互驗(yàn)證，這意味著滿足了會話設(shè)計(jì)流標(biāo)準(zhǔn)。此外，人工審核顯示移位寄存器符合原始規(guī)范。

G.結(jié)果

所有聊天日志都在數(shù)據(jù)存儲庫中提供。表III顯示了使用ChatGPT-4和-3.5運(yùn)行的腳本基準(zhǔn)測試的三個測試集的結(jié)果。

表III基準(zhǔn)挑戰(zhàn)結(jié)果

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

幾種故障模式是一致的，一個常見的錯誤是在設(shè)計(jì)或testbench中添加了SystemVerilog特定的語法。例如，它通常會嘗試使用typedef為FSM模型創(chuàng)建狀態(tài)，或?qū)嵗蛄繑?shù)組，這兩種方法在Verilog-2001中都不受支持。

總的來說，ChatGPT-4生產(chǎn)的testbench并不是特別全面。盡管如此，通過其配套testbench的大多數(shù)設(shè)計(jì)也被認(rèn)為是符合要求的。兩次不合規(guī)的“通過”是擲骰子機(jī)，沒有產(chǎn)生偽隨機(jī)輸出。為了結(jié)束設(shè)計(jì)循環(huán)，我們從Tiny Tapeout 3的ChatGPT-4對話中合成了測試集T1，添加了一個由ChatGPT--4設(shè)計(jì)但未測試的包裝器模塊。在所有的設(shè)計(jì)中，需要85個組合邏輯單元、4個二極管、44個觸發(fā)器、39個緩沖器和300個抽頭來實(shí)現(xiàn)。

ChatGPT-3.5：ChatGPT-3.5的表現(xiàn)明顯比ChatGPT-4差，大多數(shù)對話都導(dǎo)致了基準(zhǔn)測試失敗，而通過自己testbench的大多數(shù)對話都是不合規(guī)的。與ChatGPT-4相比，ChatGPT-3.5的故障模式不太一致，每次對話和基準(zhǔn)測試之間都會出現(xiàn)各種各樣的問題。它比ChatGPT-4更經(jīng)常地需要對設(shè)計(jì)和testbench進(jìn)行修改。

H.觀察

在使用挑戰(zhàn)基準(zhǔn)測試的四個LLM中，只有ChatGPT-4表現(xiàn)良好，盡管大多數(shù)對話仍然需要人工反饋才能成功并符合給定的規(guī)范。在修復(fù)錯誤時，ChatGPT-4通常需要幾條消息來修復(fù)小錯誤，因?yàn)樗茈y確切了解是什么特定的Verilog行會導(dǎo)致來自iverilog的錯誤消息。它會添加的錯誤也往往會在對話之間重復(fù)出現(xiàn)。

與功能設(shè)計(jì)相比，ChatGPT-4在創(chuàng)建功能testbench方面也困難得多。大多數(shù)基準(zhǔn)測試幾乎不需要對設(shè)計(jì)本身進(jìn)行修改，而是需要對testbench進(jìn)行維護(hù)。FSM尤其如此，因?yàn)樵撃Ｐ退坪鯚o法創(chuàng)建一個testbench，在沒有關(guān)于狀態(tài)轉(zhuǎn)換和相應(yīng)預(yù)期輸出的重要反饋的情況下，該testbench將正確檢查輸出。另一方面，ChatGPT-3.5在testbench和功能設(shè)計(jì)方面都很吃力。

4共同設(shè)計(jì)的探索：非結(jié)構(gòu)化對話

A.概覽

現(xiàn)實(shí)世界中的硬件設(shè)計(jì)將比我們在第三節(jié)中調(diào)查的要求更廣泛、更復(fù)雜。考慮到以前使用的方法，這是一個挑戰(zhàn)，因?yàn)樗鼘θ祟惻cLLM交互的方式進(jìn)行了腳本化和限制。然而，鑒于不同級別的人類反饋相對成功，我們試圖調(diào)查非結(jié)構(gòu)化對話是否可以提高效率和相互創(chuàng)造力。一般來說，這項(xiàng)研究將通過大規(guī)模的用戶研究來完成，硬件工程師將在開發(fā)過程中與該工具配對。這類研究是在LLM的軟件領(lǐng)域進(jìn)行的，例如谷歌的這個例子，它將其專有LLM與超過一萬名軟件開發(fā)人員配對，并發(fā)現(xiàn)對開發(fā)人員的生產(chǎn)力產(chǎn)生了可衡量的積極影響（將其編碼迭代持續(xù)時間減少了6%，上下文切換次數(shù)減少了7%）。我們的目標(biāo)是通過進(jìn)行概念驗(yàn)證實(shí)驗(yàn)來激勵硬件領(lǐng)域的這項(xiàng)研究，在該實(shí)驗(yàn)中，我們將LLM（性能最好的模型，OpenAI的ChatGPT-4）與經(jīng)驗(yàn)豐富的硬件設(shè)計(jì)工程師（論文作者之一）配對，并在負(fù)責(zé)進(jìn)行更復(fù)雜的設(shè)計(jì)時對結(jié)果進(jìn)行定性檢查。

B.設(shè)計(jì)任務(wù)：一種基于8位累加器的微處理器

限制：我們再次遵守第III-C節(jié)中規(guī)定的要求。我們希望ChatGPT-4編寫所有處理器的Verilog（不包括頂級Tiny Tapeout包裝器）。為了確保我們可以從處理器加載和卸載數(shù)據(jù)，我們要求所有寄存器連接在移位寄存器的“掃描鏈”中。

總體目標(biāo)：共同設(shè)計(jì)基于8位累加器的架構(gòu)。ChatGPT-4的初始提示如圖10所示。考慮到空間限制，我們的目標(biāo)是使用32字節(jié)內(nèi)存（數(shù)據(jù)和指令相結(jié)合）的馮·諾依曼型設(shè)計(jì)。

圖10 基于8位累加器的處理器：啟動協(xié)同設(shè)計(jì)提示

任務(wù)劃分：考慮到所探索的LLM的優(yōu)勢和劣勢，并避免產(chǎn)生“不合規(guī)”設(shè)計(jì)（見第III-E節(jié)），對于該設(shè)計(jì)任務(wù)，經(jīng)驗(yàn)豐富的人類工程師負(fù)責(zé)（a）指導(dǎo)ChatGPT-4，以及（b）驗(yàn)證其輸出。同時，ChatGPT-4全權(quán)負(fù)責(zé)處理器的Verilog代碼。它還產(chǎn)生了處理器的大部分規(guī)格。

C.方法：對話流

一般過程：微處理器設(shè)計(jì)過程始于定義指令集體系結(jié)構(gòu)（ISA），然后實(shí)現(xiàn)ISA所需的組件，然后將這些組件與控制單元組合在數(shù)據(jù)路徑中進(jìn)行管理。模擬和測試被用來發(fā)現(xiàn)錯誤，然后進(jìn)行修復(fù)。

會話線程：考慮到ChatGPT-4和其他LLM一樣，有一個固定大小的上下文窗口（見第II-a節(jié)），我們認(rèn)為與模型會話的最佳方式是將較大的設(shè)計(jì)分解為子任務(wù)，每個子任務(wù)在界面中都有自己的“會話線程”。這使總長度保持在16000個字符以下。當(dāng)長度超過這個值時，一個專有的后端方法會執(zhí)行某種文本縮減，但關(guān)于其實(shí)現(xiàn)的細(xì)節(jié)很少。由于ChatGPT-4不在線程之間共享信息，人類工程師會將前一個線程的相關(guān)信息復(fù)制到新的第一條消息中，從而形成一個逐步定義處理器的“基本規(guī)范”。基本規(guī)范最終包括ISA、寄存器列表（累加器“ACC”、程序計(jì)數(shù)器“PC”、指令寄存器“IR”）、存儲器組、ALU和控制單元的定義，以及處理器在每個周期中應(yīng)該做什么的高級概述。本規(guī)范中的大部分信息由ChatGPT-4生成，并由人類復(fù)制/粘貼和輕度編輯。

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

表IV 會話流程圖：處理器是通過11個“會話線程”中18個主題的125條用戶消息的線性流構(gòu)建的。

重新啟動：有時ChatGPT-4會輸出次優(yōu)響應(yīng)。如果是這樣，工程師有兩個選項(xiàng)：（1）繼續(xù)對話并推動它以修復(fù)響應(yīng)，或者（2）使用接口強(qiáng)制ChatGPT-4“重新啟動”響應(yīng)，即通過假裝以前的答案從未出現(xiàn)來重新生成結(jié)果。在這兩者之間進(jìn)行選擇需要權(quán)衡，需要專業(yè)判斷：繼續(xù)對話可以讓用戶指定之前回應(yīng)的哪些部分是好的或壞的，但重新生成將使整個對話更短、更簡潔（考慮到有限的上下文窗口大小，這很有價值）。盡管如此，從表IV中的“#Restart”列中可以看出，隨著工程師在使用ChatGPT-4方面越來越有經(jīng)驗(yàn)，重新啟動的次數(shù)往往會減少，主題00-07有57次重新啟動，而主題08-18只有8次。在主題04（控制信號規(guī)劃）中，單個消息的最高重新啟動次數(shù)為10次，該主題的消息如圖11所示。這是一個困難的提示，因?yàn)樗筇峁┚哂写罅考?xì)節(jié)的特定類型的輸出，但最終得到了令人滿意的答案，如圖12所示。

圖11 在ChatGPT-4生成數(shù)據(jù)路徑控制信號和定義列表后，主題04中的提示最為困難（10次重新啟動）。

圖12 ChatGPT-4為困難提示生成的代碼（第11次嘗試）。它仍然缺少一些I/O，稍后的消息對此進(jìn)行了更正。

D.結(jié)果: ISA

所有聊天日志都在數(shù)據(jù)存儲庫中提供。在對話00中與ChatGPT-4共同生成的ISA（在10中更新）如表V所示，它是一種相對簡單的基于累加器的設(shè)計(jì)，具有一些顯著的特點(diǎn)：（1）在給定大小限制的情況下，內(nèi)存訪問“具有可變數(shù)據(jù)操作數(shù)的指令”僅使用五位來指定內(nèi)存地址，這意味著處理器將被限制為存儲器的絕對最大32字節(jié)。（2） 只有一條指令具有即時數(shù)據(jù)編碼。（3） 指令使用完整的256個可能的字節(jié)編碼。（4）盡管有點(diǎn)笨拙（沒有堆棧指針），但JSR指令使實(shí)現(xiàn)子例程調(diào)用成為可能。（5） 分支指令有一定的局限性，但很有用。向后跳過兩條指令可以進(jìn)行有效的輪詢（例如，加載輸入，屏蔽相關(guān)位，然后檢查是否為0）。向前跳過3條指令可以跳過JMP或JSR所需的指令。這些是在多次迭代中共同設(shè)計(jì)的，包括后來的修改（對話10-12，“分支更新”），將跳轉(zhuǎn)從2條指令增加到3條。在模擬過程中，我們意識到我們無法僅用2條指令輕松編碼JMP/JSR。（5） LDAR指令允許對內(nèi)存加載進(jìn)行類似指針的解引用。這使我們能夠有效地使用內(nèi)存映射中的常量表（添加在對話17中），將二進(jìn)制值轉(zhuǎn)換為7段顯示器的LED模式。

表V 與CHATGPT-4協(xié)同設(shè)計(jì)（使用所有256個編碼）。

E.結(jié)果：處理器實(shí)現(xiàn)

處理器數(shù)據(jù)路徑在對話08中進(jìn)行了組合，如圖13所示。馮·諾依曼的設(shè)計(jì)（用于數(shù)據(jù)和指令的共享存儲器）需要一個雙狀態(tài)多循環(huán)控制單元（“FETCH”和“EXECUTE”）。到達(dá)HLT指令（重置為退出）后，進(jìn)入第三個“HALT”狀態(tài)，它還會設(shè)置一個processor_halted輸出標(biāo)志。值得注意的是，由于“FETCH”狀態(tài)還會增加PC寄存器，因此ISA中的分支指令需要“-3”和“+2”修飾符。內(nèi)存庫是全局參數(shù)化的，允許人類工程師從Tiny Tapeout封裝類（他們編寫的唯一文件，用于執(zhí)行與處理器無關(guān)的布線）內(nèi)部更改內(nèi)存大小。處理器最終與17字節(jié)的寄存器存儲器合成，第17字節(jié)用于I/O（7段LED輸出，一鍵輸入）。將用于分段模式的10個字節(jié)的查找常量存儲器表連接起來。合成后，處理器在第IV-E節(jié)中產(chǎn)生“GDS”。

圖13 GPT-4設(shè)計(jì)的基于累加器的數(shù)據(jù)路徑（由人工繪制）。用虛線表示的控制信號。

F觀察

總的來說，ChatGPT-4產(chǎn)生了相對高質(zhì)量的代碼，這可以從短暫的驗(yàn)證周轉(zhuǎn)中看出。編寫完P(guān)ython匯編程序（Conversation 09）后，修復(fù)錯誤的會話（10-13、15-16）只使用了125條消息中的19條。考慮到ChatGPT-4每3小時25條消息的速率限制，此設(shè)計(jì)的總時間預(yù)算為ChatGPT--4的22.8小時（包括重新啟動）。每條消息的實(shí)際生成平均約為30秒：如果沒有速率限制，整個設(shè)計(jì)本可以在<100分鐘內(nèi)完成，具體取決于人類工程師。盡管ChatGPT-4相對容易地生成了Python匯編程序，但它很難編寫為我們的設(shè)計(jì)編寫的程序，而且ChatGPT也沒有編寫任何重要的測試程序。總體上，我們完成了在模擬和FPGA仿真中評估了一系列全面的人工編寫的匯編程序中的所有24條指令。

圖14 處理器綜合信息。

5評估

A.討論

實(shí)際采用的步驟：理想情況下，隨著會話LLM的興起，可以用最少的精力實(shí)現(xiàn)從想法到功能設(shè)計(jì)。盡管人們非常重視它們的單次性能（即單步完成設(shè)計(jì)），但我們發(fā)現(xiàn)，對于硬件應(yīng)用程序，LLM作為代碼簽署者的功能更好。如果LLM與經(jīng)驗(yàn)豐富的工程師步調(diào)一致地工作，他們可能會成為一個“能力倍增器”，提供“第一次通過”的設(shè)計(jì)，然后可以進(jìn)行調(diào)整和快速迭代。

腳本基準(zhǔn)測試的一個值得注意的觀察結(jié)果是，總體結(jié)果在很大程度上取決于早期的交互：對最初提示的響應(yīng)和最初的幾個反饋實(shí)例。在許多情況下，由于LLM未能理解錯誤和修復(fù)之間的相關(guān)性，因此需要多次迭代反饋才能解決簡單的錯誤。因此，我們建議評估對早期提示的反應(yīng)，如果它們不令人滿意，請考慮從早期開始“重新開始”對話。

最先進(jìn)技術(shù)的表現(xiàn)：HuggingFace的HuggingChat顯然是表現(xiàn)最差的，有時甚至難以寫出連貫的Verilog。谷歌的Bard在這方面做得更好，但仍然無法遵循足夠詳細(xì)的說明進(jìn)行評估。OpenAI的ChatGPT-3.5和ChatGPT-4都可以遵循規(guī)范并編寫Verilog，但只有ChatGPT-4可以可靠地做到這一點(diǎn)。盡管如此，它還是在不到一半的對話中成功地在沒有人工輸入的情況下做出了符合要求的功能性輸出。然而，一旦有了這些輸入，ChatGPT-4就能夠?yàn)?0/24基準(zhǔn)生成兼容的代碼；這一表現(xiàn)與聊天流程的聯(lián)合設(shè)計(jì)相呼應(yīng)。在這里，該模型能夠幫助創(chuàng)建規(guī)范并將其實(shí)現(xiàn)到Verilog中。最先進(jìn)性能的主要限制在于testbench和驗(yàn)證代碼的作者身份。我們認(rèn)為，這反映了合適的開源訓(xùn)練數(shù)據(jù)的（非）可用性。

B.對有效性的威脅

可再現(xiàn)性：由于測試的會話LLM是不確定的和模型生成的，因此輸出不具有一致的可再現(xiàn)性。這體現(xiàn)在基準(zhǔn)測試對話的不同成功率中，其中針對單個基準(zhǔn)測試的一些對話通過簡單的人工反饋和少量的信息獲得了成功，而另一些則完全失敗。兩個版本的ChatGPT都是封閉源代碼的，并且都是遠(yuǎn)程運(yùn)行的，因此我們無法檢查模型的參數(shù)并分析生成輸出的方法。這些測試的會話性質(zhì)阻礙了再現(xiàn)性，因?yàn)闀捴械拿總€用戶響應(yīng)都取決于之前的模型響應(yīng)，因此微小的變化可能會在最終設(shè)計(jì)中產(chǎn)生實(shí)質(zhì)性的變化。無論如何，我們確實(shí)為結(jié)果重建提供了完整的會話日志。

統(tǒng)計(jì)有效性：由于這項(xiàng)工作的目標(biāo)是以對話方方式設(shè)計(jì)硬件，我們沒有自動化這個過程的任何部分，每個對話都需要手動完成。這限制了可以進(jìn)行的實(shí)驗(yàn)的規(guī)模，而這些實(shí)驗(yàn)也受到速率限制和模型可用性的阻礙（在撰寫本文時，OpenAI的ChatGPT-4和谷歌的Bard的訪問權(quán)限仍然有限）。因此，這三個測試案例可能無法提供足夠的數(shù)據(jù)來得出正式的統(tǒng)計(jì)結(jié)論。

6結(jié)論

挑戰(zhàn)：雖然很明顯，使用會話LLM來幫助設(shè)計(jì)和實(shí)現(xiàn)硬件器件總體上是有益的，但該技術(shù)還不能僅通過驗(yàn)證工具的反饋來一致地設(shè)計(jì)硬件。目前最先進(jìn)的模型在理解和修復(fù)這些工具所帶來的錯誤方面表現(xiàn)得不夠好，無法僅通過初始的人機(jī)交互創(chuàng)建完整的設(shè)計(jì)和testbench。

機(jī)會：盡管如此，當(dāng)人類的反饋被提供給能力更強(qiáng)的ChatGPT-4模型，或用于聯(lián)合設(shè)計(jì)時，語言模型似乎是一個“能力倍增器”，允許快速的設(shè)計(jì)探索和迭代。一般來說，ChatGPT-4可以生成功能正確的代碼，這可以在實(shí)現(xiàn)公共模塊時節(jié)省設(shè)計(jì)者的時間。未來的潛在工作可能涉及更大規(guī)模的用戶研究以調(diào)查這一潛力，以及開發(fā)特定于硬件設(shè)計(jì)的會話LLM，以改進(jìn)設(shè)計(jì)結(jié)果。

審核編輯：湯梓紅