Bài trước chúng ta đã bàn về kỹ sư RTL có cần biết làm DV không. Hôm nay ta sẽ bàn hướng ngược lại, liệu DV có cần hiểu sâu về RTL không nhé.

Đây cũng là một câu hỏi mình gặp khá nhiều khi nói chuyện với các bạn mới học DV. Nhiều bạn nghĩ rằng công việc của Verification Engineer chủ yếu là viết testcase, build environment, chạy regression, check coverage… còn phần RTL bên trong module thì cứ để designer lo.

Theo quan điểm của mình, để trở thành 1 DV giỏi, đặc biệt là khi handle những dự án lớn hoặc các block phức tạp, thì việc hiểu RTL design cũng rất quan trọng.

Tuy nhiên, đây cũng là một chủ đề có khá nhiều quan điểm khác nhau trong ngành.

Có một số ý kiến cho rằng Verification Engineer chỉ cần quan tâm tới design spec. Nghĩa là module được mô tả phải hoạt động như thế nào thì DV sẽ verify xem function có chạy đúng như spec hay không. Theo hướng này, DV không nhất thiết phải đọc RTL code.

Và thật ra quan điểm đó đúng trong một số môi trường làm việc. Ví dụ với những IP đã rất chuẩn hóa, có tài liệu đầy đủ, behavior được mô tả rõ ràng, interface specification chi tiết, timing diagram đầy đủ… thì DV hoàn toàn có thể verify dựa trên spec mà không cần quan tâm quá nhiều bên trong RTL implement như thế nào. Điều này đặc biệt thường thấy ở các 3rd party IP hoặc những block đã mature, được re-use qua nhiều product. Khi đó mindset sẽ là verify behavior theo spec.

Nhưng thực tế không phải lúc nào môi trường dự án cũng lý tưởng như vậy.

Trong khá nhiều công ty nhỏ, startup, hoặc những team chạy tiến độ khá gấp, một designer đôi khi phải handle nhiều module cùng lúc. Tài liệu có thể chưa thật sự chuẩn hóa, spec chưa đủ detail, hoặc có những behavior chỉ được trao đổi nhanh trong lúc làm việc. Khi đó, nếu chỉ đọc spec thôi thì đôi khi DV sẽ rất khó hình dung chính xác block đang hoạt động như thế nào.

Lúc này, việc đọc RTL code ở mức overall để hiểu flow xử lý, structure của block, data đi như thế nào… lại trở nên khá cần thiết, đặc biệt khi debug hoặc trace issue.

Tuy nhiên, trong verification cũng có một điểm khá quan trọng: DV thường không được khuyến khích đọc implementation quá sâu ngay từ đầu.

Lý do là vì khi đọc RTL quá kỹ, Verification Engineer rất dễ bị cuốn theo cách suy nghĩ của designer. Lúc đó testcase sẽ vô tình bị ảnh hưởng bởi implementation hiện tại, dẫn đến mindset kiểu:

“Designer code như vậy thì chắc behavior phải như vậy.”

Cách suy nghĩ này sẽ dẫn đến bỏ sót bug trong quá trình verify.

Trong khi điều DV thực sự cần quan tâm phải là:

“Spec yêu cầu điều gì, và liệu design có thật sự hoạt động đúng như vậy không?”

Thế nên trong thực tế, nhiều DV engineer thường chỉ đọc RTL ở mức vừa đủ để hiểu overall architecture hoặc hỗ trợ debug khi testcase fail, thay vì cố bám quá sâu vào từng dòng implementation.

Dĩ nhiên cũng có những trường hợp việc đọc RTL lại giúp DV nghĩ ra thêm các testcase rất hay. Ví dụ khi debug, bạn vô tình thấy một nhánh condition khá đặc biệt, một state transition hiếm, hay một đoạn logic phụ thuộc rất nhạy vào timing/reset sequence… thì tự nhiên sẽ bắt đầu nghĩ:

“Ủa, case này đã được verify chưa?”

Và khá nhiều lần, những chỗ như vậy lại chính là nơi bug xuất hiện thật.

Ngoài ra, cách các team xử lý bug giữa DV và RTL cũng khá khác nhau tùy văn hóa công ty.

Ở một số team, khi DV tìm được bug thì nhiệm vụ chính chỉ là report phenomenon hoặc issue quan sát được:

• testcase nào fail
• waveform ra sao
• mismatch nằm ở đâu
• điều kiện reproduce bug là gì

Sau đó phía designer sẽ tự debug và tìm root cause.

Nhưng ở một số team khác, DV lại được khuyến khích trace sâu hơn:

• logic nào đang sai
• condition nào gây lỗi
• state transition nào chưa đúng
• thậm chí đôi khi còn đề xuất luôn hướng sửa RTL

Thật ra chuyện này không có đúng sai tuyệt đối, chủ yếu tùy cách vận hành của từng team thôi. Có nơi muốn tách role thật rõ giữa Design và Verification. Nhưng cũng có nơi muốn DV ownership sâu hơn để quá trình debug nhanh hơn.

Một câu hỏi khác hay gặp là:

“Vậy kỹ sư DV có cần code RTL giỏi như RTL engineer không?”

Theo mình là không nhất thiết phải ở mức tối ưu design như một RTL engineer chuyên nghiệp. DV không cần quá tập trung vào chuyện area optimization, synthesis implication hay timing closure như phía design.

Nhưng ít nhất bạn nên:

• đọc hiểu RTL một cách thoải mái
• hiểu handshake protocol
• hiểu pipeline/dataflow
• hiểu module hierarchy
• hiểu signal nào là combinational, signal nào là sequential

Vì nếu không hiểu những thứ đó, testcase đôi khi chỉ đang random cầu may chứ chưa thật sự verify đúng bản chất thiết kế.

Thực tế thì trong quá trình học DV, phần khiến nhiều bạn tiến bộ nhanh nhất lại thường không phải lúc học syntax UVM, mà là lúc ngồi debug waveform và cố hiểu:

“Ủa, tại sao RTL lại chạy như vậy?”

Chính những lúc đó mới bắt đầu hình thành tư duy verify thật sự.

Nên nếu bạn đang theo hướng Verification, đừng nghĩ RTL là vùng đất của riêng designer. Càng hiểu design, bạn càng biết cách verify thông minh hơn, viết testcase sát vấn đề hơn, và debug nhanh hơn rất nhiều.

Đó cũng là điểm thú vị của ngành này. RTL và DV tuy là hai role khác nhau, nhưng cuối cùng vẫn luôn phải hiểu cách suy nghĩ của nhau để làm ra một con chip chạy đúng.