Blog

Thoughts on IC development, EDA, and hardware design languages.

SystemVerilog: bet you didn’t know you could…(Part 1)

Posted by: Brad Quinton | Posted on: April 29th, 2014 | 4 Comments

Share on LinkedIn79Share on Facebook0Tweet about this on Twitter0Share on Google+0Email this to someone

SystemVerilog has been around for awhile now (after all, simple math shows it has been 9 years since the original 2005 standard, with years of committee work before that…). And, while it is now clear that it has become a completely mainstream design and verification language with support now coming from across the board in the EDA world and more recently even from the FPGA vendors (Altera Xilinx ), the language is large and complex. There is still a lot of interesting corners that are not so obvious to even the experienced hardware designer.

At Invionics we spend a lot of time investigating the strange corner cases of SystemVerilog (VHDL too, but that’s for another post), and having also done a lot of ASIC design and verification in the past, we are always fascinated by the interesting things that you can do with the language. We’ve had many excited discussions around the white board upon discovering some new language subtlety … so we’ve decided to start sharing them on our blog.  Hope you enjoy!

Modules in Modules! And then modules in those modules…?

Interestingly, in Section 23.4 of the IEEE 1800-2009 standard you will see that SystemVerilog supports nested modules. Here is what this looks like:

module top ();
  wire a, b, c;
  module nested;
    assign c = a & b;
  endmodule
endmodule

or, even:

module top ();
  wire a, b, c;
  module nested;
    module nested_more;
      assign c = a & b;
    endmodule
  endmodule
endmodule

or, maybe more understandably:

module top ();
  wire a, b, c;
  module nested;
    assign c = a & b; 
  endmodule
  nested nested_i ();
endmodule

So you see that a nested module has access to wires and regs from it’s parent, but not the other way around, which would be really weird!

But why, you ask? 

Well, according to the spec they are for “logical partitioning of a module without using ports.”  Which explains the scoping behavior, but, of course, the spec then goes on to describe how you can define ports on a nested module…. so not a 100% consistent, but there you go.

Taking a step back, you realize that it might be nice to have a middle ground way of organizing the contents of a module, especially if you have a large structural design you need to manage.  I’ve often gone down the road of defining a bunch of small modules in one file to accomplish the same thing…. The other thing to note is that VHDL also has much the same idea with the ‘block’ construct (IEEE Std 1076, 2000 , Section 9.1), so it is not a new idea.

So there you have it.  You can now amaze your friends and family with your knowledge of esoteric HDL specifications. It is also interesting to see if your SystemVerilog tools support this feature. Of course, I tested ours before the post ;-)

Do you have an aspect of SystemVerilog that you think is particularly weird? Or a non-obvious part of the language that you have put to good use?  If so, we’d love to hear about it. Leave us a comment below. I can promise it will get us talking.

- Brad.

4-Ways-to-Build-Best-in-Class

Share on LinkedIn79Share on Facebook0Tweet about this on Twitter0Share on Google+0Email this to someone

Comments (4)


  1. Naveen Kumar - Reply
    November 27, 2014

    Can you write something on creating array of module instance, generate commands?

    • Brad Quinton - Reply
      November 28, 2014

      Sure, Naveen. We’ll add it to the queue…

  2. Shalom Bresticker - Reply
    January 7, 2015

    You might declare a nested module with ports if you wanted to instantiate it more than once. I think that most tools today do not support nested modules. I think most tools don’t even support the ‘alias’ construct.

    • Trent McClements - Reply
      January 7, 2015

      You are correct Shalom, tool support does lag the SystemVerilog LRM, even today. The language is quite complex and a variety of syntax constructs won’t work across all tool vendors. Still, it is interesting to see what the language enables and how you can use these features. The tools will catch up to the LRM eventually!

Leave a Comment