[Verification] Tổng quan về công việc kiểm tra và xác minh thiết kế

Bài viết này mô tả tổng quan về công việc kiểm tra và xác minh thiết kế (verification). Bên cạnh đó, bài viết cũng trình bày những khái niệm thuật ngữ liên quan và ý nghĩa của chúng. Hy vọng, qua bài viết, các bạn có thể hình dung một cách rõ ràng những vấn đề mà bạn sẽ gặp phải khi chọn công việc này.

1. Tổng quan

Nếu người thiết kế sáng tạo ra sản phẩm thì người mô phỏng là những người đảm bảo sản phẩm đó phải đáp ứng chất lượng tốt nhất khi đến tay khách hàng. Mục đích quan trọng nhất của người kiểm tra không phải là chỉ đi tìm bug (lỗi thiết kế) mà phải đảm bảo thiết kế hoạt động hoàn toàn chính xác theo đúng yêu cầu. Nghĩa là không chỉ chức năng thiết kế đúng mà các thông số khác như hiệu suất xử lý, tốc độ đáp ứng, ... nếu có thì cũng phải được đảm bảo.

Chi phí cho mỗi lần chế tạo, sản xuất vi mạch vô cùng đắt đỏ. Tùy vào công nghệ, nếu chỉ sản xuất thử nghiệm thì số tiền có thể từ hàng chục đến hàng trăm USD cho lô chip từ 20 đến 40 con. Chỉ một lỗi cũng có thể làm cho sản phẩm bị vứt bỏ hoàn toàn nên yêu cầu công việc kiểm tra ngày càng được chuẩn hóa, chuyên nghiệp và có những phương pháp cụ thể.

2. Các mức kiểm tra thiết kế

2.1 Phân chia mức kiểm tra dựa trên phạm vi kiểm tra

Một thiết kế sẽ cần nhiều mức kiểm tra khác nhau để đảm bảo tính chính xác cao. Dựa trên phạm vi kiểm tra, việc kiểm tra có thể chia làm các mức từ chi tiết đến tổng quan như sau:

• Mức khối (block level)
• Mức kết nối (connection level) hay mức tích hợp (integration level)
• Mức hệ thống (system level) hay mức chip (chip level) hay mức TOP

Kiểm tra mức khối là mức thấp nhất trong các mức kiểm tra. Một thiết kế, được chia làm nhiều khối (block hoặc module) khác nhau. Mỗi khối này thực thi một chức năng nhiệm vụ cụ thể được người thiết kế quy định. Kiểm tra mức này giúp dễ dàng phát hiện ra các bug ẩn sâu trong từng khối. Đây là mức kiểm tra đầu tiên và cần thiết đối với các thiết kế mới.

Tùy vào từng thiết kế, cách hiểu mức block là khác nhau. Ví dụ, nếu thiết kế là một chip MCU như hình 1 thì kiểm tra mức block là kiểm tra các khối chức năng như Cortex-M3, UART, WDT, SPI, RTC, 5-layer AHB Matrix,....

Hình 1. Sơ đồ khối của một chip vi điều khiển MCU

Nếu thiết kế chỉ là một ngoại như UART như hình 2 thì kiểm tra mức block là kiểm tra các khối APB interface, Baud rate generator, Transmitter, Receiver,...

Hình 2. Sơ đồ khối của một UART

Kiểm tra mức kết nối hay mức tích hợp là kiểm tra sự hoạt động của của một block khi được kết nối đến các block khác kết nối trực . Mục tiêu chính của kiểm tra này chính là sự giao tiếp và đáp ứng giữa một block với các block khác kết nối trực tiếp đến nó. Cho dù giao tiếp giữa 2 block đã được chuẩn hóa thì công đoạn kiểm tra này cũng không thể bỏ qua vì cùng một quy định, cùng một tài liệu như mỗi người thiết kế có thể có cách nhìn và hiểu khác nhau nên việc hiểu sai và thực hiện sai hoàn toàn có thể xảy ra. Ví dụ, kiểm tra mức kết nối cho khối Receiver ở hình 2 là kiểm tra giao tiếp giữa Receiver và khối Baud rate generator, khối 32x12 receive FIFO, khối APB interface và Transmitter.

Kiểm tra mức hệ thống là kiểm tra hoạt động của thiết kế trong mô hình hệ thống thực tế mà thiết kế sẽ sử dụng. Từ "hệ thống" ở đây bao hàm một ý nghĩa rộng, hệ thống có thể đơn giản chỉ là kết nối thiết kế đến các mô hình chuẩn thông qua các giao tiếp để kiểm tra hoặc là một tổ hợp hoàn chỉnh của một con chip.

Ví dụ, với thiết kế là một MCU như hình 1, kiểm tra mức hệ thống tương đương với việc kiểm tra mức chip. Một môi trường kiểm tra được xây dựng với đầy đủ các thành phần như một con chip hoàn chỉnh, bạn sẽ kiểm tra hệ thống này như việc bạn lập trình một con chip MCU là viết code firmware (Assemble hoặc C), biên dịch thành mã nhị phân để đưa vào môi trường cho MCU chạy và kiểm tra kết quả.

Đối với thiết kế UART như hình 2, môi trường có thể gồm:

• Một mô hình APB master để kết nối đến khối APB interface và điều khiển giao tiếp này
• Một mô hình UART để kết nối với Transmiter, Receiver và FIFO stattus and Interrupt để thực thi giao thức truyền dữ liệu UART và các giao thức bắt tay mở rộng
• Một bộ tạo và cấp clock đến chân UARTCLK
• Một bộ giám sát tín hiệu ngắt UARTn interrupt
• Một thành phần giám sát tất cả các giao tiếp

Hình 3. Kiểm tra mức hệ thống

2.2 Phân chia mức kiểm tra dựa trên quy trình thiết kế vi mạch

Quy trình thiết kế vi mạch gồm nhiều công đoạn khác nhau. Sau một số công đoạn quan trọng, thiết kế cần được kiểm tra lại. Có hai mức kiểm tra quan trọng là:

• Kiểm tra mức RTL (RTL level) thực thi trên RTL code với mục đích chính là chỉ kiểm tra chức năng (function) của RTL code
• Kiểm tra mức cổng (Gate level) thực thi trên netlist, thành phần được tạo ra sau khi tổng hợp RTL code, với mục đích chính là kiểm tra chức năng có tính đến timing như độ trễ trên các cổng logic, tần số xung clock mà thiết kế có thể đáp ứng, ...

Hình 4. Mức RTL code và mức Gate

3. Kế hoạch kiểm tra

Kế hoạch kiểm tra (verification plan) là một bản mô tả chi tiết và đầy đủ về các đặc điểm cần kiểm tra, kỹ thuật, phương pháp dùng để kiểm tra, thứ tự các bước sẽ thực hiện, cấu trúc môi trường kiểm tra.

Một kế hoạch kiểm tra sẽ trả lời rõ hai câu hỏi quan trọng là:

1. Thiết kế sẽ được kiểm tra như thế nào? 
2. Các trường hợp test, gọi là các test hoặc testcase hoặc testbench, sẽ được viết như thế nào?

Kế hoạch mô phỏng là văn bản định nghĩa các thông tin quan trọng sau:

1. Các test sẽ được sử đụng để kiểm tra thiết kế bao gồm đầy đủ các test từ mức block đến mức TOP hay mức hệ thống
2. Môi trường kiểm tra DUT bao gồm ngôn ngữ sử dụng, cấu trúc testbench, các lệnh đặc biệt, các model, các thư viện, các gói dữ liệu, cấu trúc file, các giao tiếp,...
3. Môi trường xác thực cho DUT gồm định nghĩa phần mềm sử dụng, phương pháp báo lỗi, các loại lỗi.

Hình 5. Ví dụ về một mô tả cấu trúc kiểm tra register trong một kế hoạch kiểm tra

Hình 5 là một minh họa về cách mô tả cấu trúc kiểm tra register trong một thiết kế. Tôi sử dụng minh họa này để giải thích việc mô tả một môi trường mô phỏng trong một kế hoạch kiểm tra. Hai câu hỏi quan trọng của một kế hoạch kiểm tra được thể hiện như sau:

1. Thiết kế sẽ được kiểm tra như thế nào? UVM TEST là testbench sẽ tạo ra các SEQUENCES đưa dữ liệu cho BUS SEQR và HW SEQ. Dữ liệu này được chuyển đến BUS DRIVER và HW DRIVER để lái các đầu vào của thiết kế DUT. Đầu ra của thiết kế được giám sát bằng HW MONITOR. Bên cạnh đó các thuộc tính và các hoạt động khác của DUT còn được giám sát bởi các Assertion, một đặc điểm được hỗ trợ bởi System Verilog. Đối với việc kiểm tra register. Một UVM register Model được sử dụng để kiểm tra giá trị register của DUT.
2. Các trường hợp test, gọi là các test hoặc testcase hoặc testbench, sẽ được viết như thế nào? Các test sẽ được tạo bằng cách viết các UVM TEST khác nhau và các SEQUENCES khác nhau để truyền dữ liệu kiểm tra mong muốn đến DUT

Trong minh họa hình 5, phương pháp mô phỏng được sử dụng là UVM (Universal Verification Methodology).

4. Các loại testbench

4.1 Directed test

Test có hướng (Directed test) là loại test được viết để nhằm mục đích kiểm tra một chức năng hoặc đặc điểm cụ thể nào đó. Theo phương pháp truyền thống, khi nhận được một yêu cầu kiểm tra thiết kế, kỹ sư kiểm tra bắt đầu liệt kê tất cả các test theo mô tả của thiết kế và bắt đầu viết từng test cụ thể cho từng trường hợp. Mối test sẽ truyền những giá trị test cụ thể đến DUT.

Hình 6. Minh họa không gian của một thiết kế có chưa các đặc điểm cần kiểm tra (feature) và các lỗi (bug). Nhiệm vụ của người kiểm tra là tạo ra các test bao phủ (cover) được tất cả các đặc điểm và tìm ra tất cả các lỗi

Tên "directed test" là do mỗi test sẽ chỉ tập trung kiểm tra một hoặc một tập tính năng cụ thể của thiết kế. Như vậy, để một thiết kế được test 100% hoặc có mức độ bao phủ 100% (coverage 100%) thì người kiểm tra phải suy nghĩ và viết đầy đủ được các trường hợp cần test. Điều này hoàn toàn có thể thực hiện được nhưng tốn rất nhiều thời gian và công sức. Tuy nhiên, về mặt quản lý, phương pháp này cho thấy tiến trình và kết quả đều đặn của quá trình kiểm tra.

*Coverage là thông số biểu thị số phần trăm đã được kiểm tra của thiết kế. Một thiết kế đã được test đầy đủ thì giá trị coverage là 100%.

Hình 7. Biều đồ thời gian coverage khi thực thi directed test

Tuy nhiên, nếu thiết kế tăng mức độ phức tạp, ví dụ như tăng gấp đôi thì thời gian để test sẽ cùng tăng gấp đôi hoặc hơn nữa. Đồng thời, có những đoạn thời gian mức độ coverage giữ nguyên trong quá trình test với directed test (tham khảo biểu đồ 7).

Bạn cần phương pháp nhanh hơn nhưng vẫn phải đạt được mục tiêu coverage 100% đó chính là phương pháp test ngẫu nhiên (random test).

4.2 Random test

Trong khi directed test giúp chúng ta tìm ra các bug mà chúng ta dự đoán có thể xảy ra trong thiết kế thì random test có thể tìm ra các bug mà chúng ta không nghĩ đến.

Như tên gọi, test ngẫu nhiên (random test) là testbench tạo ra các giá trị ngẫu nhiên một cách tự động (đặc điểm này được hỗ trợ bởi ngôn ngữ System Verilog) để cung cấp đến DUT. Nhưng đối với giao tiếp đã được quy chuẩn, ví dụ như APB, AHB, AXI, Avalon, .... có các tín hiệu hoạt động bắt tay theo quy định thì làm sao có thể sử dụng random test? Với trường hợp này, nếu sử dụng random test thuần túy, tạo giá trị ngẫu nhiên cho các tín hiệu điều khiển và dữ liệu, thì không thể kiểm tra đúng được. Vì vậy, phương pháp random được hỗ trợ thêm ràng buộc (constraint) để giới hạn khả năng random thông qua các điều kiện cụ thể. Đây cũng là đặc điểm được hỗ trợ bởi ngôn ngữ System Verilog. Test này gọi là "test ngẫu nhiên có ràng buộc" (constrained-random test).

Có thể thấy, với random test số mẫu giá trị đưa vào DUT và thứ tự giá trị đưa đến DUT có thể ngẫu nhiên một cách tự động, có thể kèm ràng buộc nếu cần. Kết quả, tiến độ kiểm tra sẽ rất nhanh trong giao đoạn bắt đầu chạy test tuy việc xây dựng test loại này thường lâu hơn so với directed test do cần có các mô hình giám sát và kiểm tra các gái trị random.

Hình 8. Biều đồ so sánh thời gian đạt coverage 100% khi sử dụng random test và directed test

Về cuối giai đoạn mô phỏng với random test, phạm vi cần kiểm tra của thiết kế bị thu hẹp lại, một số trường hợp có thể phải thêm rất nhiều ràng buộc cho random test hoặc dùng directed test để kiểm tra các trường hợp này. Các trường hợp này gọi là các corner case.

Tóm lại, trong khi directed test tạo chính xác giá trị cần test thì random test có thể tạo ra nhiều giá trị test khác nhau nên các random test có thể bị chồng lấp lên nhau, hai hoặc nhiều test cùng tạo ra cùng một trường hợp kiểm tra. Điều này không phải là vấn đề nghiêm trọng. Nhưng nếu random test tạo ra các giá trị test sai thì buộc phải thêm ràng buộc để giới hạn lại random test.

Quy trình thực hiện kiểm tra mức độ coverage của directed test và random test khác nhau như sau:

• Directed test: Chạy test -> kiểm tra coverage -> tìm điểm chưa được coverage (chưa được kiểm tra) -> hiệu chỉnh test để tạo ra test mới -> quay lại từ đầu
• Random test: Chạy test nhiều lần với các chuỗi giá trị random khác nhau -> kiểm tra coverage -> tìm điểm chưa được coverage (chưa được kiểm tra) -> hiệu chỉnh test để tạo ra test mới (nếu có) -> thêm ràng buộc -> quay lại từ đầu

Hình 9. Quy trình hội tu của directed test và random test

*Note: bài viết có tham khảo cuốn System Verilog for Verification của CHRIS SPEAR

Đọc thêm

[Verification] Hướng dẫn tạo testbench tự kiểm tra thiết kế bằng Verilog, System Verilog

Bài viết này hướng dẫn các bạn viết một testbench đơn giản tự động kiểm tra một thiết kế. Đồng thời qua đó các bạn có thể hiểu cơ bản về việc mô phỏng và kiểm tra thiết kế. Nội dung của bài viết này dành cho các bạn mới bắt đầu tìm hiểu cách viết một testbench Verilog.

1. Môi trường mô phỏng là gì?

Môi trường mô phỏng (simulation environment) hay môi trường kiểm tra (verification environment) của thiết kế là một tổ hợp các thành phần (bao gồm cả thiết kế) cho phép công cụ mô phỏng có thể sử dụng để thực thi tính toán các dữ liệu đầu ra của thiết kế dựa trên các dữ liệu đầu vào được môi trường cung cấp. Dữ liệu đầu ra có thể hiện dưới nhiều dạng khác nhau như một file dữ liệu, hoặc hiển thị trên ngõ ra chuẩn (màn hình).

Với cùng một thiết kế, môi trường mô phỏng được xây dựng bởi các kỹ sư khác nhau có thể khác nhau nhưng đều thực thi hai nhiệm vụ cơ bản:

1. Cấp giá trị ngõ vào cho thiết kế hoạt động
2. Giám sát giá trị ngõ ra của thiết kế tương ứng với những giá trị ngõ vào đã cấp để đảm bảo thiết kế hoạt động chính xác

Testbench là một thành phần của môi trường mô phỏng thực thi trực tiếp hai nhiệm vụ trên hoặc chỉ cấp giá trị ngõ vào cho thiết kế hoạt động. Thuật ngữ testbench cũng có thể dùng để hàm ý nói về một môi trường mô phỏng hoàn chỉnh.

Cấu trúc môi trường mô phỏng cơ bản gồm:

1. DUT (Design Under Test) còn được gọi là UUT (Unit Under Test) chính là thiết kế cần mô phỏng và kiểm tra. DUT sẽ được gọi và kết nối với các thành phần kiểm tra ở bên trong môi trường mô phỏng hoặc trực tiếp trong testbench.
2. Testbench
1. Stimulus hoặc Driver hoặc Test Vector Generator là thành phần tạo và cung cấp dữ liệu đầu vào của DUT, lái các tín hiệu đầu vào của DUT
2. Monitor hoặc Observer là thành phần giám sát và kiểm tra các giá trị ngõ ra của DUT

Hình 1. Cấu trúc cơ bản của môi trường mô phỏng

Xin lưu ý với các bạn, đây chỉ là cấu trúc cơ bản. Hiện nay, với sự phức tạp ngày càng tăng của các thiết kế môi trường mô phỏng cũng được xây dựng dựa trên các giao thức và phương pháp được chuẩn hóa ví dụ như OVM, VMM, UVM,... Các giao thức này phân chia môi trường thành nhiều thành phần với tên gọi khác nhau nhưng vẫn không nằm ngoài 2 mục đích là tạo dữ liệu đầu vào và giám sát dữ liệu đầu ra của thiết kế.

2. Mô tả DUT 

Phần này mô tả DUT sẽ sử dụng trong bài viết này. DUT là một bộ đếm Johnson được mô tả chi tiết ở link sau:

http://nguyenquanicd.blogspot.com/2017/08/verilog-rtl-code-mo-ta-cac-loai-bo-em.html

RTL code của bộ đếm Johnson N bit:

module johnson_counter (clk, rst_n, js_count);
//
parameter N  = 4;
//
//Interface
//
input clk;
input rst_n;
output reg [N-1:0] js_count;
wire js_msb_inv;
assign js_msb_inv = ~js_count[N-1];
always @ (posedge clk) begin
 if (~rst_n)
   js_count[N-1:0] <= 0;
 else
   js_count[N-1:0] <= {js_count[N-2:0], js_msb_inv};
end
endmodule

Bộ đếm này đã được mô phỏng trong bài viết sau:

http://nguyenquanicd.blogspot.com/2017/08/questa-sim-huong-dan-cai-at-va-chay-mo.html

sử dụng testbench có nội dung như sau:

module tb_jc;
parameter N = 4;
//
//Interface
//
reg clk;
reg rst_n;
wire [N-1:0] js_count;
johnson_counter #(.N(N)) dut (.clk(clk), .rst_n(rst_n), .js_count(js_count));
initial begin
  clk = 0;
forever #10 clk = !clk;
end
initial begin
  rst_n = 0;
#20
rst_n = 1;
end
endmodule 

Testbench trên đơn giản chỉ làm nhiệm vụ:

1. Gọi thiết kế
2. Tạo giá trị ngõ vào cho xung clock clk và tín hiệu reset rst_n (Stimulus).

Monitor khi chạy mô phỏng testbench trên là cửa sổ waveform của trình mô phỏng. Qua cửa sổ này, chúng ta quan sát bằng mắt để kiểm tra giá trị của tín hiệu ngx ra js_count theo hoạt động của xung clock và reset.

Việc kiểm tra bằng mắt như trên sẽ gây mất thời gian, phụ thuộc vào "tình trạng" người quan sát nên dễ nhầm lẫn. Nhất là với các thiết kế phức tạp thì việc làm như vậy là không đảm bảo tính đúng đắn của thiết kế. Chính vì vậy, việc xây dựng các môi trường và testbench tự kiểm tra là cần thiết.

3. Mô tả cấu trúc testbench
Một file testbench có thể gồm các thành phần cơ bản như sau:

1. Định nghĩa chỉ dẫn mô phỏng là các khai báo về đơn vị thời gian timescale, define, include các file liên quan
2. Tạo khối testbench bằng cặp từ khóa module/endmodule
3. Khai báo các tham số, hằng số như các parameter
4. Khai báo giao tiếp với DUT: các tín hiệu sẽ kết nối với DUT
5. Gọi DUT
6. Khai báo các tín hiệu, biến sử dụng nội bộ trong testbench
7. Tạo Stimulus
8. Tạo Monitor
9. Giới hạn thời gian chạy mô phỏng của testbench

Trong đó:

• Các thành phần bắt buộc phải có đối với testbench tối thiểu là 2, 4, 5, 7. Testbench loại này như đã nói ở mục 2 phía trên.
• Các thành phần bắt buộc phải có đối với testbench tự động kiểm tra là 2, 4, 5, 7 và 8.

Sau đây, tôi xin mô tả chi tiết từng phần của một testbench dùng để tự động kiểm tra DUT bộ đếm Johnson theo những thành phần đã trình bày ở trên.

3.1 Định nghĩa chỉ dẫn mô phỏng

Khai báo đơn vị thời gian mô phỏng

`timescale 1ns/1ns

3.2 Tạo khối testbench

module tb_auto;
   //testbench body
endmodule

3.3 Khai báo các tham số, hằng số

parameter N = 4;
parameter END_TIME = 100;
parameter VALUE_NUM = 2*N;

Trong đó:

• N là số bit của DUT bộ đếm Johnson
• VALUE_NUM là số giá trị cần phải kiểm tra của DUT
• END_TIME là thời gian giới hạn của testbench khi chạy mô phỏng tính theo số chu kỳ xung clock clk. Ở đây, sau 100 xung clock clk thì mô phỏng sẽ kết thúc.

3.4 Khai báo giao tiếp với DUT

reg clk;

reg rst_n;

wire [N-1:0] js_count;

Đây chính là các ngõ vào và ngõ ra của DUT, Trong đó:

• Ngõ vào được khai báo kiểu biến (variable) để gán giá trị lái DUT
• Ngõ ra khai báo kiểu net chỉ để giám sát

3.5 Gọi DUT

johnson_counter #(.N(N)) dut (.clk(clk), .rst_n(rst_n), .js_count(js_count));

Dòng code trên gọi module johnson_counter và thiết lập số bit cho bộ đếm là N = 4 bit.

3.6 Khai báo các tín hiệu, biến sử dụng nội bộ

reg [N-1:0] test_value[2*N-1:0];

integer i,j;

Trong đó:

• test_value là một mảng dùng để lưu các giá trị cần kiểm tra, giá trị này sẽ được sử dụng để so sánh với ngõ ra DUT để biết DUT có hoạt động đúng hay không.
• i,j là hai biến lặp dùng để xây dựng Stimulus và Monitor

3.7  Tạo Stimulus

Tạo clock với chu kỳ 20 đơn vị thời gian. Đơn vị thời gian ở đây là 1ns, được quy định bởi 3.1. Nếu không có định nghĩa trước về đơn vị thời gian thì testbench sẽ chạy theo đơn vị thời gian mặc định của trình mô phỏng:

initial begin

       clk = 0;

forever #10 clk = !clk;

end

Tạo reset tích cực trong 20ns ở hai điểm là thời điểm bắt đầu mô phỏng 0ns và sau khi chạy 200ns. Điểm thứ 2 là để kiểm tra DUT có hoạt động chính xác khi bị reset trong lúc hoạt động hay không.

initial begin

        rst_n = 0;

#20

rst_n = 1;

#200

rst_n = 0;

#20

rst_n = 1;

end

3.8 Tạo Monitor

Tạo giá trị kiểm tra ngõ ra DUT. Phương pháp tạo ở đây là sử dụng một mảng lưu lại tất cả các giá trị mong muốn được kiểm tra theo thứ tự đúng như cách mà DUT hoạt động. Lưu ý, kỹ sư mô phỏng sẽ xây dựng dựa trên mô tả kỹ thuật (specification) của DUT chứ không phải theo thiết kế DUT của người thiết kế nên cách thực hiện có thể giống và khác với với code của người thiết kế.

initial begin

  j = VALUE_NUM;

  test_value[0] = 0;

  for (i = 1; i < VALUE_NUM; i=i+1) begin

 test_value[i] = {test_value[i-1][N-2:0], ~test_value[i-1][N-1]};

  end

end

Chú ý, số lượng giá trị cần kiểm tra là VALUE_NUM sẽ được lưu theo thứ tự từ ô thứ 0 đến ô thứ VALUE_NUM-1. Tuy nhiên, biến j được gán giá trị ban đầu ngoài tầm này, j = VALUE_NUM là để sử dụng xác định thời điểm testbench bắt đầu kiểm tra sau này. Cụ thể, testbench chỉ kiểm tra bắt đầu tính từ khi DUT được reset. Thời điểm bắt đầu mô phỏng cho đến trước khi reset, giá trị DUT là không xác định nên không kiểm tra.

Tạo địa chỉ để lấy giá trị test từ mảng test_value:

always @ (posedge clk) begin

  if (~rst_n) j <= 0;

else if (j == VALUE_NUM-1) j <= 0;

else j <= j + 1;

end

So sánh và kiểm tra giá trị reset của DUT:

always @ (*) begin

  if (!rst_n && (j != VALUE_NUM) && (js_count[N-1:0] != test_value[j])) begin

   $display ("--------------- SIMULATION FAIL ---------------");

  $display ("[%t]The reset value of DUT: %b\tThe TEST value: %b", $time, js_count[N-1:0], test_value[j]);

   $stop;

   end

end

Ở đây, giá trị reset được test từ khi:

1. Tín hiệu reset tích cực mức thấp, tương ứng rst_n=0
2. Sau khi DUT đã reset, tương ứng, j phải khác giá trị khởi tạo ban đầu

Nếu giá trị ngõ ra DUT js_count khác giá trị kiểm tra test_value, testbench sẽ hiển thị báo sai; hiện vị trí thời gian sai; hiện giá trị DUT và giá trị kiểm tra tại vị trí phát hiện sai. Cuối cùng, dừng mô phỏng bởi $stop.

So sánh và kiểm tra ngõ ra DUT trong lúc hoạt động và không có reset:

always @ (posedge clk) begin

  if (rst_n && (js_count[N-1:0] != test_value[j])) begin

    $display ("--------------- SIMULATION FAIL ---------------");

   $display ("[%t]The DUT value: %b\tThe TEST value: %b", $time, js_count[N-1:0], test_value[j]);

    $stop;

end

end

Khối kiểm tra trên chỉ lấy mẫu kiểm tra tại các vị trí cạnh lên xung clock và báo lỗi bất cứ khi nào giá trị ngõ ra DUT khác với giá trị kiểm tra. Mô phỏng cũng dừng ngay khi phát hiện lỗi.

3.9 Giới hạn thời gian chạy mô phỏng của testbench

initial begin

  repeat (END_TIME) begin

@ (posedge clk);

  end

$display ("[%t]--------------- SIMULATION PASS ---------------", $time);

$stop;

end

Kết thúc thời gian chạy mô phỏng, sau số cạnh lên xung clock clk được quy định bởi END_TIME, testbench sẽ báo mô phỏng thành công với thông điệp "SIMULATION PASS". Điều kiện PASS ở đây không cần vì chỉ cần xuất hiện 1 lỗi thì testbench đã dừng và báo FAIL ngay lập tức.

3.10 Nội dung file testbench hoàn chỉnh

`timescale 1ns/1ns
module tb_auto;
//parameter
parameter N = 4;
parameter END_TIME = 100;
parameter VALUE_NUM = 2*N;
//
//Interface of DUT
//
reg clk;
reg rst_n;
wire [N-1:0] js_count;
//DUT instance
johnson_counter #(.N(N)) dut (.clk(clk), .rst_n(rst_n), .js_count(js_count));
//internal variables
reg [N-1:0] test_value[2*N-1:0];
integer i,j;
//Generate clock
initial begin
  clk = 0;
forever #10 clk = !clk;
end
//Generate reset
initial begin
  rst_n = 0;
#20
rst_n = 1;
#200
rst_n = 0;
#20
rst_n = 1;
end
//END SIMULATION
//After END_TIME cycles, if any error occurs, this testcase is ended and pased
initial begin
  repeat (END_TIME) begin
 @ (posedge clk);
end
$display ("[%t]--------------- SIMULATION PASS ---------------", $time);
$stop;
end
//
//Automatic TEST
//
//Generate the test value table
initial begin
  j = VALUE_NUM;
  test_value[0] = 0;
  for (i = 1; i < VALUE_NUM; i=i+1) begin
 test_value[i] = {test_value[i-1][N-2:0], ~test_value[i-1][N-1]};
  end
end
//Create the address to search the test value from the above table
always @ (posedge clk) begin
  if (~rst_n) j <= 0;
else if (j == VALUE_NUM-1) j <= 0;
else j <= j + 1;
end
//
//Compare and check
//
//Check the reset value
always @ (*) begin
  if (!rst_n && (j != VALUE_NUM) && (js_count[N-1:0] != test_value[j])) begin
 $display ("--------------- SIMULATION FAIL ---------------");
$display ("[%t]The reset value of DUT: %b\tThe TEST value: %b", $time, js_count[N-1:0], test_value[j]);
$stop;
end
end
//Check the output of the Johnson counter
always @ (posedge clk) begin
  if (rst_n && (js_count[N-1:0] != test_value[j])) begin
 $display ("--------------- SIMULATION FAIL ---------------");
$display ("[%t]The DUT value: %b\tThe TEST value: %b", $time, js_count[N-1:0], test_value[j]);
$stop;
end
end
endmodule 

4. Kết quả chạy trên Questa SIM

Việc biên dịch và chạy mô phỏng với Questa SIM các bạn hãy tham khảo hướng dẫn ở link:

http://nguyenquanicd.blogspot.com/2017/08/questa-sim-huong-dan-cai-at-va-chay-mo.html

Ở đây, tôi chỉ phân tích kết quả mô phỏng. Nếu mô phỏng PASS, các bạn sẽ quan sát trên cửa sổ Transcript hiện thông báo "SIMULATION PASS" và thời điểm kết thúc mô phỏng ngay trước thông điệp. Đồng thời, một dòng báo vị trị code trong testbench làm ngắt mô phỏng, chính là dòng $stop trong mục 3.9.

Hình 2. Thông điệp báo PASS trên cửa sổ transcript

Nếu giá trị reset bị sai, tác giả  đã sửa giá trị reset trong RTL code của DUT thành 1 (lưu ý phải biên dịch lại DUT), kết quả mô phỏng như sau:

Hình 3: Sai giá trị reset

Sau khi reset, nếu giá trị DUT sai trong khi hoạt động thì kết quả sẽ như sau. Lưu ý, tôi sửa RTL của DUT thành bộ đếm binary tuần tự như sau:

always @ (posedge clk) begin

 if (~rst_n)

   js_count[N-1:0] <= 0;

 else

   js_count[N-1:0] <= js_count + 1;

end 

Chuỗi giá trị sẽ là:

1. Bộ đếm Binary 4 bit:    0000 -> 0001 -> 0010
2. Bộ đếm Johnson 4 bit:  0000 -> 0001 -> 0011

Vì vậy, testbench sẽ báo lỗi tại vị trí ngõ ra DUT bằng 0010 và giá trị cần test là 0011.

Hình 4. Thông điệp báo lỗi bộ đếm

Việc tạo một testbench kiểm tra cho phép kiểm tra nhiều trường hợp trong thời gian mô phỏng dài mà không cần tốn công dò dạng sóng. Việc xem waveform chỉ thực hiện khi bạn mới xây dựng testbench để kiểm tra tính đúng đắn của testbench và khi phát hiện lỗi để gỡ lỗi (debug).

Trên đây chỉ là một hướng dẫn cơ bản giúp bạn nhanh chóng viết một testbench. Để một DUT được kiểm tra toàn diện và đảm bảo tính đúng đắn cao thì testbench và môi trường mô phỏng có thể cần thêm nhiều thành phần khác.

Lịch sử cập nhật:

1) 2019.11.10 - Cập nhật hình ảnh

Đọc thêm