• Top
    • Documentation
    • Books
    • Boolean-reasoning
    • Projects
    • Debugging
    • Std
    • Community
    • Proof-automation
    • Macro-libraries
    • ACL2
    • Interfacing-tools
    • Hardware-verification
      • Gl
      • Esim
      • Vl2014
        • Warnings
        • Primitives
        • Use-set
        • Syntax
        • Getting-started
        • Utilities
        • Loader
          • Preprocessor
          • Vl-loadconfig
          • Lexer
          • Vl-loadstate
          • Parser
            • Parse-expressions
            • Parse-udps
            • Vl-genelements
            • Parse-paramdecls
            • Parse-blockitems
            • Parse-utils
            • Parse-insts
              • Special-note-about-blank-ports
                • Vl-parse-list-of-named-port-connections-2012
                • Vl-parse-udp-or-module-instantiation
                • Vl-parse-udp-instance
                • Vl-parse-list-of-ordered-port-connections
                • Vl-parse-list-of-ordered-parameter-assignments
                • Vl-parse-list-of-named-port-connections-2005
                • Vl-parse-list-of-named-parameter-assignments
                • Vl-parse-1+-udp-instances
                • Vl-parse-module-instance
                • Vl-parse-1+-module-instances
                • Vl-parse-udp-instantiation
                • Vl-parse-parameter-value-assignment
                • Vl-parse-named-port-connection
                • Vl-parse-named-parameter-assignment
                • Vl-parse-module-instantiation
                • Vl-parse-list-of-parameter-assignments
                • Vl-parse-list-of-named-port-connections
                • Vl-parse-param-expression
                • Vl-parse-list-of-port-connections
              • Parse-datatype
              • Parse-functions
              • Parse-datatypes
              • Parse-strengths
              • Vl-parse-genvar-declaration
              • Vl-parse
              • Parse-ports
              • Seq
              • Parse-packages
            • Vl-load-merge-descriptions
            • Scope-of-defines
            • Vl-load-file
            • Vl-flush-out-descriptions
            • Vl-description
            • Vl-loadresult
            • Vl-read-file
            • Vl-find-basename/extension
            • Vl-find-file
            • Vl-read-files
            • Extended-characters
            • Vl-load
            • Vl-load-main
            • Vl-load-description
            • Vl-descriptions-left-to-load
            • Inject-warnings
            • Vl-load-descriptions
            • Vl-load-files
            • Vl-load-summary
            • Vl-collect-modules-from-descriptions
            • Vl-descriptionlist
          • Transforms
          • Lint
          • Mlib
          • Server
          • Kit
          • Printer
          • Esim-vl
          • Well-formedness
        • Sv
        • Fgl
        • Vwsim
        • Vl
        • X86isa
        • Svl
        • Rtl
      • Software-verification
      • Math
      • Testing-utilities
    • Parse-insts

    Special-note-about-blank-ports

    Clarification regarding how empty module port lists are handled.

    The Verilog grammar contains a nasty ambiguity in handling arguments for module instances due to the possibility of "blank ports". Blank ports may be used to model an instantiation where a port is not connected to anything. For instance, after writing

    module m (a, b, c) ; ... ; endmodule

    In another module we may instantiate M, and not connect anything to port b, by writing something like this:

    m my_instance (a, , c);

    In the grammar, this causes the following ambiguity. Let Epsilon be the empty production, and note that:

    • Epsilon may be a valid ordered_port_connection. I think of this as a "blank port." Hence, list_of_port_connections may be Epsilon, and such a think might be thought of as a singleton list containing a blank port.
    • On the other hand, module_instance is said to take an OPTIONAL list_of_port_connections. If we omit the list_of_port_connections entirely, we might think of it it as an empty list containing no ports.

    So in the context of a module instance, what does Epsilon mean? Is it an empty list containing no ports, or is it a singleton list containing one blank port. The grammar is ambiguous.

    To explore how Cadence handles this case, consider the file blank.v, which explores this question and some related matters. The short of it (in particular see inst1a) is that Cadence seems to treat this as an empty list, with no ports. And a funny consequence of this is that one cannot instantiate a one-port module with a blank, unless named argument lists are used.

    Cadence's handling seems like the most sensible choice, and we are going to mimick it. Because this is somewhat delicate, we also include a number of unit tests at the bottom of this file.