[UVM] Bài 2 - Phân tích môi trường UVM cho lõi IP UART-APB

Tiếp theo bài 1, bài viết này trình bày tổng quan về môi trường UVM sẽ được build* cho lõi IP UART-APB. Các thành phần của môi trường với nhiệm vụ và chức năng cụ thể sẽ được mô tả khái quát để bạn đọc có cái nhìn cụ thể về một môi trường UVM.

*build: một thuật ngữ dùng để chỉ việc xây dựng một "cái gì đó" từ yêu cầu ban đầu. Build gồm nhiều hành động như phân tích, mô tả specification**, viết code, ...

**specification (gọi tắt là spec): một thuật ngữ dùng để chỉ những tài liệu được tạo ra bởi người thiết kế, những tài liệu này mô tả từ tổng quan đến chi tiết đối tượng mà người thiết kế sẽ thực hiện. Ví dụ, đối với người thiết kế lõi IP, specification là tài liệu mô tả chi tiết thiết kế; đối với người xây dựng môi trường mô phỏng, specification là tài liệu mô tả chi tiết môi trường mô phỏng.

1) Các bước cơ bản để build môi trường mô phỏng

Cấu trúc DUT và mô tả specification của UART đã được trình bày chi tiết trong bài 1. Các bước cơ bản để build một môi trường mô phỏng và kiểm tra thiết kế, ví dụ như môi trường UVM, như sau:

1. Phân tích môi trường:
• Đây là bước đầu tiên trong quá trình build môi trường mô phỏng. Bước này sẽ làm rõ "Làm thế nào để đưa dữ liệu cần kiểm tra đến thiết kế (DUT)?", "Làm thế nào để kiểm tra kết quả mô phỏng?", cấu trúc môi trường, cấu trúc testbench, chức năng và mối liên hệ giữa các thành phần trong môi trường.
• Đối với môi trường UVM, thư viện UVM đã hỗ trợ sẵn các thành phần gốc để build môi trường mô phỏng. Về cơ bản, việc phân tích môi trường sẽ dựa trên sẽ dựa trên cấu trúc và thành phần UVM. Người build môi trường lúc này cần tập trung vào các vấn đề quan trọng sau:
• Xác định rõ các giao tiếp (interface) với DUT sẽ được kết nối với thành phần nào? được lái (drive) hoặc giám sát (monitor) ra sao?
• Bao nhiêu thành phần UVM (Sequencer, Driver, Monitor, Agent, ...) sẽ được sử dụng và kết nối với nhau như thế nào?
• Cấu trúc của một transaction được tạo ra từ sequence gửi đến Driver. Transaction được tạo ra như thế nào và chứa các dữ liệu gì?
• Các thành phần khác, ngoài UVM, được sử dụng là gì? và chức năng là gì?
2. Coding: là viết code để hiện thực hóa các thành phần của môi trường như đã phân tích ở bước 1. Đối với môi trường UVM, ngôn ngữ sử dụng là System Verilog.
3. Kiểm tra: là thực hiện các hoạt động kiểm tra các thành phần môi trường gồm kiểm tra cú pháp, kiểm tra quy định về sử dụng các thành phần UVM và kiểm tra hoạt động của các thành phần trong môi trường.
• Tổng hợp môi trường để kiểm tra cú pháp System Verilog và cú pháp UVM
• Chạy tối hiểu một testcase để kiểm tra hoạt động của các thành phần trong môi trường
4. Xây dựng checklist: Checklist là một danh sách chi tiết các điểm cần kiểm tra. Nó được xây dựng dựa trên specification của thiết kế. Checklist là một phần rất quan trọng giúp kiểm soát số lượng các điểm cần kiểm tra, gọi là các "check item". Một checklist cần chi tiết hóa các điểm sau đây:
• Số lượng check item
• Mô tả mục đích kiểm tra của từng check item
5. Phân tích và viết testcase: việc phân tích các testcase là trả lời câu hỏi "làm thế nào để thực hiện một check item?". Một check item có thể được kiểm tra bằng một hoặc nhiều testcase khác nhau. Một testcase có thể kiểm tra một phần hoặc toàn bộ yêu cầu của một check item đã đặt ra. Một testcase cần mô tả rõ các điểm sau đây:
• Cách thực hiện hay trình tự một testcase sẽ thực thi khi chạy mô phỏng
• Phương pháp xác định kết quả sau khi thực thi testcase, ví dụ như kiểm tra trên log file, waveform, ...
6. Mô phỏng và phân tích kết quả: là việc thực thi mô phỏng với toàn bộ các testcase đã xây dựng và đánh giá kết quả PASS/FAIL cho từng testcase cụ thể.
7. Coverage: là bước cuối cùng, giúp xác định rõ toàn bộ thiết kế đã được kiểm tra đầy đủ hay chưa? còn trường hợp nào chưa được kiểm tra hay không. Nếu kết quả coverage chưa đạt 100% nghĩa là một số thành phần trong thiết kế (trong RTL code) chưa được thực thi. Việc "một phần RTL code nào đó chưa được thực thi" cần được đánh giá xem thuộc trường hợp nào sau đây:
• Trường hợp 1: Thành phần RTL code này không được sử dụng trong thiết kế hiện tại. Trường hợp này không cần tạo thêm testcase để kiểm tra. Ví dụ, trong thiết kế hiện tại, một biến được gán giá trị cố định (hằng số) làm cho RTL code không bao giờ có thể thực thi phần chức năng nào đó. Trong ví dụ dưới đây, case_0 luôn được gán là 1'b0 nên y luôn bằng a-b. Trường hợp y=a+b không bao giờ xảy ra nên không cần tạo testcase để kiểm tra điều này.

assign case_0 = 1'b0;
assign y = case_0? a+b: a-b;

• Trường hợp 2: Thành phần RTL code là một chức năng được sử dụng trong thiết kế hiện tại nhưng các testcase đã có chưa đủ để kiểm tra được phần RTL code này. Người kiểm tra cần phân tích nguyên nhân và các điều kiện cần thiết để tạo thêm testcase kiểm tra phần RTL code này.

Hình 1: Các bước xây dựng môi trường mô phỏng và kiểm tra thiết kế

2) Phân tích môi trường UVM

Phân tích môi trường mô phỏng là bước đầu tiên trong quy trình xây dựng một môi trường mô phỏng. Mọi phân tích sẽ bắt đầu từ spec của thiết kế. Spec của thiết kế, trong môi trường mô phỏng thiết kế là DUT, gồm rất nhiều thông tin khác nhau:

• Cấu trúc DUT (sơ đồ khối, liên kế giữa các khối)
• Chức năng DUT (các chế độ hoạt động, cách thức hoạt động, cách thức cấu hình, ...)
• Các giao tiếp của DUT với hệ thống (giao tiếp APB, giao tiếp UART, giao tiếp ngắt)
• Thanh ghi cấu hình và trạng thái

Chúng ta sẽ bắt đầu từ đâu? Để trả lời câu hỏi này, các bạn hãy hình dung lại cấu trúc cơ bản nhất của tất cả các môi trường mô phỏng. Trong cấu trúc cơ bản này, hai thành phần phải có phục vụ cho việc kiểm tra là stimulus (tác nhân kích thích) và monitor (thành phần giám sát). Trong đó:

• Stimulus cung cấp dữ liệu đầu vào cho DUT
• Monitor giám sát các hoạt động và kết quả sinh ra từ DUT. Monitor giúp chúng ta xác định kết quả mô phỏng là PASS hay FAIL.

Việc phân tích xem stimulus là gì? và monitor là gì? sẽ đưa đến hai câu hỏi quan trọng như đã trình bày ở mục trên là:

• Làm thế nào để đưa dữ liệu cần kiểm tra đến thiết kế (DUT)?
• Làm thế nào để kiểm tra kết quả mô phỏng?

Như vậy, trước hết hãy làm rõ và hiểu kỹ các giao tiếp (interface) của DUT. Mọi mẫu dữ liệu cần cung cấp cho DUT hoặc cần lấy từ DUT để kiểm tra đều phải thông qua các giao tiếp của DUT. Đối với lõi IP UART-APB, chúng ta có 3 giao tiếp:

1. Giao tiếp APB - hoạt động tương thích chuẩn APB AMBA3.0
2. Giao tiếp UART - truyền nhận dữ liệu nối tiếp với UART khác
3. Giao tiếp interrupt - tạo các sự kiện gây ngắt hệ thống

Hình 2: Kết nối và vị trí của lõi IP UART-APB trong một SoC

Trong 3 giao tiếp trên, dữ liệu cung cấp cho UART có thể được đưa vào qua hai giao tiếp:

1. Giao tiếp APB: cấu hình các thanh ghi và nạp dữ liệu cần truyền cho UART bằng cách "ghi" theo giao thức APB
2. Giao tiếp UART: nhận dữ liệu nối tiếp thông qua uart_rx

Như vậy, chúng ta cần tạo stimulus để lái hai giao tiếp này.
Để giám sát kết quả mô phỏng, monitor cần được gắn tại tất cả các giao tiếp để giám sát hoạt động, thái thái trên các giao tiếp này:

1. Giao tiếp APB: cần giám sát hoạt động đúng giao thức APB AMBA 3.0; đọc các dữ liệu cần kiểm tra từ các thanh ghi của lõi IP.
2. Giao tiếp UART: cần giám sát hoạt động đúng giao thức UART; giám sát độ rộng bit truyền (hoặc baud rate); kiểm tra dữ liệu truyền/nhận đúng như cấu hình.
3. Giao tiếp interrupt: Giám sát các tín hiệu ngắt xuất hiện đúng như điều kiện mô tả trong spec.

Với những phân tích về giao tiếp trên đây, chúng ta bắt đầu đánh giá khả năng thực hiện. Chú ý, việc đánh giá khả năng thực hiện cần dựa trên nhiều yếu tố như:

1. Phương pháp hoặc cách thức được chọn có thể kiểm tra DUT chính xác hay không? có rủi ro gì không? Nếu có rủi ro thì cần làm gì để tránh? -> Đây là tiêu chí quan trọng nhất. Nó phải được ưu tiên trên tất cả các tiêu chí khác.
2. Phương pháp hoặc cách thức được chọn có giúp dễ dàng tạo các testcase để kiểm tra hay không? -> Tiêu chí này giúp người kiểm tra dễ dàng hiểu môi trường và tốn ít thời gian viết các testcase.
3. Phương pháp hoặc cách thức được chọn có đơn giản hay không? tốn nhiều thời gian để thực hiện hay không? -> Tiêu chí này giúp giảm thời gian build môi trường mô phỏng.
4. Phương pháp hoặc cách thức được chọn có thể "tái sử dụng" (re-use) dễ dàng với ít sự chỉnh sửa hay không? -> Tiêu chí này giúp giảm thời gian chỉnh sửa môi trường khi DUT thay đổi
5. Phương pháp hoặc cách thức được chọn có phổ biến hay không? -> Tiêu chí này giúp một môi trường hướng đến những quy chuẩn chung về cấu trúc, thành phần, tên gọi được sử dụng, ... Từ đó, nó có thể được đọc, hiểu bởi nhiều kỹ sư khác nhau. Điều này giúp bạn dễ dàng nhận được những hỗ trợ, góp ý trong quá trình build môi trường; dễ chuyển giao môi trường cho kỹ sư khác khi cần.

Trên đây là một số tiêu chí chính được cho là cần phải xem xét kỹ khi build một môi trường mô phỏng. Các tiêu chí này được liệt kê dưới góc nhìn chủ quan của nhóm tác giả để bạn đọc, nhất là các bạn mới bắt đầu có thể định hướng và suy nghĩ về việc build môi trường.

Quay trở lại với ví dụ lõi IP UART-APB, như đã phân tích về các giao tiếp ở phần trên, chúng ta sẽ bắt đầu trả lời rõ hai câu hỏi:

• Làm thế nào để đưa dữ liệu cần kiểm tra đến thiết kế (DUT)?
• Giao tiếp APB:
• Đánh giá: APB là một giao thức đơn giản có thể dễ dàng mô tả hành vi của giao thức bằng System Verilog mà không cần tốn quá nhiều thời gian.
• Quyết định: Sử dụng một UVM driver để làm thành phần stimulus điều khiển.
• Nhận xét: Nếu chúng ta có một APB VIP (Verification IP) đã được kiểm chứng để sử dụng thì sẽ đảm bảo hoạt động của giao thức. Trong trường hợp này, chúng ta tự viết một UVM driver nên nhóm tác giả sẽ tạo thêm một System Verilog APB checker để kiểm tra một số điều kiện hoạt động mong muốn.
• Giao tiếp UART:
• Đánh giá: UART là giao thức truyền nối tiếp với độ rộng các bit dữ liệu thay đổi tùy vào cấu hình baud rate. Bên cạnh đó, cấu trúc khung dữ liệu cũng thay đổi (có hoặc không có parity). Việc tạo một stimulus lái giao thức này tương đương với việc thiết kế một UART. Trường hợp này, chúng ta không có sẵn 1 UART khác hoặc một UART VIP để sử dụng.
• Quyết định: Tạo một top DUT chứa 2 UART instance được kết nối với nhau, một cái truyền, một cái nhận để kiểm tra.
• Nhận xét: Cách làm này có ưu điểm là giảm thời gian build giao tiếp UART, dễ dàng cấu hình 2 UART vào các chế độ hoạt động khác nhau để tạo nhiều trường hợp kiểm tra cần thiết. Tuy nhiên, rủi ro lớn là "giao thức UART không được đảm bảo". Trường hợp này, nhóm tác giả sẽ thêm một System Verilog checker để giám sát giao thức UART giữa 2 UART instance.

Hình 3: Môi trường UVM sau bước phân tích stimulus

• Làm thế nào để kiểm tra kết quả mô phỏng?
• Như đã phân tích trên đây, tại các giao tiếp APB, UART sẽ được gắn thêm checker để kiểm tra. Với giao tiếp interrupt, một checker cũng được tạo ra để giám sát các tín hiệu ngắt.
• Bên cạnh đó, một UVM monitor sẽ được sử dụng để giám sát giao tiếp APB và Interrupt.
• Dữ liệu được truyền từ apb_uart_0 đến apb_uart_1 (chiều từ apb_uart_1 đến apb_uart_0 là tương tự) sẽ được đọc tại apb_uart_1 và so sánh với dữ liệu truyền ở apb_uart_0. Điều này được thực hiện bằng cách:
• Dữ liệu cần truyền từ apb_uart_0 sẽ được lưu lại trong một FIFO.
• Khi apb_uart_1 nhận dữ liệu, nó sẽ được đọc lên và so sánh với giá trị trong FIFO theo thứ tự.
• Quá trình này sẽ được thực hiện bởi scoreboard. Scoreboard sẽ nhận các dữ liệu cần so sánh từ UVM monitor.

Hình 4: Môi trường UVM sau khi phân tích các monitor

Đến đây, chúng ta đã làm rõ các thành phần sẽ sử dụng để lái, giám sát và kiểm tra DUT. Các bạn thấy rằng để môi trường này có thể hoạt động, chúng ta cần cung cấp các mẫu dữ liệu cho UVM driver để lái giao tiếp APB của dut_top. UVM driver chỉ làm nhiệm vụ chuyển đổi một mẫu dữ liệu (transaction) thành những thông tin đúng theo chuẩn APB quy định để lái DUT. Việc cung cấp mẫu dữ liệu này cho driver cần thêm các thành phần UVM khác gồm:

1. UVM Sequencer: tạo các transaction với giá trị cụ thể từ UVM sequencecung cấp cho UVM driver
2. UVM Sequence: Định hình cấu trúc transaction.

Các thành phần Sequencer, Driver và Monitor sẽ được gộp trong UVM agent. UVM agent và Scoreboard sẽ được kết nối với nhau trong UVM environment (uvm_env).
Một test pattern sẽ gọi uvm_env và UVM Sequence để cung cấp các transaction cho việc chạy mô phỏng.

Hình 5: Cấu trúc của uvm_env và phạm vi của một test pattern

DUT sẽ được kết nối với môi trường UVM và các checker trong một top module (testTop).

Hình 6: Cấu trúc tổng thể của toàn bộ môi trường (Chú ý: uvm_env chỉ bao gồm các thành phần nằm trong phạm vi giữa biên giới hạn 1 và 2)

3) Phân tích cấu trúc transaction

Cấu trúc transaction và hoạt động của UVM driver có mối liên hệ mất thiết với nhau.Cấu trúc transaction sẽ chỉ rõ "Những thông tin nào sẽ được tạo ra để cung cấp cho UVM driver?" và "Các thông tin này được tạo ra bằng cách nào?".
Trong ví dụ này, chúng ta cần các mẫu dữ liệu để lái giao tiếp APB nên các thông tin cần cung cấp cho UVM driver là:

• Transaction là đọc hay ghi
• Nếu là một transaction ghi thì thông tin cần cung cấp thêm là
• Địa chỉ ghi (paddr)
• Dữ liệu ghi (pwdata)
• Giá trị điều khiển write strobe (pstrb)
• Nếu là một transaction đọc thì thông tin cần cung cấp thêm chỉ là địa chỉ đọc và cần lưu lại các thông tin về:
• Dữ liệu đọc (prdata)
• Trạng thái trasfer (pslverr)

Hình 7: Cấu trúc transaction

Các bạn lưu ý một số điểm sau đây:

• Các biến pwrite, paddr, pwdata, pstrb, prdata và pslverr là các biến lưu giá trị của transaction. Chúng được đặt tên trùng với các tín hiệu trong giao thức APB để dễ hiểu ý nghĩa chứ chúng không được gán trực tiếp đến các tín hiệu APB của DUT. UVM driver sẽ sử dụng thông tin từ các biến này để lái các tín hiệu APB của DUT theo đúng giao thức.
• Các biến pwrite, paddr, pwdata và pstrb là các biến có thể random (tạo giá trị ngẫu nhiên) được.

Qua bài viết này, các bạn có thể hình dung được bước đầu tiên trong quá trình xây dựng một môi trường mô phỏng, cụ thể là môi trường UVM. Sau bước phân tích này, nhóm tác giả sẽ tiếp tục chi tiết hóa các thành phần đã trình bày trong bài tiếp theo.

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

1/ 2019.06.30 - Tạo lần đầu
2/ 2019.08.11 - Update hình 6

Danh sách tác giả:

1. Phạm Thanh Trâm

2. Đoàn Đức Hoàng (email: hoangbk154@gmail.com)

3. Trương Công Hoàng Việt
4. Nguyễn Sinh Tơn

5. Nguyễn Hùng Quân