2．2．2 設(shè)計(jì)綜合
綜合是將較高級(jí)抽象層次的描述轉(zhuǎn)換成較低層次描述，在這里就是把HDL程序轉(zhuǎn)化成標(biāo)準(zhǔn)的門級(jí)結(jié)構(gòu)網(wǎng)表。本設(shè)計(jì)采用的EDA工具是Sy-nopsys公司的Synplify，將SoC的各個(gè)模塊分別進(jìn)行綜合，綜合時(shí)要加約束文件和Altera公司的相應(yīng)器件的庫文件，產(chǎn)生一個(gè)FPGA網(wǎng)表文件。
2．2．3 等價(jià)性檢查
形式驗(yàn)證(Formal Verification)主要用來在覆蓋所有可能輸入情況下，檢查是否與給定的規(guī)范一致。等價(jià)性檢查(equivalence check-ing)是形式驗(yàn)證中的一部分，它主要是檢查兩個(gè)門級(jí)網(wǎng)表(gate-level netlisf)之間是否一致，保證網(wǎng)表處理后不會(huì)改變電路的功能，或者檢查RTL和門級(jí)網(wǎng)表之間是否一致，保證網(wǎng)表能正確地實(shí)現(xiàn)RTL代碼所描述的功能，或者檢查RTL間是否一致，保證兩種RTL描述邏輯一致。這種方法主要是用來尋找實(shí)現(xiàn)(Implementation Design)中的缺陷，而不是設(shè)計(jì)中的缺陷。由于芯片開發(fā)中，設(shè)計(jì)代碼將不斷的更改，都需要
更新FPGA的鏡像文件，這樣在頻繁的鏡像制作過程中，可能會(huì)因?yàn)榄h(huán)境和設(shè)計(jì)的更改引出許多實(shí)現(xiàn)過程中的錯(cuò)誤，而本文為了減少這些錯(cuò)誤，采用的Synopsys公司的Formality工具，主要用于檢查網(wǎng)標(biāo)和RTL間是否一致，把RTL設(shè)計(jì)作為Reference Design，而把網(wǎng)標(biāo)作為Imple-mentation Design，在進(jìn)行等價(jià)性檢查時(shí)要加入Altera器件綜合過程中需要的相關(guān)庫文件。
2．2．4 設(shè)計(jì)整合和布局布線
把多個(gè)設(shè)計(jì)文件轉(zhuǎn)換合并到一個(gè)設(shè)計(jì)庫文件中，并把整合后的設(shè)計(jì)輸入到Altera公司的QuartuslI工具，將綜合過的網(wǎng)表中的邏輯門映射到FPGA的內(nèi)部資源中，如ALUT等。
布局是指從映射取出定義的邏輯和輸入輸出塊，并把它們分配到FPGA內(nèi)部的物理位置，布線是指利用自動(dòng)布線軟件使用布線資源選擇路徑試著完成所有的邏輯連接。
2．2．5 時(shí)序分析
在設(shè)計(jì)實(shí)現(xiàn)過程中，在映射后需要對(duì)一個(gè)設(shè)計(jì)的實(shí)際功能塊的延時(shí)和估計(jì)的布線延時(shí)進(jìn)行時(shí)序分析。而在布局布線后，也要對(duì)實(shí)際布局布線的功能塊延時(shí)和實(shí)際布線延時(shí)進(jìn)行時(shí)序分析。時(shí)序分析不僅可以檢查出我們代碼設(shè)計(jì)中的時(shí)序問題，還可以檢查出由于布局布線產(chǎn)生的時(shí)序問題。在本設(shè)計(jì)中用Altera公司的TimeQuest來進(jìn)行時(shí)序分析，通過對(duì)原型設(shè)計(jì)增加時(shí)序約束，提高了工作主頻和減少了關(guān)鍵路徑的延時(shí)。在設(shè)計(jì)中經(jīng)常存在時(shí)序違約的情況，這時(shí)需要查看違約的關(guān)鍵路徑，然后查找原因，進(jìn)行修改后再進(jìn)行時(shí)序分析，重復(fù)整個(gè)過程直到滿足要求。
2．2．6 鏡像文件的生成和下載配置
QuartusII經(jīng)過整合、布局布線等一系列操作后，最終會(huì)生成一個(gè)配置FPGA的位流文件(.sof洛式)，然后利用QuartusII的Programmer工具，通過USB Blaster下載到FPGA，此時(shí)FPGA實(shí)現(xiàn)了原SoC設(shè)計(jì)的功能，原型驗(yàn)證環(huán)境搭建完成。

3 FPGA原型驗(yàn)證測試激勵(lì)的設(shè)計(jì)
測試程序在FPGA基原型驗(yàn)證中起至關(guān)重要的作用，現(xiàn)在的SoC設(shè)計(jì)很多都采用IP復(fù)用的方式，本文所設(shè)計(jì)出的測試程序有可重用性好、功能覆蓋率高和調(diào)試簡易等特點(diǎn)。
測試程序的基本框架如圖5所示，具體模塊的測試程序只需要根據(jù)框架所提供的接口進(jìn)行編寫相應(yīng)的測試程序即可，代碼主要由以下四部分組成：
(1)系統(tǒng)啟動(dòng)部分。主要包含系統(tǒng)的異常向量表和系統(tǒng)啟動(dòng)后設(shè)置ARM內(nèi)核的配置程序，如各種模式下的堆棧設(shè)置、開啟或關(guān)閉FIR和IRQ、設(shè)定中斷向量表等，在Boot_gfd．s中提供了跳到測試程序的接口。
(2)模塊測試部分。在此部分根據(jù)各個(gè)模塊的功能，編寫相應(yīng)的測試函數(shù)，系統(tǒng)在執(zhí)行時(shí)會(huì)調(diào)用這些函數(shù)，完成我們各個(gè)模塊的功能測試。
(3)頭文件部分。為了方便代碼的編寫和理解，在tyoedef．h文件中對(duì)系統(tǒng)的數(shù)據(jù)類型做了重新定義并包含了部分公用函數(shù)的宏定義。一個(gè)SoC系統(tǒng)中擁有大量的寄存器，在本設(shè)計(jì)中用Register．h文件來存放這些寄存器地址的宏定義。