{"id":274,"date":"2009-05-07T13:06:16","date_gmt":"2009-05-07T20:06:16","guid":{"rendered":"https:\/\/blogs.mentor.com\/nosimulation\/?p=2"},"modified":"2026-03-27T08:47:42","modified_gmt":"2026-03-27T12:47:42","slug":"programblocks","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/2009\/05\/07\/programblocks\/","title":{"rendered":"Are Program Blocks Necessary?"},"content":{"rendered":"

That’s a frequent SystemVerilog question I’m asked<\/a>.<\/p>\n

Program blocks came directly from donation of the Vera language to SystemVerilog by Synopsys<\/a> , and try to mimic the scheduling semantics that a PLI application has interacting with a Verilog simulator.\u00a0 So coming from a Vera background, program blocks make perfect sense and do help people transitioning from Vera to SV. But looking at SV from scratch, they are just extra language baggage.<\/p>\n

Who would have ever thought we\u2019d be having language wars within the same language! \ud83d\ude2e
\n<\/span><\/p>\n

As far as I can tell, a program block by itself only addresses two race conditions between the testbench and DUT, both of which are covered by using a clocking block by itself.<\/p>\n

    \n
  1. Erroneous use of blocking assignments for sequential logic. You have a race within your DUT regardless of the race between your testbench and DUT.<\/li>\n
  2. Erroneous use of non-blocking assignments in combinational gated clock logic. You may have a race within your DUT regardless of the race between your testbench and DUT.<\/li>\n<\/ol>\n

    As a user, if you don\u2019t understand why these create races within your DUT, you\u2019re going to have the same races within your testbench, and there\u2019s nothing a program block does that prevent races within your testbench. There lays the false sense of security of having a race-free testbench.<\/p>\n

    Using a clocking block by itself takes care of the same testbench to DUT races that a program block addresses, plus it takes care of the races caused by non-zero delay skews introduced by gate-level propagation. It does this by the use of the input skews for sampling and output skews for driving.<\/p>\n

    Now, in addition to the false sense of security, and the redundancy with clocking blocks, here are some additional reasons why I don\u2019t recommend using program blocks<\/p>\n

      \n
    1. If you have legacy Verilog testbench code, sometimes you want to share legacy BFM tasks by having your \u201cclass\u201d based testbench call those BFM tasks. You\u2019re going to run into nasty timing problems if that task was designed to be scheduled in the active region, and now is scheduled in the re-active. Sampling will be off by a clock cycle. You\u2019ll have even nastier problems if some tasks are called from a program block, and other are still called from a module.<\/li>\n
    2. One person\u2019s Design IP is another person\u2019s Verification IP. At the system level (ESL), there is less of a distinction between models written to represent higher level abstractions of the design, versus part of a testbench. You can\u2019t have differences in scheduling just because one time it\u2019s called from a program, and another time it\u2019s called from a module. Same problem with C code called from a program block or module.<\/li>\n
    3. Unless you\u2019re an experienced Vera user, there is the unexpected surprise that your simulation exits immediately after the thread in your program block ends. Again this is an issue with mixing legacy testbenches, or mixed-language testbenches.<\/li>\n
    4. Most advanced users can barely understand the scheduling semantics of SystemVerilog even without using program blocks. Why introduce unnecessary complexity. Many other enviroments, like SystemC and VHDL have been in production for years without needing the kind of scheduling semantics the program block introduces. Quick quiz: How can you get an assertion pass and fail in the same time slot?<\/li>\n<\/ol>\n

      The SystemVerilog language has had many hands involved with its development, including yours and mine. I\u2019m not dismissing anyone efforts, but sometimes you have to take a step back and realize how bloated the language has become. Just because some feature exists in the LRM doesn\u2019t justify that it needs to be used. Let me tell you about virtual interfaces\u2026 \ud83d\udc7f<\/p>\n

      Dave Rich<\/p>\n","protected":false},"excerpt":{"rendered":"

      That’s a frequent SystemVerilog question I’m asked. Program blocks came directly from donation of the Vera language to SystemVerilog by…<\/p>\n","protected":false},"author":71589,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spanish_translation":"","french_translation":"","german_translation":"","italian_translation":"","polish_translation":"","japanese_translation":"","chinese_translation":"","footnotes":""},"categories":[1],"tags":[751,819],"industry":[],"product":[205],"coauthors":[979],"class_list":["post-274","post","type-post","status-publish","format-standard","hentry","category-news","tag-systemverilog","tag-verification","product-questa"],"_links":{"self":[{"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/posts\/274","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/users\/71589"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/comments?post=274"}],"version-history":[{"count":1,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/posts\/274\/revisions"}],"predecessor-version":[{"id":16744,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/posts\/274\/revisions\/16744"}],"wp:attachment":[{"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/media?parent=274"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/categories?post=274"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/tags?post=274"},{"taxonomy":"industry","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/industry?post=274"},{"taxonomy":"product","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/product?post=274"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/coauthors?post=274"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}