Sau series Design Verification Engineer làm gì?, chắc mọi người cũng hình dung được công việc DV nó ra sao rồi. Giờ mình đi vào phần chính là SystemVerilog và UVM. Nếu bạn định đi theo Design Verification, gần như sớm muộn gì bạn cũng sẽ gặp SystemVerilog và UVM. Bài này, cùng mình và Học Vi Mạch Cùng ICTC bắt đầu với SystemVerilog trước nhé.

Đầu tiên, Mình thấy ở khá nhiều bạn là học rất chăm, nhưng lại dễ bị kẹt ở một đoạn nào đó. Có người thuộc rất nhiều syntax nhưng khi áp dụng vào thực tế lại lúng túng không biết sử dụng thế nào. Có người nhảy vào UVM khá sớm, nhưng lại không hiểu bản chất bên dưới nên càng học càng rối.

Khi mới bắt đầu, không cố nhớ hết mọi thứ. Data type, array các kiểu… cứ đọc qua để biết nó tồn tại và dùng trong trường hợp nào. Lúc đó bạn chưa cần quá chính xác, vì thật ra mấy thứ này dùng nhiều tự khắc sẽ nhớ. Đoạn đáng chú ý hơn là khi bắt đầu đụng tới fork…join, mailbox, semaphore. Lúc này bạn sẽ thấy testbench không còn chạy một mạch từ trên xuống nữa, mà có nhiều process chạy song song và trao đổi dữ liệu với nhau. Nếu hiểu được đoạn này, bạn sẽ dễ hình dung testbench hoạt động ra sao, thay vì chỉ nhìn nó như một đống code rời rạc.

Nhưng nếu phải chọn một phần đáng để đầu tư thời gian nhất trong SystemVerilog, thì đó chắc chắn là class. SystemVerilog thực sự mạnh ở testbench không phải vì nó có nhiều syntax, mà vì nó cho bạn viết theo kiểu OOP. Ban đầu đọc lý thuyết về class, inheritance hay polymorphism có thể hơi khô, nhưng nếu chuyển sang đọc ví dụ và tự viết lại thì sẽ dễ ngấm hơn nhiều. Ngoài ra, đừng bỏ qua interface. Đây là thứ giúp bạn kết nối testbench với DUT một cách gọn gàng hơn, đặc biệt khi bắt đầu viết driver/monitor. Hiểu interface sớm sẽ giúp code sạch và dễ scale hơn về sau.

Đến đoạn random và constraint, nhiều bạn hay bị ngợp vì nghe có vẻ phức tạp. Nhưng thật ra ở giai đoạn đầu, bạn chỉ cần hiểu nó như một cách để tạo dữ liệu test mà không cần ngồi hardcode từng case. Biết cách dùng rand, viết vài constraint cơ bản và gọi randomize() là đủ để đi tiếp. Những thứ sâu hơn có thể để sau.

Một lỗi khá phổ biến là học xong hết mấy thứ này rồi … dừng. Chưa từng viết một testbench tử tế. Theo mình, tới đây nên chuyển sang làm luôn. Tự build một testbench đơn giản bằng SystemVerilog, ví dụ Counter hoặc Memory. Làm rồi bạn sẽ tự gặp những câu hỏi rất thực tế: driver viết gì, monitor lấy data ở đâu, data flow chạy như thế nào. Những thứ này đọc không bao giờ ngấm bằng tự làm.

Sau khi đã có testbench, quay lại học assertion và functional coverage sẽ dễ hiểu hơn nhiều. Lúc đó bạn sẽ thấy rõ: assertion để check behavior, coverage để biết mình đã test đủ hay chưa.

SystemVerilog không khó vì syntax. Cái khó là không biết học để làm gì, nên dễ bị lan man. Khi xác định rõ là học để build testbench, mọi thứ sẽ đơn giản lại: học cái cơ bản, hiểu cách chạy song song, tập trung vào class, dùng random để tạo test, rồi tự build một testbench trước khi đào sâu thêm

Vậy tóm lại, các bước để học tốt SystemVerilog:

1. Data type, array: học để quen syntax, biết dùng khi nào, không cần nhớ hết

2. fork…join, mailbox, semaphore: hiểu cách testbench chạy song song và giao tiếp với nhau

3. Class & Interface: phần quan trọng nhất, class để hiểu OOP và tổ chức code, interface để kết nối testbench với DUT cho gọn và rõ ràng

4. Random, constraint: biết dùng để generate data, chưa cần đào sâu

5. Build testbench: quan trọng nhất, tự làm để hiểu driver, monitor và data flow

6. Assertion, coverage: học sau khi đã có testbench để thấy rõ nó dùng để làm gì

Vậy chúng ta bắt đầu với 1 Systemverilog testbench vào tuần sau nhé?