Disable iff: hủy nghĩa vụ đang chờ và phân biệt với gating
Tiên quyết
Sau bài này bạn sẽ
- Phân biệt antecedent false với attempt bị hủy
- Theo dõi nghĩa vụ trước, trong và sau reset
- Đọc đúng giới hạn clock-visible reset của ví dụ đã chạy
Reset có được hủy yêu cầu đang chờ không?
Một start yêu cầu done sau hai tick. Nếu reset xuất hiện trước deadline, yêu cầu ấy còn phải được đáp ứng không?
Hãy trả lời từ yêu cầu thiết kế. Trong ví dụ này, reset được phép hủy nghĩa vụ đang chờ. Hủy nghĩa vụ khác với đáp ứng thành công, và cũng khác với một vi phạm.
Theo dõi yêu cầu trước và sau reset
Clock có cạnh lên ở 5, 15, 25 ns rồi tiếp tục mỗi 10 ns. Reset high từ 12 đến 23 ns: sau start tại tick 1 nhưng trước deadline ở tick 3. Done chỉ đúng tại tick 10.
| Start | Deadline | Có disable iff (rst) |
Chỉ có !rst trong antecedent |
|---|---|---|---|
| Tick 1 | Tick 3 | Nghĩa vụ bị hủy trong reset | Vẫn cần done tại tick 3, nên vi phạm |
| Tick 5 | Tick 7 | Vi phạm vì done bằng 0 | Vi phạm vì done bằng 0 |
| Tick 8 | Tick 10 | Done đáp ứng đúng hạn | Done đáp ứng đúng hạn |
Lỗi tại tick 7 cho thấy yêu cầu sau reset vẫn phải được kiểm. Không nên kéo reset tới hết mô phỏng chỉ để mọi vi phạm biến mất.
Điều kiện disable khác mẫu Boolean của antecedent
Dạng có clock explicit là @(posedge clk) disable iff (rst) start |-> ##2 done.
Với (!rst && start) |-> ##2 done, reset lại nằm trong antecedent được lấy mẫu theo clock. Đó là một cách chọn điều kiện tạo nghĩa vụ, không phải cú pháp hủy nghĩa vụ cũ.
Gating chỉ đổi lúc tạo nghĩa vụ mới
Tại tick 1, reset low nên cả hai cách viết đều tạo nghĩa vụ cho tick 3. Reset high sau đó không làm mẫu antecedent ở tick 1 trở thành false. Nghĩa vụ cũ của cách viết chỉ gating vẫn còn.
Gating không có nghĩa concurrent assertion ngừng được đánh giá ở các tick của nó. Trong ví dụ này, nó ngăn tạo nghĩa vụ non-vacuous mới khi reset được sample high.
Sau reset, cần kiểm cả việc bắt đầu yêu cầu mới và việc phát hiện lỗi hợp lệ. Lịch sử nghiệp vụ của $past cũng cần điều kiện hợp lệ riêng; hủy attempt không tự chứng minh dữ liệu lịch sử đã được làm mới.
Thử reset nằm giữa hai cạnh clock
Reset có thể đổi giữa hai cạnh clock. Ví dụ, xung từ 12 đến 13 ns nằm sau start tại 5 ns nhưng kết thúc trước cạnh kế tại 15 ns.
Nếu yêu cầu thiết kế cho phép reset ấy hủy nghĩa vụ đang chờ, hãy kiểm riêng tình huống này. Nó khác tình huống reset high qua cạnh sample trong bảng trên.
Cũng cần thử trường hợp reset xuất hiện khi chưa có nghĩa vụ và khi nhiều nghĩa vụ đang sống. Phần bằng chứng cuối bài ghi rõ trường hợp công cụ hiện tại đã chạy đúng và trường hợp còn chưa đạt.
Không đoán ưu tiên khi reset đổi đúng cạnh clock
Khi reset đổi đúng cạnh clock, cần biết phép cập nhật nằm trong Active hay NBA và điều kiện disable được xét tại đâu. Không suy thứ tự thực thi từ vị trí hai block trong file.
Ví dụ trong bảng tránh điểm tranh chấp: reset lên tại 12 ns và xuống tại 23 ns, tách khỏi các cạnh 5, 15, 25 ns. Nó chưa giải quyết mọi cách release reset hoặc trường hợp X/Z.
Thêm $sampled(rst) vào điều kiện disable cũng thay đổi câu hỏi đang kiểm. Hãy xác định ý nghĩa mong muốn trước khi đổi biểu thức.
Bốn lỗi thường gặp khi kiểm reset
- Dùng gating antecedent như thể nó xóa nghĩa vụ cũ.
- Xem nghĩa vụ bị hủy là một lần đáp ứng thành công.
- Chỉ thử reset trước khi start, chưa thử reset giữa lúc đang chờ.
- Hủy quá rộng khiến lỗi thật sau reset bị bỏ qua.
Một bài kiểm reset cần theo dõi trước reset, trong lúc có nghĩa vụ, sau release và deadline của yêu cầu mới.
Tự phân tích việc hủy và đáp ứng
- Nếu bỏ
disable iff, nghĩa vụ từ start tại tick 1 sẽ kết luận thế nào? - Nếu done xuất hiện sớm hơn deadline một tick, điều đó đã đáp ứng yêu cầu “đúng hai tick sau” chưa?
- Vì sao phải thử riêng xung reset nằm hoàn toàn giữa hai cạnh?
- Cần giữ một lỗi sau reset để phát hiện điều gì?
Kiểm tra
Bằng chứng kiểm chứng
Expected tính trước chạy: DISABLE IFF CHECK samples=10 starts=3 done_samples=1 reset_pulses=1 disabled_failures=1 disabled_mask=128 gated_failures=2 gated_mask=136 time_ns=100. Main dùng Verilator 2-state và không dựa vào pass-action counter để đại diện cho cancellation.
Lỗi tại tick 7 có chủ đích xác nhận checker đã hoạt động sau reset. Mask giữ được thời điểm vi phạm, còn các counter stimulus/time giữ được scenario đang kiểm. Không dùng nhãn simulated của main để nâng probe giữa hai cạnh thành supported.
Phản ví dụ còn giữ: xung reset 12–13 ns có yêu cầu cancellation với một failure và mask 128, nhưng Verilator 5.050 quan sát hai failure và mask 136. Source parse/build được; kết quả runtime bị từ chối. Không đổi kỳ vọng, kéo dài pulse hoặc bỏ assertion để gọi là PASS. Ba mutant bỏ disable, đổi deadline và đưa done sớm đều bị bắt sau parse/build. Việc chạy đúng trường hợp reset 12–23 ns không chứng minh công cụ xử lý đúng abort giữa hai cạnh.
Nguồn và mức độ đối chiếu
- IEEE 1800-2023 SystemVerilog LRM, Concurrent assertion disabling, unsampled disable conditions and attempt lifecycle — chưa đối chiếu LRM. Chưa đối chiếu với văn bản nguồn (chưa mở).
- SystemVerilog Assertions disable iff — bản chụp resources.zip, Syntax; Why Gating the Antecedent Isn't Enough; A Concrete Example: Aborting a Check Mid-Flight; Common Beginner Mistakes. Trích dẫn; nguồn đã đọc các mục liên quan.
- Thí nghiệm nguyên bản B8.disable-iff, Clock-visible reset, deadline masks, three runtime mutants and retained between-edge cancellation failure. Trích dẫn; nguồn đã đọc toàn văn.
- IEEE 1800-2023 SystemVerilog LRM, Disabling versus sampled history — chưa đối chiếu LRM. Chưa đối chiếu với văn bản nguồn (chưa mở).
- IEEE 1800-2023 SystemVerilog LRM, Concurrent assertion attempt lifecycle and disabling — chưa đối chiếu LRM. Chưa đối chiếu với văn bản nguồn (chưa mở).
- IEEE 1800-2023 SystemVerilog LRM, Assertion disabling and attempt cancellation — chưa đối chiếu LRM. Chưa đối chiếu với văn bản nguồn (chưa mở).