Đây là một câu hỏi mình nhận được trong buổi đầu tiên của lớp IC35. Thật ra đây cũng là thắc mắc của rất nhiều bạn mới tìm hiểu về thiết kế vi mạch. Nhiều bạn hay nghĩ công việc được chia rất rõ: RTL engineer thì chỉ viết design, còn verify là chuyện của các bạn DV. Viết xong rồi bàn giao qua là xong.

Thực tế thì không hẳn như vậy. Câu trả lời ngắn gọn là có, kỹ sư RTL design vẫn cần biết verify.

Lý do khá đơn giản. Khi bạn vừa thiết kế xong một module, không ai mang đi đưa cho đội DV ngay mà chưa tự kiểm tra xem nó có chạy đúng những chức năng cơ bản hay không. Trong design flow, bước self-test (tự kiểm tra sau khi code) gần như là bắt buộc đối với kỹ sư thiết kế

Ví dụ, giả sử bạn vừa viết một module FIFO đồng bộ. Trước khi nghĩ đến những bài test phức tạp như simultaneous read/write ở mọi corner case, full-empty transition trong các timing ngặt nghèo, hay stress test với hàng chục nghìn transaction ngẫu nhiên… thì ít nhất bạn phải tự chắc rằng những thứ cơ bản nhất chạy được, như là ghi vào đọc ra phải đúng thứ tự, full thì không ghi thêm được, empty thì không đọc bậy. Những thứ basic sanity check đó là phần mà chính người viết RTL phải tự verify được trước.

Còn những testcase phức tạp hơn như random traffic trong thời gian dài, functional coverage, protocol stress test, assertion checking, corner-case cross scenario… đó mới là lúc các bạn DV phát huy thế mạnh để verify sâu và rộng hơn.

Ngoài ra, kỹ sư RTL design chính là người hiểu thiết kế của mình rõ nhất. Bạn biết từng nhánh if-else, từng state transition, từng assumption rất nhỏ lúc viết code. Có những corner case cực kỳ đặc thù mà đôi khi phía DV không nghĩ ra được, đơn giản vì họ thường phải phụ trách số lượng module nhiều hơn khá nhiều so với một kỹ sư RTL. Thế nên trong thực tế, rất nhiều lần chính RTL engineer sẽ tự viết luôn testcase để check cho chắc.

Chính vì vậy nên một kỹ sư RTL design cần biết những kỹ năng verify cơ bản: viết testbench, viết testcase, chạy simulation, đọc waveform, debug, trace signal, tìm nguyên nhân mismatch giữa expected và actual output…

Trong các lớp cơ bản, các bạn cũng sẽ làm đúng những việc đó. Không phải chỉ ngồi viết RTL xong là xong, mà phải tự build testbench, tự chạy, tự sửa, tự debug cho đến khi design clean. Đây cũng là cách làm gần với môi trường dự án nhất.

Một câu hỏi hay khác là: “Vậy kỹ sư RTL design có cần biết SystemVerilog và UVM không?”

Câu trả lời vẫn là có, nhưng không nhất thiết phải quá sâu như một Verification Engineer.

Trong nhiều dự án, RTL engineer vẫn cần đọc testcase của team DV để hiểu họ đang verify flow nào, stimulus đang được generate ra sao, constraint viết kiểu gì, sequence đang đẩy transaction thế nào, monitor bắt tín hiệu ở đâu, scoreboard đang compare theo logic gì.

Có những lúc bug xuất hiện, bạn phải lần theo testcase để trace xem dữ liệu đi từ sequence xuống driver ra interface rồi vào DUT như thế nào. Nếu không hiểu cấu trúc cơ bản của SV/UVM, package import ở đâu, class hierarchy chạy ra sao, phase nào execute trước, objection được raise/drop thế nào… thì việc debug phối hợp với DV sẽ khá vất vả.

Nói cách khác, RTL engineer không cần thành UVM expert, nhưng nên đủ hiểu để đọc được flow verify và giao tiếp trơn tru với team DV.

Đó cũng là lý do ở các bài test đầu vào của lớp RTL nâng cao sắp tới, ngoài phần design thì vẫn có phần yêu cầu tự viết testbench để self-check để đảm bảo rằng khi bước vào các bài SoC design phức tạp hơn, các bạn đã có tư duy tự verify cho chính thiết kế của mình.

RTL design chưa bao giờ là chuyện viết code xong rồi để người khác lo phần còn lại. Một kỹ sư thiết kế tốt luôn là người có khả năng tự kiểm chứng sản phẩm của mình trước khi mang nó đi xa hơn trong flow. Và một kỹ sư RTL giỏi thường sẽ có mindset: cố gắng tìm ra bug của mình trước khi testcase của DV tìm thấy nó.

Tóm lại là khá vui khi ngay buổi đầu của IC35 đã có những câu hỏi như vậy. Nó cho thấy các bạn đang bắt đầu nhìn ngành này đúng hơn: không phải học từng mảnh rời rạc, mà phải hiểu cách mọi thứ kết nối với nhau trong một flow hoàn chỉnh.