【正文】 d(xx分別為3214)分別對(duì)譯碼產(chǎn)生的5種長(zhǎng)度的立即數(shù)和寄存器操作數(shù)A_reg[31:0]進(jìn)行選擇，得到A_tmp[31:0]；最后由A操作數(shù)取反信號(hào)Neg_A和ALU指令確認(rèn)信號(hào)Alu_valid相與后選擇輸出最終的A操作數(shù)A_oprand[31:0]。2）P2級(jí)寄存輸出A_oprand_p2[31:0]。一起寄存輸出的還有A操作數(shù)的可能的四個(gè)控制位A_bit0_p2[4:0]、A_bit1_p2[4:0]、A_bit2_p2[4:0]、A_bit3_p2[4:0]。 P2級(jí)取A操作數(shù)原理圖另外，分支指令的執(zhí)行安排在P2級(jí)完成。分支指令的執(zhí)行包含分支地址的產(chǎn)生和分支地址寫(xiě)回。其中Jmp(Loop)、Jstack(Return)、Call、Callstack跳轉(zhuǎn)地址可以取地址操作數(shù)得到，Jmul地址需要通過(guò)PRI_ENC模塊運(yùn)算得到。：1）由寄存器PC_STACK硬連線得到Sreg5_pc_stack_p3 [10:0]的值，同時(shí)也取得指令譯碼信號(hào)Jump_label [10:0]。然后根據(jù)指令譯碼信號(hào)Jump_pc_stack_valid選擇跳轉(zhuǎn)地址來(lái)源。若為0，取Jump_label [10:0]，若為1，取Pc_stack [10:0]。2） PRI_ENC模塊運(yùn)算得到指令Jmul跳轉(zhuǎn)地址Jmul_addr[10:0]，和Jump_addr [10:0]一起經(jīng)Jump_valid選擇相應(yīng)的跳轉(zhuǎn)地址信，輸出分支地址Jump_addr_p2[10:0]到P0級(jí)。3）若執(zhí)行Call/Callstack，即Pc_stack_wr_en有效時(shí)，把當(dāng)前指令地址Pc_p2[10:0]+3nop_num存入PC_STACK寄存器低11位，把供Return指令使用的NOP參數(shù)Jump_ ret_nop_num[1:0]存入PC_STACK寄存器高2位。4） 確定NOP參數(shù)。參數(shù)來(lái)源一Jump_valid確認(rèn)信號(hào)與Jump_nop_num[1:0]，來(lái)源二為預(yù)先保存在PC_STACK的Pc_stack_data_p2[15:14],然后由Jump_use_ret_nop_valid選擇NOP參數(shù)來(lái)源。若選擇值為1，即return指令使用參數(shù)Pc_stack_data_p2[15:14]；若選擇值為0，即選擇普通的NOP參數(shù)。若結(jié)果為NOP1，置位Jump_cancel_p1_valid_p2；若結(jié)果為NOP2，同時(shí)置位Jump_cancel_p1_valid_p2和Jump_cancel_p2_valid_p2。5）LOOP指令,即IF(![F_LP_RSV]) JMP。每次執(zhí)行將Sreg4_t_p3[7:0]寄存器值減1。直接出處到P3，更新寄存器Sreg4_t_p3[7:0]。 P2級(jí)分支執(zhí)行原理圖（4）指令執(zhí)行寫(xiě)回部件這一部件實(shí)現(xiàn)了微引擎的數(shù)據(jù)通路，完成了指令的執(zhí)行，包括ALU、MAX、MINTERM、PRI_ENC等運(yùn)算，這里不再贅述。然后本級(jí)將產(chǎn)生得執(zhí)行結(jié)果寫(xiě)回寄存器和存儲(chǔ)器，并將在P2級(jí)產(chǎn)生跳轉(zhuǎn)地址送到P0。 微引擎設(shè)計(jì)實(shí)現(xiàn)方法本文采用Verilog硬件描述語(yǔ)言對(duì)P1600網(wǎng)絡(luò)處理器微引擎模塊進(jìn)行功能描述，建立功能驗(yàn)證模型，然后進(jìn)行功能仿真驗(yàn)證，使用的是Mentor公司的Questasim軟件。通過(guò)編寫(xiě)測(cè)試激勵(lì)對(duì)各類(lèi)數(shù)據(jù)包進(jìn)行驗(yàn)證，并觀察相應(yīng)的輸出波形信號(hào)。一旦發(fā)現(xiàn)代碼設(shè)計(jì)中的錯(cuò)誤，作好記錄并及時(shí)返回設(shè)計(jì)修改代碼。本文采用Synplicity公司的Synplify Premier軟件對(duì)設(shè)計(jì)源代碼進(jìn)行綜合（Synthesis）。綜合是將行為描述的電路轉(zhuǎn)換為基本邏輯單元組成的邏輯連接（網(wǎng)表）的過(guò)程。綜合的最終目標(biāo)是能得到標(biāo)準(zhǔn)的門(mén)級(jí)結(jié)構(gòu)網(wǎng)表，所以編寫(xiě)的Verilog程序必須符合該綜合器風(fēng)格的要求，否則需要返回設(shè)計(jì)修改源代碼。綜合完成后，本文采用Xilinx公司的FPGA對(duì)微引擎設(shè)計(jì)進(jìn)行驗(yàn)證。采用的工具是ISE，根據(jù)所選的芯片的型號(hào)將綜合輸出的邏輯網(wǎng)表翻譯成器件的底層硬件原語(yǔ)，它與芯片實(shí)際的配置情況還有較大差距。在將設(shè)計(jì)映射到器件結(jié)構(gòu)上之后進(jìn)行布局布線，從而在選定芯片上實(shí)現(xiàn)微引擎的設(shè)計(jì)。因?yàn)橹挥衅骷_(kāi)發(fā)商最了解器件的內(nèi)部結(jié)構(gòu)，所以必須選用器件開(kāi)發(fā)商提供的工具軟件。微引擎設(shè)計(jì)實(shí)現(xiàn)的最后一步是器件編程和下板調(diào)試。即產(chǎn)生的位流數(shù)據(jù)文件Bitstream下載到FPGA板中進(jìn)行調(diào)試。本文所采用的FPGA板為Xilinx FPGA Virtex6 XC6VLX550T。 本章小結(jié) 首先對(duì)轉(zhuǎn)發(fā)微引擎的73位專(zhuān)用的指令集進(jìn)行了詳細(xì)的設(shè)計(jì)分析，增加的這些指令對(duì)于網(wǎng)絡(luò)處理中的微引擎對(duì)外部數(shù)據(jù)的訪問(wèn)以及數(shù)據(jù)運(yùn)算要求非常適用，靈活可調(diào)的位寬以及字節(jié)或者位掩碼處理，提高了處理的效率和速度。 其次對(duì)微引擎的結(jié)構(gòu)進(jìn)行了設(shè)計(jì)，采用類(lèi)超標(biāo)量結(jié)構(gòu)，共有4個(gè)RISC核，一個(gè)周期可以同時(shí)處理多條指令。微引擎包含指令存儲(chǔ)器、輸入出入存儲(chǔ)器（寄存器）、內(nèi)部寄存器堆、功能執(zhí)行單元等功能模塊。 接著詳細(xì)設(shè)計(jì)了微引擎的四級(jí)流水線，分別是P0：指令PC值產(chǎn)生；P1：取指；P2：指令譯碼、取操作數(shù)；P3：指令執(zhí)行、寫(xiě)回。微引擎設(shè)計(jì)驗(yàn)證和性能分析第4章 微引擎設(shè)計(jì)驗(yàn)證和性能分析第4章 微引擎功能驗(yàn)證隨著IC設(shè)計(jì)規(guī)模的不斷增長(zhǎng)和設(shè)計(jì)復(fù)雜度的不斷提高，驗(yàn)證已經(jīng)占據(jù)所耗時(shí)間和資源的三分之二，同時(shí)對(duì)驗(yàn)證的穩(wěn)定性和正確性提出了更高的要求，而驗(yàn)證平臺(tái)（testbench）往往決定了驗(yàn)證的結(jié)果是否可靠，因此驗(yàn)證平臺(tái)的設(shè)計(jì)非常關(guān)鍵。對(duì)于傳統(tǒng)的驗(yàn)證平臺(tái)，采用硬件描述語(yǔ)言搭建，而硬件描述語(yǔ)言適合用于寄存器傳輸級(jí)的設(shè)計(jì)，已經(jīng)無(wú)法滿(mǎn)足搭建更抽象和更高級(jí)的驗(yàn)證平臺(tái)的要求。為了解決這個(gè)問(wèn)題，EDA標(biāo)準(zhǔn)化組織Accellera提出了SystemVerilog(SV)，它結(jié)合C、C++、和Verilog語(yǔ)言的概念，極大地提高了更高抽象層次上的設(shè)計(jì)建模能力，擁有芯片設(shè)計(jì)及驗(yàn)證人員所需的全部結(jié)構(gòu)。同時(shí)SystemVerilog還能結(jié)合驗(yàn)證方法學(xué)，來(lái)加速芯片驗(yàn)證過(guò)程提高驗(yàn)證質(zhì)量，因此本文采用SystemVerilog作為驗(yàn)證語(yǔ)言進(jìn)行微引擎的功能驗(yàn)證。4 驗(yàn)證策略和方法（1） 驗(yàn)證策略本文分兩階段進(jìn)行微引擎的驗(yàn)證。第一階段，通過(guò)測(cè)試激勵(lì)自動(dòng)生成器來(lái)生成大量的偽隨機(jī)微碼指令測(cè)試激勵(lì)進(jìn)行驗(yàn)證。此時(shí)并不需要非常了解微引擎內(nèi)部結(jié)構(gòu)，關(guān)鍵是要根據(jù)System verilog的語(yǔ)法結(jié)構(gòu)編寫(xiě)微引擎的指令集。本階段產(chǎn)生的大量測(cè)試向量能夠驗(yàn)證微引擎的主要功能；第二階段，首先分析研究各個(gè)模塊代碼覆蓋率統(tǒng)計(jì)情況，并查看微引擎verilog代碼中未被覆蓋到的語(yǔ)句和分支等；然后根據(jù)上述情況中涉及到的功能點(diǎn)，手工編寫(xiě)少量有針對(duì)性的測(cè)試激勵(lì)進(jìn)行驗(yàn)證，最終使代碼覆蓋率達(dá)到要求。本文采用System verilog編寫(xiě)的驗(yàn)證平臺(tái)進(jìn)行驗(yàn)證，其中最重要的兩個(gè)模塊是激勵(lì)生成和結(jié)果比較。激勵(lì)生成模塊在上文已經(jīng)提到，采取手工編寫(xiě)和隨機(jī)生成兩種方式相結(jié)合。而結(jié)果比較模塊通常也有兩種方法實(shí)現(xiàn)，一種是在驗(yàn)證平臺(tái)中同時(shí)運(yùn)行兩個(gè)模型，即一個(gè)RTL的實(shí)現(xiàn)模型和一個(gè)參考模型（reference model）。其中參考模型不需要可綜合，通常使用高級(jí)語(yǔ)言（如C語(yǔ)言）實(shí)現(xiàn)。然后通過(guò)比較測(cè)試激勵(lì)在兩個(gè)模型上運(yùn)行的輸出結(jié)果和中間狀態(tài)，來(lái)驗(yàn)證被測(cè)設(shè)計(jì)的正確性，被測(cè)試的RTL代碼通常稱(chēng)為DUT（Design Under Test）。 驗(yàn)證平臺(tái)和待測(cè)設(shè)計(jì)的基本結(jié)構(gòu)另一種是采用自檢查(selfchecking)方式，這種方式只有一個(gè) RTL 級(jí)實(shí)現(xiàn)模型，它通過(guò)功能單元將測(cè)試激勵(lì)轉(zhuǎn)化為預(yù)期的正確輸出，在驗(yàn)證過(guò)程中或驗(yàn)證結(jié)束之后判斷中間狀態(tài)和輸出是否與預(yù)期的結(jié)果一致。在實(shí)現(xiàn)驗(yàn)證平臺(tái)的比較模塊時(shí)，本文采取了自檢的方法。由于微引擎模塊級(jí)別的驗(yàn)證 DUT比較復(fù)雜，若每次都要通過(guò)查看波形的方法來(lái)檢查DUT是否正確執(zhí)行，驗(yàn)證效率很低。因此驗(yàn)證環(huán)境必須要有自我檢查的功能。同時(shí)它有利于直接用批處理的方式來(lái)跑仿真，可極大的提高的驗(yàn)證效率和驗(yàn)證正確性。（2） UVM驗(yàn)證方法學(xué) 采用SystemVerilog進(jìn)行驗(yàn)證工作，是一項(xiàng)精細(xì)的工程和極其完整的任務(wù)，需要實(shí)現(xiàn)各種激勵(lì)的生成、并將激勵(lì)按照某種規(guī)定施加給硬件、并從硬件得到響應(yīng)，實(shí)現(xiàn)平臺(tái)的配置機(jī)制等，從零開(kāi)始搭建一個(gè)平臺(tái)是復(fù)雜的過(guò)程，因此，一般搭建平臺(tái)是基于某種方法學(xué)，例如基于AVM、VMM、UVM，這些方法學(xué)都提供自身的平臺(tái)庫(kù)以及平臺(tái)框架，使得驗(yàn)證工作更加快捷有效。UVM（Unicersal Verification Methdology，通用驗(yàn)證方法學(xué)）起源于OVM（Open Verification Methdology），是由三大EDA公司Synopsys、Candence和Mentor聯(lián)合驗(yàn)證業(yè)界于2011年2月正式推出的新一代驗(yàn)證方法學(xué)。UVM是建立在SystemVerilog平臺(tái)上的一個(gè)庫(kù)，它提供了一系列的接口，讓我們更加方便的驗(yàn)證數(shù)字邏輯電路的正確性。 UVM與數(shù)字電路設(shè)計(jì) 相對(duì)于之前的驗(yàn)證方法學(xué)，UVM方法學(xué)更多關(guān)注驗(yàn)證平臺(tái)如何配置，以及在系統(tǒng)驗(yàn)證中的可重用具體方法和思路。另一方面UVM方法學(xué)也繼承了傳統(tǒng)方法學(xué)的很多優(yōu)點(diǎn)，如提供系統(tǒng)級(jí)建模、使用事物處理組件和各種先進(jìn)的庫(kù)機(jī)制等等。為提高驗(yàn)證質(zhì)量，UVM提出了覆蓋率導(dǎo)向驗(yàn)證和約束隨機(jī)化驗(yàn)證等新驗(yàn)證技術(shù)來(lái)提高覆蓋率，并采用斷言（System Verilog Assertion，SVA）來(lái)加速上述過(guò)程。（3） UVC解決方案UVC（Unicersal Verification Componen，通用驗(yàn)證組件）解決方案是基于UVM方法學(xué)的解決方案，為驗(yàn)證工作提供了驗(yàn)證框架、開(kāi)放式驗(yàn)證類(lèi)庫(kù)，使得構(gòu)建驗(yàn)證平臺(tái)的過(guò)程更加容易。 ，一個(gè)基本的UVC驗(yàn)證平臺(tái)由事務(wù)數(shù)據(jù)（transaction）、激勵(lì)序列（sequence）、序列發(fā)生器（sequencer）、序列驅(qū)動(dòng)器（driver）、監(jiān)視器（monitor）以及測(cè)試用例（test）構(gòu)成，各部件之間相互聯(lián)系，互相通信完成對(duì)DUT的各種功能的測(cè)試。這些標(biāo)準(zhǔn)部件都是UVC庫(kù)中提供，平臺(tái)構(gòu)建的時(shí)候按照標(biāo)準(zhǔn)部件構(gòu)建自身所需的相應(yīng)部件，實(shí)現(xiàn)驗(yàn)證所需要的功能即可。UVC組件之間通過(guò)事務(wù)交易級(jí)建模（Transaction Level ModelingTLM）接口通信。 UVC解決方案 驗(yàn)證環(huán)境（1） 驗(yàn)證平臺(tái)總體結(jié)構(gòu) 根據(jù)前文分析可以知道，本文采用的基于UVM方法學(xué)的驗(yàn)證平臺(tái)對(duì)微引擎進(jìn)行功能驗(yàn)證，驗(yàn)證環(huán)境中包含主代理（Master agent）、從代理（Slave agent）、序列庫(kù)（Sequence libirary）記分板（Scoreboard）、覆蓋率收集（Covergroup monitor）以及配置部分。其中主代理中含有序列發(fā)生器，驅(qū)動(dòng)和監(jiān)視器，從代理只含有監(jiān)視器。 驗(yàn)證平臺(tái)總體結(jié)構(gòu)（2）測(cè)試激勵(lì)的生成測(cè)試激勵(lì)的生成是微引擎驗(yàn)證平臺(tái)最核心的部分。本文的測(cè)試激勵(lì)的生成采用手工編寫(xiě)與隨機(jī)生成相結(jié)合的方式。其中手工編寫(xiě)的測(cè)試激勵(lì)主要用于用于兩點(diǎn)：1）系統(tǒng)的初始化。比如時(shí)鐘信號(hào)復(fù)位，微引擎寄存器初始化，設(shè)定微引擎工作狀態(tài)等等；2）針對(duì)隨機(jī)生成的指令難以覆蓋到的情況。比如邊界條件以及未測(cè)試到的功能點(diǎn)等等。對(duì)于隨機(jī)生成的測(cè)試指令流來(lái)說(shuō)，有效性是我們必須滿(mǎn)足的最基本和最重要的要求。如果隨機(jī)指令失去了有效性，那隨機(jī)驗(yàn)證本身也就失去了它的意義。所謂有效性是指隨機(jī)生成的測(cè)試激勵(lì)必須符合處理器的設(shè)計(jì)規(guī)格，并且滿(mǎn)足一定的測(cè)試要求，它是測(cè)試程序最基本的要求。有效性具體分析包括以下三點(diǎn)內(nèi)容。首先，對(duì)指令合法性要求的滿(mǎn)足。指令合法性的要求相對(duì)而言比較容易滿(mǎn)足，支持的是 73 比特的 RSIC 指令集，所以必須限定隨機(jī)生成的指令為73位，同時(shí)微引擎的 30多種類(lèi)型的指令有著各自不同的指令格式，需要逐一對(duì)其添加約束，下面以MOV指令為例進(jìn)行說(shuō)明。MOV指令的源操作數(shù)和目的操作數(shù)寄存器來(lái)源可以為任意核內(nèi)寄存器，但是仍有以下幾點(diǎn)限制：1）源操作數(shù)為立即數(shù)時(shí)的操作碼和為寄存器時(shí)的操作碼不同；2）源寄存器的尋址方式為間接尋址時(shí)，指令49到52位的寄存器索引號(hào)只有兩種可能1110和1111；同理目的寄存器尋址方式為間接尋址時(shí)，存在同樣的限制；3）取操作數(shù)的大小SIZE的方式為間接尋址時(shí)，相應(yīng)SIZE_VALUE為零，否則從00到11。，其中 rand 表示隨機(jī)生成，而十七到三十六行表示的是對(duì)MOV指令提供的約束表達(dá)式。對(duì)于其他三十多種類(lèi)型的指令，其約束添加過(guò)程與這條指令類(lèi)似，不再一一贅述。 生成MOV指令激勵(lì)的部分約束其次，對(duì)指令序列的合法性要求的滿(mǎn)足。全部由合法指令組成的指令序列不一定是合法的，主要原因在于，不同的處理器有著不同的指令集，而大部分指令集中都存在一些有著特殊關(guān)系的指令，比如兩條指令需要成對(duì)的出現(xiàn)，或者某條指令之后不能僅跟部分類(lèi)型的指令。轉(zhuǎn)發(fā)微引擎的指令集對(duì)指令序列的要求并不是很多，主要包含以下幾點(diǎn)：1）分支跳轉(zhuǎn)指令執(zhí)行之后必須插入NOP指令，以解決流水線的控制相關(guān)導(dǎo)致的執(zhí)行錯(cuò)誤；2）不能連續(xù)執(zhí)行同一功能點(diǎn)的情況，比如微引擎向RFD寄存器進(jìn)行寫(xiě)入命令，中間需要加入其它的指令比如空指令NOP；3)某些指令執(zhí)行時(shí)需先初始化一些相關(guān)的功能寄存器，比如Minterm操作執(zhí)行時(shí)需預(yù)先初始化輸入寄存器MINT_I。第三，對(duì)附加的有效性要求的滿(mǎn)足。在隨機(jī)指令序列生成的過(guò)程中，要避免生成一些雖然合法，但對(duì)可能是處理器陷入死循環(huán)，導(dǎo)致驗(yàn)證幾乎沒(méi)有意義的指令序列。對(duì)于轉(zhuǎn)發(fā)微引擎來(lái)說(shuō)，附加的有效性主要針對(duì)的是跳轉(zhuǎn)指令，所以對(duì)于分支跳轉(zhuǎn)指令需要添加更嚴(yán)格的約束。本文中對(duì)跳轉(zhuǎn)指令的約束采用以下兩種方式相結(jié)合的辦法：1）每條跳轉(zhuǎn)指令的跳轉(zhuǎn)地址都為緊跟著它的下一個(gè)地址、下兩個(gè)或者下三個(gè)地址處，具體是哪個(gè)地址進(jìn)行隨機(jī)選擇；2）同時(shí)生成另一些跳轉(zhuǎn)類(lèi)型，無(wú)條件向前跳轉(zhuǎn)，在本文中，我們將這種跳轉(zhuǎn)類(lèi)型放在了每次需要產(chǎn)生的 1024 條指令的最后部分。通過(guò)以上兩種方式既滿(mǎn)足了附加的有效性的要求，同時(shí)又充分保證了跳轉(zhuǎn)方式的全面性。（3）覆蓋率統(tǒng)計(jì) 覆蓋率主要包括代碼覆蓋率和功能覆蓋率。其中代碼覆蓋率是從軟件編程的角度來(lái)分析設(shè)計(jì)代碼是否被充分的驗(yàn)證；功能覆蓋率則是從驗(yàn)證計(jì)劃角度強(qiáng)調(diào)所有規(guī)定的功能點(diǎn)是否都測(cè)試