1. Combine test.
Không sử dụng model, Môi trường combine test thường rất lớn,
Bao gồm toàn bộ các rtl (Verilog hoặc system Verilog) được kết nối lại với
nhau. Combine test thường cho việc kiểm tra đọc/ghi thanh ghi, kiểm tra
connection giữa các thành phần.
Chúng ta thường tạo pattern bằng cách viết ngôn ngữ assembly
để CPU có thể access đến các thanh ghi cụ thể (Thông qua địa chỉ của các thanh
ghi này).
2. Unit test.
Dùng để kiểm tra tính đúng đắn của function. Môi trường unit
test thường rất nhỏ vì chỉ test cho một function nhất định. Chúng ta thường
dùng thư viện uvm (build môi trường random test) để tạo môi trường.
Nó không cần toàn bộ rtl của hệ thống mà các chỉ cần một DUT
(Design under test) cụ thể cần được test. Sau đó , các connection đến nó sẽ được
giả lập bởi các model (Tùy theo chuẩn giao tiếp mà bạn đang dùng). Model là một
code được viết bằng ngôn ngữ Verilog hoặc system Verilog được cung cấp bởi
cadence hoặc synopsys. Một model sẽ có đầy đủ các input/output cần connect đến
DUT nhầm thực hiện chức năng nhận data và trả data (giả lập như một rtl hoàn chỉnh).
Với môi trường unit test, kết quả được đánh giá là “PASS” nếu
như function của bạn chạy đúng.
Ví dụ:
Bạn có 1 DUT thực hiện tính năng cộng giữa hai số. Bạn đánh
giá kết quả là “PASS” khi bạn đưa input vào và kết quả gửi ra đúng như mong đợi
(Kết quả mong đợi dựa vào spec).
Người chạy unit test chỉ cần tạo pattern. Partern ở đây
không giống với pattern của combine test vì nó là đưa vào các input cụ thể hoặc
các tín hiệu kích thích ngẫu nhiên. Từ các tín hiệu đó chúng ta sẽ quan sát kết
quả đầu ra. Nếu đúng với kết quả chúng ta mong đợi thì đó là “PASS”. Tôi lấy ví
dụ ta có bộ cộng như bên dưới:
Nhiệm vụ của ta là tạo ra 2 tín hiệu input chứa tất cả các
trường hợp có thể có. Đưa vào DUT và quan sát kết quả đầu ra.
Giả sử nếu ta đưa vào a = 2 và b = 3 các trường hợp có thể xẩy
ra:
- Kết quả đầu ra c= 4 => Fail vì 2+3 # 4.
- Kết quả đầu ra c = 5 => Pass vì 2+3 = 5.
- Quá trình mô phỏng treo.
Bên cạnh việc kiểm tra kết quả ngõ ra, Bạn còn phải đảm bảo
rằng bạn đưa vào đủ các trường hợp có thể có của a và b. Điều này được tính
toán bởi quá trình lấy coverage. Nếu coverage đạt trên bao nhiêu phần % sẽ được
chấp nhận. Vậy tại sao chúng ta cần coverage. Đơn giản là vì nếu bạn sử dụng
môi trường random test các tín hiệu a và b sẽ được tạo ra một cách ngẫu nhiên.
Khi đó bạn không thể đảm bảo rằng nó đưa vào đủ hết các trường hợp. Việc tính
toán coverage là cần thiết để biết chắc bạn đã “PASS” hết tất cả các trường hợp
có thể xảy ra.
3. System test.
System test là cách để bạn kiểm tra hiệu xuất làm việc của
toàn bộ hệ thống.
Tôi lấy ví dụ với unit test bạn chỉ cần kết quả gửi ra đúng
(Hay nói đúng hơn miễn sao function của bạn đúng) là bạn có thể đánh giá kết quả
là “PASS”. Tuy nhiên, thực tế có một số trường hợp đặc biệt bạn không thể đoán
trước được. Tôi lấy ví dụ master A gửi quá nhiều transaction đến slave B. Đôi khi
slave B không thể xử lí kịp và trả về kết quả . Điều này dẫn đến kết quả dữ liệu
bạn nhận được khi read/write có thể bị mất, hoặc hệ thống bị treo…
Để kiểm tra cho việc này chúng ta cần phải có một môi trường
để kiểm tra nó. Và system test ra đời.
Một lưu ý quan trọng là system test rất khó debug vì vậy nó
chỉ nên được chạy tại các giai đoạn sau cùng.
Nghĩa là khi combine test (CT) và unit (UT) đã “PASS”. Việc
đảm bảo function đúng để tránh lãng phí thời gian debug cho system test.
Về cơ bản System test là việc kiểm tra các bus, hay các
interconnection có đáp ứng được các điều kiện hoạt động hay không.
Có đảm bảo performance hay không. Vì hầu như các master hay
slave đều được thay thế bằng model.
Nhiệm vụ của người chạy là tạo các patern (Hay sequence) bằng
cách thiết lập các thông số cho model. Ví dụ bandwidth là bao nhiêu,data width…v…v
(Còn tiếp).
No comments:
Post a Comment