Non-Connected Ports

Unconnected Ports

Often some ports may be left unconnected, either intentionally or by accident. The following table lists the effects of various build options on unconnected ports. It shows the effects at build-time versus each option, and at simulation run-time, for various situations of unconnected ports. By default, any unconnected ports are automatically connected to null-terminators as a convenience. (Null terminators will absorb any inadvertent sends or receives on the ports.) Also by default, a warning notice is issued for each unconnected port. The -lenient mode suppresses the warning messages and controls verbosity only.

The table shows how -rigorous and -ncports can be used to find unintentially unconnected ports. When any ports are accidently left unconnected, -rigorous will not allow a successful build. The -ncports option is a compromise that will allow builds but will stop the simulation if a model ever attempts to use an unconnected port.

Table 1 - Effects of build-options on unconnected ports.

Case (default) -lenient -rigorous -ncports Run-Time

1. Port-name does not exist on any instance of this type

Build Error, fails w/message Build Error, fails w/message Build Error, fails w/message Build Error, fails w/message NA

2. Non-Existent Port from Variable

Ok Ok Ok Ok On attempt to Send out non-existent port-name, simulation Stops w/Error Message.

3. Inconsistent Connections

Automatically adds null connections w/Warnings Silently adds automatic null connections Error message, fails build Adds NC connections automatically Ok, unless -ncports was used and Send is attempted on unconncted port, then sim stops w/Error message.

4. Explicit Nulls

Ok Ok Ok Ok Ok (Inadvertent Sends on null ports absorbed without notice)

5. Explicit NC's

Ok Ok Ok Ok Ok, unless model attempts Send on NC port, simulation will Stop w/Error Message.

(* Ok = Build or Sim proceeds normally without warning or error messages, or not applicable.)

-lenient controls warning message output only. It can be used in combination with the default mode, or in combination with -ncports. The -lenient option is considered the opposite of -rigorous, and each is used exclusive of the other.
-ncports can be combined with -lenient to suppress warning messages. The -ncports option could be combined with -rigorous, but the result is meaningless because -rigorous overrides by stopping the build on any unconnected ports.

Discussion:

Case 1: Port-name does not exist on any instance of this type - This is the case where a literal port-name is used (in quotes) in a SEND or RECEIVE of a behavioral model, but no instance of the given device-type ever has a port of that name connected to it. This error is detected at build-time regardless of the option settings.

Case 2: Non-Existent Port from Variable - This case is similar to Case-1 above, but instead of a literal port name that could be checked at build-time, a port-name variable is used in a SEND or RECEIVE of a behavioral model. At run-time, the port-name variable evaluates to an unknown port-name. This error is detected at run-time and stops the simulation with a fatal error message. (It cannot be detected at build-time under any options.)

Case 3: Inconsistent Connections - This is the case where models of the same type do not have all the same port connections. By default, this is treated as a potential missing connection. A default warning is issued and the missing port is terminated with a null connection. Since this situation is often intentional and ok with newer mdoels, these warnings can be suppressed by the -lenient checking option. Inadvertent sends or receives on the given port will be absorbed/ignored. In other situations where inconsistent ports should be considered errors, use the -rigorous option. Finally, in situations where unconnected ports are ok, but should not be used, then the -ncports option terminates unconnected ports with explicit NC terminators. Any attempted receives or sends on NC ports result in a fatal error message at simulation run-time.

Case 4: Explicit Nulls - Explicitly terminating ports with Null connections avoids build-time warning/error messages regardless of option settings, and causes any sends or receives on the given port at run-time to be absorbed/ignored. (These ports will be shielded from the -ncports option.)

Case 5: Explicit NC's - Explicitly terminating ports with NC connections avoids build-time warning/error messages regardless of option settings, but causes any sends or receives on the given port at run-time to raise a fatal error message and stop the simulation.