摘要

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

1介紹

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

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

B.自動(dòng)化硬件描述語言（HDL）

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

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

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

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

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

C.貢獻(xiàn)

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

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

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

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

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

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

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

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

A.大型語言模型 (LLMs)

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

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

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

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

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

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

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

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

A.概覽

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

B.方法

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

圖2 簡(jiǎn)化的LLM對(duì)話流程圖

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

圖4 testbench提示

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

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

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

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

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

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

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

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

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

表一 基準(zhǔn)描述

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

E.模型評(píng)估：度量

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

表二 已評(píng)估的會(huì)話LLM

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

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

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

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

（截?cái)?，格式化）?/p>

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

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

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

F.對(duì)話示例

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

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

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

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

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

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

G.結(jié)果

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

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

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

幾種故障模式是一致的，一個(gè)常見的錯(cuò)誤是在設(shè)計(jì)或testbench中添加了SystemVerilog特定的語法。例如，它通常會(huì)嘗試使用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對(duì)話中合成了測(cè)試集T1，添加了一個(gè)由ChatGPT--4設(shè)計(jì)但未測(cè)試的包裝器模塊。在所有的設(shè)計(jì)中，需要85個(gè)組合邏輯單元、4個(gè)二極管、44個(gè)觸發(fā)器、39個(gè)緩沖器和300個(gè)抽頭來實(shí)現(xiàn)。

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

H.觀察

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

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

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

A.概覽

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

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

限制：我們?cè)俅巫袷氐贗II-C節(jié)中規(guī)定的要求。我們希望ChatGPT-4編寫所有處理器的Verilog（不包括頂級(jí)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位累加器的處理器：?jiǎn)?dòng)協(xié)同設(shè)計(jì)提示

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

C.方法：對(duì)話流

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

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

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

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

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

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

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

D.結(jié)果: ISA

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

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

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

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

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

F觀察

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

圖14 處理器綜合信息。

5評(píng)估

A.討論

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

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

最先進(jìn)技術(shù)的表現(xiàn)：HuggingFace的HuggingChat顯然是表現(xiàn)最差的，有時(shí)甚至難以寫出連貫的Verilog。谷歌的Bard在這方面做得更好，但仍然無法遵循足夠詳細(xì)的說明進(jìn)行評(píng)估。OpenAI的ChatGPT-3.5和ChatGPT-4都可以遵循規(guī)范并編寫Verilog，但只有ChatGPT-4可以可靠地做到這一點(diǎn)。盡管如此，它還是在不到一半的對(duì)話中成功地在沒有人工輸入的情況下做出了符合要求的功能性輸出。然而，一旦有了這些輸入，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.對(duì)有效性的威脅

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

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

6結(jié)論

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

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

審核編輯：湯梓紅