Kiểm tra IEEE Std 1800-2012 § 3.4 & § 24. Để biết mô tả đầy đủ về program khối.
Trong một thời gian ngắn, tóm tắt đầy đủ, một khối program:
- không thể không thể chứa
always thủ tục, primitive trường hợp, module trường hợp, interface trường (virtual interface và cổng interface được phép), hoặc program trường hợp khác.
- chỉ định lập lịch trong vùng Phản ứng. Điều này ngăn ngừa điều kiện chủng tộc.
- có một nhiệm vụ hệ thống bổ sung
$exit, kết thúc trường hợp program gọi nó.
- Mô phỏng sẽ chấm dứt khi tất cả các trường hợp
program đã thoát.
- chủ yếu là khối
module ngoại trừ như đã nêu ở trên.
Ý tưởng về khối program là tạo sự tách biệt rõ ràng giữa thử nghiệm và thiết kế. Trong các phiên bản trước của SystemVerilog (trước IEEE 1800), việc khởi tạo class thường bị giới hạn ở các khối program. Điều này nhấn mạnh việc phân chia thử nghiệm và thiết kế. Nó cũng làm cho các khối program quan trọng đối với các kỹ sư xác minh muốn sử dụng lập trình hướng đối tượng trong luồng của họ. Kể từ IEEE 1800, một class có thể được xác định và khởi tạo ở hầu hết mọi nơi. Kết quả là, các khối program trở nên ít đủ.
Hôm nay, ý kiến về tính hữu ích của khối program được chia. Từ một vài quy ước cuối cùng tôi đã thực hiện, xu hướng dường như có lợi cho việc bỏ rơi các khối program. Điều này là do những lợi thế có thể đạt được bằng các phương pháp khác. Lập kế hoạch trong vùng Phản ứng có thể được thực hiện với các khối clocking. Một mailbox, hàng đợi ([$]), hoặc mảng kết hợp ([*]) có thể được sử dụng để xử lý thông minh mô phỏng chấm dứt chạy nhiều thử nghiệm. Cá nhân, tôi vẫn thích sử dụng các khối program và sử dụng initial forever làm tương đương always khi cần. Nếu bạn dự định sử dụng UVM, thì một băng ghế thử nghiệm không phải là program có thể hoạt động tốt hơn cho bạn.
Cuối cùng, nó thực sự đi kèm theo sở thích phương pháp. Tốt nhất là bạn nên tự mình đánh giá và thử nó.
Cảm ơn! – dan