[sv-bc] More interface discussion

At the SV BC meeting of 30 August, I was asked to
document my proposals for enhancing interfaces
and modports more thoroughly, and include some
implementation notions. This email expands on
the presentation included in “All 1800
Requrirements Gathering Slides Feb 2010”.

My view of an interface is a convenient shorthand
for connecting modules in bus-structured hardware. As the LRM says:

At its lowest level, an interface is a named
bundle of nets or variables. … The ability to
replace a group of names by a single name can
significantly reduce the size of a description and improve its maintainability.

The bundle of nets has a single name, and creates
a namespace for the individual nets. The
disadvantage of this is that the individual nets
have hierarchical names when accessed from the module.

If the individual net names match those in a
module header, such an interface could
conceptually be used as a port connection. But
there would be a problem in matching a mixture of
interfaces and nets as port connections to a
module header just containing nets. So the port
declarations need to include interfaces to match
the port connections. Again, this means that the
individual nets have hierarchical names,
requiring modification of legacy code inside the module.

To accommodate design rule checking, the port
declarations should have directions, hence the
need for a modport. The modport capabilites were
extended to provide renaming of ports, just like
normal port declarations. Note that the use of a
generic interface in the port declaration does
not provide any checking until the ports are connected.

Since the modport should include a subset of the
interface wires, it was decided to put the
modport declaration in the interface to which it
applies. This was a mistake in the language
design. There is no separation of modport type
(for port declarations) and modport instance (for
port connections). This makes it hard to vary module connections in a bus.

Furthermore, the modport cannot be specified
without the interface type. This makes re-use
difficult, because the interface description may
change in trivial ways between the port
declaration and the port connection or they may
come from different vendors. With virtual
interfaces in testbenches, the interface name and
the parameter values are checked for
compatibility, as well as the modport
name. Defparam settings are not currently checked.

Lastly there is no way to pass parameters such as
bit width to a modport in a port declaration.

Jonathan Bradford has proposed allowing the
modport declaration to be a stand-alone item in a
package. This is one solution to the problems,
but it requires a substantial change to
SystemVerilog products and documentation.

My proposal is to first solve the modport
compatibility problem by weakening the type
checking so that a match between port declaration
and port connection is achieved if the types and
names of all modport items match. In
implementation terms, this could mean that the
symbol table of modport item names yields an
alphabetically sorted index to instance-specific
tables of pointers to the objects (nets,
variables etc.). For virtual interfaces, such a
table would have to be built for each new
assignment and cached for the next time. This
approach allows different interfaces with a similar modport to be compatible.

Then the type/instance problem can be solved by
allowing port connection modports to be in
sub-interface instances. The sub-interface
instances can be used to vary the connections.

These two enhancements do not require any syntax
changes. Parameterizing a modport in a port
declaration could be done in two ways, both
needing small syntax changes. Either a parameter
value assignment could be allowed in the module
header, or a modport keyword could be used as a
place holder in the module header and then the
modport could be instantiated with a parameter
value assignment. The latter syntax is also
convenient for giving local aliases to wires in
the modport, as Jonathan Bradford has suggested,
easing conversion of existing design IP.

So far we have just discussed wires and variables
in interfaces, but the LRM says:

Additional power of the interface comes from its
ability to encapsulate functionality as well as connectivity

The functionality comprises subprograms (tasks,
functions) and processes (always, initial, final,
continuous assignments, assertions). These can
be considered as being in a kind of module
instance in the namespace of the interface
instance, but should not normally be synthesized.

For the simulation algorithm, the interfaces,
modports and ports are collapsed out of
existence, leaving only variables, event trigger
connectivity, and processes. The interfaces and
modports, like the module hierarchy, only exist for debug and VPI.

For the synthesis algorithm, a modport in the
port declaration should be equivalent to a list
of individual ports. Therefore ref ports should
be illegal, and any task or function in an
interface called from a module should be moved
into the module provided this does not change the
functionality. If it does change the
functionality, the module is not synthesizable.

With these proposals, I believe that the intended
benefits of interfaces can be more easily
achieved, with a minimum modification to
software, test suites and documentation.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.