位流驗證，對于芯片研發(fā)是一個非常重要的測試手段，對于純軟件開發(fā)人員，最難理解的就是位流驗證。在FPGA芯片研發(fā)中，位流驗證是在做什么，在哪些階段需要做位流驗證，如何做？都是問題。

我們先整體的說一下：

首先：在硬件設(shè)計階段，位流驗證是設(shè)計驗證部的重要工作，它是為了驗證硬件設(shè)計的數(shù)字電路部分的合理性，對于FPGA芯片，主要就是對標準的架構(gòu)組件進行驗證。如果相應(yīng)的EDA軟件未成形之前，相應(yīng)的位流需要通過手工單獨生成。

然后：在FPGA配套的EDA軟件開發(fā)階段，位流驗證也非常重要。因為EDA軟件的最大目標就是生成正確的位流，位流輸出是否符合預(yù)期，關(guān)系到軟件各個環(huán)節(jié)的正確性。所以，一般會將位流驗證做為重要的回歸測試手段，一方面，可以持續(xù)驗證最新輸出軟件的正確性，另外，如果芯片的底層架構(gòu)發(fā)生變化，模型變更，仿真庫變更，也可以通過位流驗證，保證架構(gòu)更改的正確性（架構(gòu)主要是按照硬件設(shè)計對應(yīng)的軟件模型，而硬件設(shè)計的這些模型，都會有對應(yīng)的仿真庫和參考模型，用于驗證）。

最后：在生產(chǎn)測試階段，位流驗證同樣是非常好的測試手段，它可以測試位流寫入芯片后上板上芯片的效果，確認芯片實際的運行情況。在軟件中只是保證了邏輯上的正確，實際結(jié)合電氣特性和各種不同環(huán)境是否能正?？煽窟\行，可能通過位流加載后的效果進行驗證。加載到實際板上的效果，也可以通過驅(qū)動程序取出，與預(yù)期參老模型的結(jié)果做對比，驗證其準確性。

當然，位流驗證可能并不僅限于上面的三種情況（限于我了解的內(nèi)容有限），但通過上面的描述，你可以發(fā)現(xiàn)，位流驗證本身是就是會跨多個部門的比較特殊的手段，在不同部門做驗證時，一定會存在配合，和一些有相似的工作。但是，因為各自的目的不同，發(fā)現(xiàn)錯誤后，定位和糾錯的方向也很不一樣。反以，反過來說，選擇的相應(yīng)示例也會有些不同。

今天，我們只講在EDA軟件如何利用位流驗證，完成對EDA軟件的重要回歸測試。

大概的講法是：

：我們會講解位流驗證依賴的框架UVM

：會講一下UVM的實現(xiàn)平臺。

：會講一下針對EDA軟件的驗證，會對哪些部分進行驗證，會使用什么樣的示例 。

：發(fā)現(xiàn)問題后，會如何通過輸出去定位錯誤。

：因為用于自動化回歸，也講一下相應(yīng)的自動化平臺應(yīng)該如何拱建。

首先，我們還是得再來理解一下位流驗證需要用到的UVM框架。

一：UVM框架

1.1：理論

Universal Verifacation Methodology：是一套基于SystemVerilog的標準驗證方法學(xué)。它提供了一套完整的框架，用于構(gòu)建復(fù)雜的驗證環(huán)境，應(yīng)用于芯片設(shè)計領(lǐng)域的功能驗證。旨在提高驗證的可重復(fù)性、可重用性和自動化程度。應(yīng)該說，對于硬件設(shè)計的驗證，UVM是最基礎(chǔ)，最常用的平臺，離不開它。

2.1.1：DUT

待測設(shè)計——Design Under Test，就是你要驗證的設(shè)計單元。

如果你是要驗證/測試一顆 FPGA 芯片，DUT 一般會分為三種，一種是單Tile的設(shè)計，一種是多Tile的設(shè)計，還有就是整個芯片的設(shè)計。

注意這里我加了個bitstream，這并不是UVM必須的，加上bitstream是和我們今天要講的位流驗證扣題，也就是我們在驗證時，使用FPGA的位流文件，來形成DUT的功能。

env：Testbenc Environment ，除了DUT，其它就是UVM的驗證環(huán)境了，它包含了一大堆東西，后面一個一個介紹。

Sequencer：測試數(shù)據(jù)序列，因為測試時需要很多的輸入數(shù)據(jù)，我們按序列提供。

Driver：如何數(shù)據(jù)輸入DUT的過程，可以理解為激勵的過程。

Monitor：監(jiān)控DUT的輸入/輸出信號

Reference Model：參考模型，對應(yīng)DUT的設(shè)計，提供相同行為的給果。

這里參考模型的運行，一般我們會使用仿真工具的內(nèi)置實現(xiàn)來完成。

Compare：比較DUT的輸出和參考模型的輸出，判斷是否匹配。

2.1.2：Sequencer

Sitmulus：生成測試數(shù)據(jù)序列。我們需要基于測試的需求，產(chǎn)生數(shù)據(jù)，交給Driver來驅(qū)動到DUT。比如：你要測試DSP的乘法，那就是提供相應(yīng)的輸入數(shù)值對。

class my_sequence extends uvm_sequence #(my_transaction);

`uvm_object_utils(my_sequence)

task body();
my_transaction tr;
foreach (tr.data[i]) begin
tr.data[i] = $urandom_range(0, 255); // 隨機生成 8 位數(shù)據(jù)
start_item(tr); // 發(fā)送數(shù)據(jù)
finish_item(tr);
end
endtask
endclass

2.1.3：Driver

接收Sequencer的測試數(shù)據(jù)并將其轉(zhuǎn)換為DUT的輸入信號。

這里可能需要模擬時序，比如：時鐘的同步，握手協(xié)議等。

class my_driver extends uvm_driver #(my_transaction);

`uvm_component_utils(my_driver)

task run_phase(uvm_phase phase);
forever begin
seq_item_port.get_next_item(req); // 接收 sequencer 的數(shù)據(jù)
@(posedge clk); // 時鐘同步
dut_input = req.data; // 將數(shù)據(jù)驅(qū)動到 DUT
seq_item_port.item_done();
end
endtask
endclass

2.1.4：Monitor

實時監(jiān)控DUT的輸入和輸出信號，將監(jiān)控到的數(shù)據(jù)送出到比較系統(tǒng)Compare，進行輸出分析。

class my_monitor extends uvm_monitor #(my_transaction);
`uvm_component_utils(my_monitor)

task run_phase(uvm_phase phase);
forever begin
@(posedge clk);
tr.data = dut_output; // 采集 DUT 的輸出數(shù)據(jù)
analysis_port.write(tr); // 將數(shù)據(jù)發(fā)送給 Scoreboard
end
endtask
endclass

2.1.5：Reference Model

參考模型，用于生成和DUT相同邏輯功能的輸出（Golden Model）。

基于相同的輸入激勵信號，獲得理想的輸出。

function bit [7:0] ref_model(input bit [7:0] data);
return data + 1; // 示例：參考模型輸出為輸入加 1
endfunction

2.1.6：Compare

這里的Compare，可能是簡單的比較結(jié)果的輸出，也可能是比較復(fù)雜的Scoreboard（一個記錄數(shù)據(jù)表）。根據(jù)比較結(jié)果，輸出不匹配的情況，并輸出報告。

class my_scoreboard extends uvm_scoreboard;

`uvm_component_utils(my_scoreboard)

task run_phase(uvm_phase phase);
my_transaction ref_tr, dut_tr;
forever begin
ref_tr = ref_fifo.get(); // 從參考模型接收預(yù)期數(shù)據(jù)
dut_tr = dut_fifo.get(); // 從 DUT 獲取實際輸出
if (ref_tr.data !== dut_tr.data)
`uvm_error("Mismatch", $sformatf("Expected: %0h, Got: %0h", ref_tr.data, dut_tr.data));
end
endtask
endclass

2.1.7：示例

我們再來一個完整的示例，說明一下各部分做的事情。

DUT設(shè)計—— 一個簡單的8位加法器。

DUT代碼：（對于位流驗證，輸入不是這個，后面會舉例說明）

module adder(
input logic [7:0] a,
input logic [7:0] b,
output logic [7:0] sum
);
assign sum = a + b;
endmodule

UVM環(huán)境：

這里需要定義一個Transaction，因為每次激勵的執(zhí)行都是不同的事務(wù)，事務(wù)標明輸入和輸出。

Transaction 定義：

class my_transaction extends uvm_sequence_item;
rand bit [7:0] a, b; // 輸入信號
bit [7:0] expected_sum; // 參考模型生成的期望輸出

`uvm_object_utils(my_transaction)

// 構(gòu)造函數(shù)
function new(string name = "my_transaction");
super.new(name);
endfunction
endclass

Sequencer：

class my_sequence extends uvm_sequence #(my_transaction);

`uvm_object_utils(my_sequence)

task body();
my_transaction tr;

repeat (10) begin
tr = my_transaction::create("tr");
tr.a = $urandom_range(0, 255); // 隨機生成輸入 a
tr.b = $urandom_range(0, 255); // 隨機生成輸入 b
start_item(tr); // 開始傳輸數(shù)據(jù)
finish_item(tr); // 結(jié)束傳輸數(shù)據(jù)
end
endtask
endclass

Driver：

class my_driver extends uvm_driver #(my_transaction);

`uvm_component_utils(my_driver)

// DUT 的接口
virtual adder_if dut_if;

// 構(gòu)造函數(shù)
function new(string name = "my_driver", uvm_component parent);
super.new(name, parent);
endfunction

// 運行階段
task run_phase(uvm_phase phase);
forever begin
seq_item_port.get_next_item(req); // 從 Sequencer 獲取數(shù)據(jù)
@(posedge dut_if.clk); // 等待時鐘上升沿
dut_if.a = req.a; // 驅(qū)動 DUT 輸入 a
dut_if.b = req.b; // 驅(qū)動 DUT 輸入 b
seq_item_port.item_done(); // 標記數(shù)據(jù)已完成
end
endtask
endclass

Monitor：

輸入監(jiān)控

class input_monitor extends uvm_monitor;

`uvm_component_utils(input_monitor)

// DUT 接口
virtual adder_if dut_if;
uvm_analysis_port #(my_transaction) analysis_port; // 分析端口

function new(string name = "input_monitor", uvm_component parent);
super.new(name, parent);
endfunction

// 運行階段
task run_phase(uvm_phase phase);
forever begin
@(posedge dut_if.clk); // 等待時鐘上升沿
my_transaction tr = my_transaction::create("tr");
tr.a = dut_if.a; // 采集 DUT 輸入 a
tr.b = dut_if.b; // 采集 DUT 輸入 b
analysis_port.write(tr); // 將交易數(shù)據(jù)發(fā)送給分析端口
end
endtask
endclass

輸出監(jiān)控：

class output_monitor extends uvm_monitor;

`uvm_component_utils(output_monitor)

// DUT 接口
virtual adder_if dut_if;
uvm_analysis_port #(my_transaction) analysis_port; // 分析端口

function new(string name = "output_monitor", uvm_component parent);
super.new(name, parent);
endfunction

// 運行階段
task run_phase(uvm_phase phase);
forever begin
@(posedge dut_if.clk); // 等待時鐘上升沿
my_transaction tr = my_transaction::create("tr");
tr.expected_sum = dut_if.sum; // 獲取 DUT 輸出 sum
analysis_port.write(tr); // 發(fā)送到分析端口
end
endtask
endclass

Compare：

class my_scoreboard extends uvm_scoreboard;

`uvm_component_utils(my_scoreboard)

uvm_analysis_imp #(my_transaction, my_scoreboard) input_analysis_imp;
uvm_analysis_imp #(my_transaction, my_scoreboard) output_analysis_imp;

my_transaction expected_tr, actual_tr;

function new(string name = "my_scoreboard", uvm_component parent);
super.new(name, parent);
input_analysis_imp = uvm_analysis_imp #(my_transaction, my_scoreboard)
::create("input_analysis_imp", this);
output_analysis_imp = uvm_analysis_imp #(my_transaction, my_scoreboard)
::create("output_analysis_imp", this);
endfunction

// 輸入數(shù)據(jù)分析
function void write(input my_transaction tr);
expected_tr = tr;
expected_tr.expected_sum = expected_tr.a + expected_tr.b; // 參考模型
endfunction

// 輸出數(shù)據(jù)分析
function void write(output my_transaction tr);
actual_tr = tr;

// 比較 DUT 輸出和參考模型的期望值
if (actual_tr.expected_sum !== expected_tr.expected_sum) begin
`uvm_error("Mismatch", $sformatf("Expected: %0d, Got: %0d",
expected_tr.expected_sum, actual_tr.expected_sum));
end
endfunction
endclass

2.1.8：位流驗證

那對于位流驗證，UVM是如何使用的呢？

1：首先，必須準備好你的FPGA的EDA軟件（準備好運行時需要的 Flow 的tcl命令)。給出你的芯片仿真時需要的Primitve仿真庫。

2：針對你要測試的全芯片或者部分tile，選擇你要測試的設(shè)計用例（需要有一定的代表性噢，可以是N多，需要有一定覆蓋度），用 flow 生成仿真用的門級網(wǎng)表文件，并輸出用例的route結(jié)果，輸出最終的bitstream。

3：開始對要測試的用例，編寫參考模型（也是另外一種實現(xiàn)方案）。

4：編寫激勵（測試）程序，提供相應(yīng)的激勵數(shù)據(jù)序列。

5：在TestBench上，針對 DUT 的 RefModel模型進行仿真，驗證兩者輸出是否一致，如果一致，說明位流測試正常。比較的方法，要看測試用例的功能。

6：如果測試不正常，可以利用中間輸出，日志輸出，波形輸出等信息進行定位，查看出錯原因。

好了，那UVM框架是如何實現(xiàn)的呢？有什么支撐平臺和工具嗎？

1.2：支撐

那UVM這種框架是如何通平臺來支撐它的呢？我們以Synopsys的VCS為例，來說明它是如何支持的（當然，也可以使用Mentor提供的QuestaSim）。

1.2.1：工具

VCS（Verlog Compiler Simulator）是業(yè)界領(lǐng)先的仿真工具，原生支持UVM，它提供了一系列的工具和功能，全而覆蓋了UVM測試平臺中的各項工作。

UVM 組件	VCS 支持工具/功能
Sequence	SystemVerilog 編譯器直接支持 UVM sequence 的隨機生成和調(diào)試。
Driver	通過 VCS 的時鐘精確仿真，支持 UVM driver 精確地驅(qū)動 DUT 信號。
Monitor	UVM 信號分析器，與 DVE 圖形工具集成，監(jiān)控信號流。
Compare Scoreboard	與覆蓋率分析工具集成，支持寄存器覆蓋率和功能覆蓋率的檢查。
Debug	提供圖形化的 UVM Phase 調(diào)試工具，支持動態(tài)調(diào)試和波形交互分析。
Verification	集成 DVE 和 Verdi 工具，查看波形和調(diào)試測試平臺的運行時行為。

基于VCS的功能，要實現(xiàn)UVM平臺，還需要封裝一些標準的命令，達成常見的功能。

1.2.2：平臺

為了實現(xiàn)UVM的基礎(chǔ)功能，我們需要提供一些封裝功能，我們稱之為平臺。因為VCS并不是直接針對UVM的，所以，我們需要針對它做一些封裝，然后我們基于封裝來使用，這樣，看起來就更像是一個針對UVM實現(xiàn)的平臺了。

基本功能如下：（封裝方法可以使用Python或其它腳本語言來實現(xiàn)）

平臺初始化：

確認 測試平臺的主目錄，測試工程目錄，測試用例目錄，工具目錄，輸出目錄……

設(shè)置重要參數(shù)：

測試的代碼列表庫

測試用例的分組

運行次數(shù)

是否調(diào)試模式：提供更多l(xiāng)og輸出

提供隨機種子數(shù)：用于控制輸入?yún)?shù)的隨機種子，控制測試數(shù)據(jù)的生成。

……

編譯/構(gòu)建：

我們的testbench的代碼還是相對比較復(fù)雜的，另外，它也依賴于背后的仿真平臺提供的大量的庫文件，所以，我們一般需要對testbench的代碼進行構(gòu)建，輸出各種我們需要的環(huán)境。

首先要對DUT代碼進行編譯，一般是SystemVerilog代碼。

一般會使用 Makefile，需要編寫相應(yīng)的makefile，主要是需要將用到的UVM的動態(tài)庫和引用資源進行構(gòu)建。VCS有一些針對UVM的支撐庫。

仿真：

直接調(diào)用VCS的仿真，有低功耗的仿真模式可選

波形分析：

輸出波形，用于Verdi波形調(diào)試

代碼覆蓋率統(tǒng)計：

統(tǒng)計測試的代碼覆蓋率

……

1.2.3：運行

在運行期，為了保證示例可以并行執(zhí)行，一般會使用HPC集群環(huán)境。我們可以使用LSF集群管理，通過 bsub 來將相應(yīng)的任務(wù)，提交到HPC中運行。

比如：

‘一般會把任務(wù)分為多條，按順序?qū)⑷蝿?wù)放入同一個隊列，保證先后次序

bsub -n 1 -M 20480 -q dv_test -Is "上面封裝的命令，完成編譯或仿真或波形分析的功能"

以上是運算支撐最基本的要求。詳細的實現(xiàn)，我們后面會展開給個實例來講。

二：位流驗證

對于位流驗證，我們今天要講的主要是 FPGA的EDA工具測試，在EDA工具的Flow已基本成形的情況下，就可以開始搭建位流驗證平臺了，用于回歸/驗證EDA工具的功能。

2.1：流程圖

我們先來解釋一下上面的典型流程：

測試用例RTL文件

使用FPGA的器件的用例。測試用例文件，一般是DeviceModel提供的一些適合于驗證功能的標準用例。作為待測用例。（這些用例，一般是由簡到繁）

EDA Flow

FPGA的軟件工具的運行flow，在自動化運行時，一般是采用無界面的tcl命令來執(zhí)行。

這里需要保留多個輸出：

綜合/映射后的網(wǎng)表：這是針對所有Primitve的電路實現(xiàn)，可以理解為羅列出，我們的設(shè)計最終實際用到了哪些邏輯的實例。就是可以看到設(shè)計最終使用的Instance，有明確的標識名稱。

Route后輸出的路由文件：這個用來定位所有實例Instance在芯片中實際的物理位置。也就是Impl后，實際上物理芯片上使用的邏輯塊和相應(yīng)的布線。結(jié)合上一步的輸出，可以明確查到實例具體的位置，以及走線的路徑。

Bitstream 位流：這個是生成的bitstream，這個作為Dut的輸入，直接加載到測試平臺（如：VCS），加上提前準備好的芯片的原生的仿真庫，仿真平臺可以實際的模擬芯片的運行，并且得到相應(yīng)的運行中結(jié)果和中間輸出。

用例的TestBench

根據(jù)實際情況，生成的tb文件。包含激勵，定位，比較的邏輯。

測試用例表：原始的測試用例

Primitive行為模型：明確這個Primitive的行為是什么，在尋找參考模型時，需要找到對應(yīng)的參考實現(xiàn)。

解析輸入/輸出管腳：找出輸入IO 和 輸出IO，這個可以在Route 中找到。

編寫用例參考模型：根據(jù)Primitive的行為和你的設(shè)計用例，寫等價的功能。注意，這里的等價模型，一般是仿真平臺直接執(zhí)行出結(jié)果（并不是基于FPGA的邏輯電路來執(zhí)行）。

設(shè)計輸入的激勵信號：設(shè)計測試的輸入數(shù)據(jù)和相應(yīng)的序列。

編寫比較函數(shù)：看如何比較兩者的輸出。對于返回值 ，可以簡單比較輸出。對于時序，可能需要檢查波形，一般是選擇幾個關(guān)鍵的點，不可能全部檢查。

位流測試平臺

結(jié)合位流文件，仿真庫，testbech ，使用UVM平臺進行實際的運行。完成代碼的編譯，構(gòu)建，仿真，結(jié)果比較的功能。

測試結(jié)果

實際比較結(jié)果，將結(jié)果輸出到指定位置，并形成報告。

對于失敗的報告，還可以通過查看其它輸出（日志，波形等），具體進行問題定位。

對于覆蓋度的統(tǒng)計，可以查看目前回歸用例的覆蓋度，進而逐漸提升。

2.2：驗證的問題

如果2.1驗證出問題，那可能有哪些問題呢？我們可以看看。

文件的問題
可能是測試用例的問題，route輸出的問題（net丟失之類），postmap輸出的問題……

IOPackage的問題
可能是IO Pad的錯誤，這可能是IO Package的問題?？赡苁禽斎隤ad，也可能是輸出Pad不對。IO配置不對，配置信號不對，綁定約束的處理問題。

路由的問題
提供的switch box 的連接不對。

邏輯單元不對
模塊的配置有問題，配置問題導(dǎo)致功能出錯，模塊到Switch box的連線問題

其它
DeviceModel建模的問題，也有可能是Primitive實現(xiàn)的問題（硬件方面的）

具體的定位，可以通過源代碼，PostMap文件，route文件來查到具體的實例，然后在VCS的仿真器上，查看具體時點的輸出，這里可能是需要使用工具查看波形。

route文件，postmap文件（這個一般是打平的flattern文件）的具體格式就不方便給出樣例了，這個每家FPGA的格式會有所不同。

三：FPGA芯片驗證方法

我們設(shè)計出來的FPGA芯片，是否能滿足預(yù)期。我們要保證我們提供給用戶的FPGA上每一個器件的功能是符合預(yù)期的，也就是單個tile的功能，以及Tile之間的連接，整體芯片的邏輯是完全正常的。

所以，我們需要針對單Tile，多Tile，fullchip做位流驗證。方法就是使用上面的位流驗證平臺。針對這三種方法，我們分別來說明，說明應(yīng)該如何設(shè)計樣例 ，來達成相應(yīng)的結(jié)果。

3.1：單Tile位流驗證

對于每一種Tile做單獨的測試（所有的Primitive），比如：CLB（LUT，CLA，DFF，SFTR……），CMT，IO，DSP，BRAM，EMRAM，F(xiàn)IFO，OBUF，IBUF，IOBUF，……

并且也包括Tile內(nèi)部的連接信號路由的驗證。

我們以CLB為例：

對于CLB，里面主要涉及不同的LUT，DFF，CLA，SFTR，需要設(shè)計一系列的用例，去覆蓋相關(guān)的器件使用。

我們以最簡單的 Lut2為例，來看看如何構(gòu)建測試用例，參考用例，激勵數(shù)據(jù)，結(jié)果比較。

3.1.1：CLB —— LUT2

首先，我們要了解Lut2的原理，它是由2輸入1輸出組成，可以完成 2個單bit輸入1個輸出的任何邏輯。比如：a & b，a | b , a xor b。

一般來說，廠商會提供 LUT2的Primitive IP，我們假如提供的IP就叫做 YY_LUT2。

那么，對于Dut，那就很簡單了。注意 a & b 的真值 表是 1000b 也就是 h8

Dut的設(shè)計代碼：

moudule And2(

input a,

input b,

output result

);

YY_LUT2 #(.INIT(4'h8)) lut2(.Io(a), .I1(b), .O(result));

end module

將該代碼使用 eda flow 執(zhí)行，生成 bitstream。

我們來看一下參考用例的寫法：

module RefModel(input A,

input B,

output Y);

assign Y = A & B ; // 參考模型的布爾函數(shù)

endmodule

以上的代碼，仿真工具在運行時，會在每個仿真周期，根據(jù)輸入數(shù)據(jù)的變化來重新輸出結(jié)果。對應(yīng)的邏輯表達式的運算是在仿真器中執(zhí)行（實際上就是語法解析，然后交給CPU來執(zhí)行了）。

當然，你的示例還可以是 A | B，A xor B，若干的樣例。

另外：

INIT=0 IS_C_INVERTED = 0 IS_CLR_INVERTED=1 可以驗證 DFFCE 的功能

1bit加，1bit 減 可以驗證CLA功能

wclk極性不反轉(zhuǎn) 驗證 SFTR32

將INIT、IC_C_INVERTED、IS_PRE(CLR/R/S/)_INVERTED的值進行隨機，inst約束到FFA0 驗證 LPQCE

3.1.2：DSP

我們再以DSP為例，選擇合適的用例（針對DSPX18 的 2個輸入乘法)

直接調(diào)用 YY_DSP48_CPLX18 ，具體就不寫了。

具體如何設(shè)置用例，需要根據(jù)DSP48_CPLX18的輸入?yún)?shù)來設(shè)置，盡量保證相關(guān)的參數(shù)可覆蓋。

3.2：多Tile位流驗證

需要驗證 Tile間路由的正確性，在多個tile分配資源，全局信號，時鐘可以正常共享，跨tile的優(yōu)化結(jié)果符合預(yù)期。主要是對一組tile，某個功能區(qū)域進行驗證。驗證多個tile的功能及其之間的交互?？梢杂脕眚炞C協(xié)同工作，比如：DSP 與 BRAM的協(xié)同工作情況，驗證范圍有限，無法覆蓋全芯片的全局資源，比如：時鐘網(wǎng)絡(luò)，全局布線等。

需要構(gòu)造如下用例：

長路徑信號傳輸：

Tile間級聯(lián)：多個tile之間的邏輯級聯(lián)（比如：多級加法器）

Tile內(nèi)外通信：在不同Tile實現(xiàn)的模塊之間進行通信（如：FIFO，AXI總線）

3.3：全芯片位流驗證

對于全局資源（如：時鐘，全局線）的使用進行驗證。關(guān)注邊界行為（I/O引腳，DDR，PCIe）。

需要構(gòu)建的用例 ：

設(shè)計一條覆蓋盡可能多Tile的信號路徑，從一個邊界Tile傳播到對角線另一側(cè)。

在設(shè)計中啟動全局時鐘。

包含外部接口（I/O,DDR,PCIe)在設(shè)計中。

選用的用例，一般會是一些經(jīng)典的電路設(shè)計，比如：FPGA一般會和閃存配合使用，那我們就選用一些標閃的閃存器件來搭建用例（因為閃存用例是有公開的行為模型和仿真庫的）

因為是針對整個芯片的測試，所以，激勵數(shù)據(jù)，應(yīng)該采用jtag方式輸入，涉及到PRAM的操作。相對比較復(fù)雜，這里不再展開細說。

3.4：代碼的測試覆蓋率

測試是否有效，主要看覆蓋率，所以，在仿真運行中輸出測試覆蓋率，是非常重要的指標。

覆蓋率報告通常包括以下信息：

總體覆蓋率：

顯示整個設(shè)計的總體覆蓋率（如行覆蓋率、分支覆蓋率等）。

模塊級覆蓋率：

顯示每個模塊的覆蓋率詳情。

代碼行覆蓋率：

顯示每一行代碼是否被執(zhí)行。

分支覆蓋率：

顯示每個分支是否被覆蓋。

條件覆蓋率：

顯示每個布爾表達式的條件組合是否被覆蓋。

狀態(tài)機覆蓋率：

顯示狀態(tài)機的所有狀態(tài)和狀態(tài)轉(zhuǎn)換是否被覆蓋。

翻轉(zhuǎn)覆蓋率：

顯示信號是否發(fā)生了 0 到 1 或 1 到 0 的翻轉(zhuǎn)。

代碼覆蓋度能夠查看測試的完整度。是非常重要的參考指標。

最后我們來看看，要搭建一個自動化的驗證平臺，需要做一些什么樣的工作：

這部分是一個封裝動作，和驗證本身的關(guān)系并不是很大，但如果對驗證的細節(jié)不清楚，也不能搭建一個好的，可擴展的平臺，因為平臺的功能也不是一成不變的，需要有一個演進的過程。如果有好的設(shè)計，自然最佳。

四：位流驗證的自動化平臺

4.1：平臺架構(gòu)

這軟件EDA的位流驗證的架構(gòu)。如果驗證是上板驗證（生產(chǎn)測試中心）。那位流的運行就不是在仿真環(huán)境，而是在板上的物理芯片運行，然后想辦法把物理芯片的運行結(jié)果，按時序取回，然后進行對比。

4.2：資源管理

需要管理的資源：

平臺的代碼

主要是流程控制的代碼，Python，Shell腳本，主要是存放到Git中，應(yīng)該需要管理版本，

一般會是解釋性腳本語言，不會有編譯/構(gòu)建的過程。

測試工程

每一次回歸測試，我們定義為一個工程。而工程會描述所有運行的輸入，輸出。

工程的定義：針對某個芯片，某種驗證方式，某個器件的測試，我們認為是一個驗證工程。

待驗證芯片——芯片的系列（架構(gòu)），具體輸出的芯片版本號（鎖定的版本）

待驗證的內(nèi)容—— FullChip，或者 TILE_CLB_LUT2，或者 BRAM & DSP 的聯(lián)合工程。

對應(yīng)的仿真庫——不同驗證點，需要提供不同的仿真庫，比如 fullchip和單tile需要的仿真庫是不同的。但相對固定，基本上是提前準備好的。但是如果芯片的架構(gòu)發(fā)生變化，需要做相應(yīng)的更換。也可以理解芯片系列的版本發(fā)生變化。

對應(yīng)的待測式DUT——待測試的DUT的測試用例。

DUT 對應(yīng)的RefModel—— 對應(yīng)的參考模型。

相關(guān)的配置信息——可能存在一些配置，可能待測內(nèi)容不同，配置會有所不同。略

輸出目錄——包括位流輸出目錄（包括一些中間文件輸出），最終輸出目錄。

DUT Testbench

每個待測工程，都需要有一個TestBench 代碼，TestBench 用來定義整個測試的過程。包括如何使用生成的位流進行仿真運行，如何調(diào)用RefModel(Golden case）獲得結(jié)果，兩者如何進行比較，如何輸出。

注意，不同測試工程，可能代碼會有所不同。

測試用例

測試用例是針對芯片待測單元的調(diào)用?？赡苄枰采w待測單元的大多數(shù)輸入組合。這些用例需要進行統(tǒng)一管理，在需要時，在測試工程中配置。

比如：針對 LUT1的測試用例 （只需要初始化一下真值表即可）

YY_LUT1 # ( INIT (2'h3) inst_lut1() // o = a

參考模型代碼

針對測試用例，與之對應(yīng)的另外一種實現(xiàn)（不依賴于FPGA），直接在VCS中運行。如果需要考慮時序，該模型代碼需要打拍。

比如：assign o = a 就是針對上面的LUT1用例的Golden case。

其它配置

配置EDA工具的運行環(huán)境，這個是可以按需配置，因為對于EDA，研發(fā)每天都會有新的版本。

4.3：調(diào)度平臺

因為需要自動化，必須要有調(diào)度，這樣可以定時自動執(zhí)行。

可以通過腳本控制執(zhí)行的入口和過程，控制超時時間，控制運行的隊列（串行還是并行），可以將大任務(wù)發(fā)到計算集群。

調(diào)度很簡單，一般使用 Jekins的 Pipeline即可，Jekins支持Shell，可以進行任務(wù)的編排。

4.4：位流生成

位流生成，就是使用j最新EDA和相應(yīng)的flow tcl ，用來生成位流。

位流生成需要注意幾個點：

可能會添加固定的物理約束，簡化輸出，明確實際的 IOPAD。

4.5：仿真運行

對于test bencch 運行，會有多個步驟。

激勵數(shù)據(jù)的處理

這里要看一下，是否需要形成有針對性的激勵數(shù)據(jù)?？赡芎臀恢棉D(zhuǎn)換有關(guān)（實際位置可以通過位流輸出的 instance和 route信息，獲取實際的位置信息）。

test bench 代碼編譯

針對 test bench代碼，建議采用makefile進行編譯/構(gòu)建，這樣比較容易針對VCS進行動態(tài)鏈接和引用，也定義輸出的動作。

test bech 仿真運行

使用仿真平臺，輸入激勵，進行仿真，輸出波形，輸出代碼覆蓋度。

對Golden Case 進行運行，輸入激勵，執(zhí)行輸出。

兩者進行比較，在仿真log中輸出

4.6：結(jié)果輸出

收集結(jié)果，確認是否成功，輸出最終報告。

可能還會輸出一些必要的數(shù)據(jù)，波形，代碼覆蓋度之類。

五：其它

5.1：硬件設(shè)計驗證

對于硬件部的位流驗證，實際上基本上是一致的。不同之處主要有：

1：在EDA的位流生成功能不成熟前，需要有其它方式生成位流。

2：硬件驗證不通過的情況，會關(guān)注硬件本身的設(shè)計，而不是位流的生成。關(guān)注點會有所不同。

5.2：生產(chǎn)測試中心位流驗證

對于生產(chǎn)測試中心，需要實際上板測試。所以。

1：位流需要download到實際芯片上運行，激勵需要實際輸入到芯片。

2：參考模型與軟件一樣，但注意，大多數(shù)時候要考慮時序，而不是簡單的組合邏輯。

3：對于實際芯片的運行輸入/輸出，一般需要做特殊處理，比如：設(shè)計專用電路，完成激勵輸入，設(shè)計驅(qū)動程序?qū)⑤敵鰯?shù)據(jù)寫入本地磁盤，然后通過磁盤文件獲取結(jié)果，進行比較。

輸出的文件需要表達時序信息。

4：生產(chǎn)測試發(fā)現(xiàn)問題，關(guān)注的是硬件的可靠性。

原文鏈接：https://community.sslcode.com.cn/6789d33a59bcf8384aa65e71.html