[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