Blog

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

SystemVerilog Insights Series: Using the Port Connection Shortcuts

Posted by: Trent McClements | Posted on: January 6th, 2015 | 13 Comments

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

How much time have you wasted pulling interconnect through your hierarchy? I always found this very tedious, especially when the connections were obvious throughout a design hierarchy – clk goes to clk, rst to rst, etc. With SystemVerilog we now have a couple of quick shorthand methods for doing these type of I/O connectivity assignments. While they are convenient to use, we should also be aware of the shortcomings, limitations and consequences of their usage.

The SystemVerilog LRM has added implicit connections for named ports, or the .name and .* methods. Let’s look into the .name notation today and we’ll delve into the .* notation in another post. To start with, let’s assume we have an adder module:

module addr (
input [1:0] in0 = 2'b00,
input [1:0] in1 = 2'b00,
output [2:0] sum);
assign sum = in0 + in1;
endmodule

We can instantiate this in a toplevel module using .name notation as follows:

module top (in0, in1, sum);
input [1:0] in0, in1;
output [2:0] sum;
addr addr (.in0, .in1, .sum);
endmodule

From a high level you can think of the .name notation as the same as explicit named port associations (that is, .port_name is equivalent to .port_name(port_name)) with a couple of caveats:

1) Implicit .name associations will only work when the port name and data type are equivalent.
2) There is no implicit net created from an implicit port connection.
3) When the ports have different net types, what was a warning using explicit named port associations (i.e. supply0 connected to supply1) is an error in the implicit connection case.

Fortunately, if any of the above give you issues you can mix notations. Say in our example the module top only has one four-bit input instead of two two-bit inputs. The .name notation would match on the output, “sum”, but not the inputs. An explicit named association would have to be used for in0 and in1:

module top (in0, sum);
input [3:0] in0;
output [2:0] sum;
addr addr (.in0(in0[1:0]), .in1(in0[3:2]), .sum);
endmodule

Mixing notations also gets us out of a sticky spot with respect to default values on ports. When using .name notation the SystemVerilog parser will not use the instantiated modules ports default value. In our example the “addr” module’s default values of 2′b00 on the “in1″ input is not sufficient to avoid error in the following instantiation case::

module top (in0, sum);
input [1:0] in0;
output [2:0] sum;
addr addr (.in0, .in1, .sum);
endmodule

Note that there was no matching “in1″ port on the toplevel module. To use the default value of addr’s in1 port you would need to instantiate addr using mixed notation as follows:

addr addr (.in0, .in1(), .sum);

Personally, I’m a big fan of the .name notation simply because it preserves the idea of self-documenting code. I find the explicit listing of an instances ports helps to give an idea of the instances functionality and helps to clearly describe how it is connected in the instantiating module. Of course, the .* notation, along with the classic explicit port connections, still have their place but I like the happy medium of .name in terms of brevity and functional clarity. I’d be curious to hear if you are using .name notation and why or why not!

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

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

Comments (13)


  1. Shalom Bresticker - Reply
    January 7, 2015

    My users say that debug tools today don’t work well with .name and even worse with .*.
    If you have .name(name), then you can select either .name or name in the Design Browser and thus select either the external connecting wire or the internal port and choose the appropriate function that you want to do. If you only have .name, you can’t distinguish between them. If you have only .*, you can’t even go to a specific port.

    • Trent McClements - Reply
      January 7, 2015

      That’s an interesting point I and think it stems from one of the subtleties of the .name syntax — no implicit net declaration. Regardless, the .name and .* notation are intended to help the writers of the RTL. I think it lands a bit in the laps of the tool vendors to make sure that the users of the code (in your case the debug tool users) shouldn’t be hindered by the syntax, especially when the intent of the syntax is quite clear!

  2. Cliff Cummings - Reply
    January 8, 2015

    The .* port connection syntax is one of the coolest design enhancements in SystemVerilog. It is based off of Intel’s IHDL language, which had a very similar capability for both simulation and synthesis. Using .* imposes additional checks that did not exist with Verilog named port connections, ie – Verilog “port-size mismatch warning” and with .* this is an error that must be corrected (this was almost always an error in Verilog). No 1-bit implicit wires was a requirement by the vendors and we gave them that concession to get the rest of the .* capabilities. In the future, we could drop the 1-bit wire declaration requirement without breaking any backward compatibility.

    The Verilog EMACS mode can expand the .* ports just like it does for autoinst, which greatly simplifies debugging when necessary. Debug tools should add a feature that allows an engineer to select an instantiation, then click a button to expand the ports for debugging purposes.

    The .name syntax was a compromise for engineers who were afraid of .* (I personally hate the .name syntax). I am also not a fan of the default input port value SystemVerilog enhancement that you have referenced in this posting.

    I have a whole paper on this topic at: http://www.sunburst-design.com/papers/CummingsSNUG2007Boston_DotStarPorts.pdf

    Regards – Cliff

    • Trent McClements - Reply
      January 8, 2015

      Hi Cliff! Thanks for the thoughtful comment. I’m in agreement with you on almost all points, but I still like the .name syntax. Undoubtedly I was one of those designers who had a bit of fear of .* syntax. :) I preferred a more explicit coding style, undoubtedly fostered by my years coding VHDL! With that in mind, I was also never a big fan of implicit wire declaration of any sort other than with respect to ports. Certainly the implicit 1-bit wire creation was something I found to be a bit of a lazy shorthand that tended to cause more problems than it solved. Totally agree with you on default input ports values — I never used them. They are part of the language though, and did relate to the topic, so I figured it warranted to discuss in the post.

      We were actually discussing the same idea with respect to design browser support for the .* syntax here at Invionics yesterday. A click-to-expand view of .* would be brilliant and solve the issues related to usability of the notation in debug environments. Hopefully we see this from the vendors!

  3. Alex Moreno - Reply
    January 8, 2015

    I agree with Shalom Bresticker because it´s an important and consistent rule for debug tools to identify interconnections when we use .name() … and I also agree with Trent McClements because it´s a cool enhancement for RTL writers when they have a lot of signals to connect…
    However I prefer to use the first one notation and use a simple script (perl, python, …) to make an automatic and secure connection or to use Cliff´s recommendation… Other option is to use systemverilog interface to reduce the writing effort during the connection.

    • Trent McClements - Reply
      January 8, 2015

      Hi Alex, thanks for the comment! I agree that a script or tool to expand the .* notation is not a bad approach. Generally speaking these mappings are quite simple as the names/types have to match. To get into the more interesting case of connecting instances (where wires would also have to be declared) or more advanced I/O connectivity would likely require a SystemVerilog parser and syntax beyond .*, like regular expressions, as Cliff mentioned. I encourage you to check out our Invio platform as it really helps when writing these type of tools and scripts.

  4. Cliff Cummings - Reply
    January 8, 2015

    Interfaces have limited value. They are terrible for general purpose interconnect. My guideline on interface usage is, if you have 5 or more signals/buses that go between two or more blocks, you can use an interface, otherwise, don’t waste your time. Standard buses between multiple blocks are a good candidate.

    Interfaces, originally added to SystemVerilog as a design construct, have actually proven invaluable to tie a class based testbench to a DUT.

    • Trent McClements - Reply
      January 8, 2015

      I do like interfaces, especially for standard busses, but agree with Cliff that they need to be used appropriately. No need to add overhead without good reason!

  5. Cliff Cummings - Reply
    January 8, 2015

    BTW – what is missing from .* port connections is limited regular expression capabilities, like what is found in the Verilog EMACS mode. If we could use some regular expressions with .*, we could consistently reduce top-level ASIC & FPGA module declarations by upwards of 70%, and get stronger port-type checking.

    • Trent McClements - Reply
      January 8, 2015

      Great idea! But if we designers thought .* syntax was scary imagine the pushback from connectivity via regular expression matching… :) The tie-in to stronger type checking of the .* syntax is really a big value-add (as you mentioned in a previous comment). A cool spot tool would be something that reads in the regular expressions and creates the explicitly connected, or the minimal .*/.name/explicit non-regular expression-based, instantiation. Of course, you could expand the regular-expression connectivity to instance-to-instance connectivity rather than just instance-to-port.

  6. Kevin Cameron - Reply
    January 9, 2015

    .* was unnecessary given the other enhancements, but it arrived in parallel at the committee, so squeeked through. It results in a requirement for prototypes for tools that can’t see the whole design, so all together it’s an unnecesary deathtrap (being hard to check).

  7. Pingback: Using the .* SystemVerilog Syntax | Invionics

  8. Charie - Reply
    February 21, 2016

    What a very neat idea for a social neotwrk! The learning and excitement that this fuels for music education is sure to be valuable. I wonder if it is available for those outside of Australia?

Leave a Comment