RE: [sv-bc] Array query functions on interface port and instance array

Not only are instance arrays not unpacked arrays, they are not even true
arrays.

Arrays of instances include arrays of module instances.  That means that
their elements are not guaranteed to be homogeneous, which is an essential
property of a true array.

Due to the existence of defparams, different instances in an array of
module instances could be parameterized differently.  And due to the
existence of generates, this means that everything in the module
(except the ports) could be different between instances.  Therefore,
arrays of module instances are not guaranteed to be homogeneous.

Being homogeneous is what gives true arrays their most useful property:
the ability to select elements using an index computed at runtime.  Since
the elements are homogeneous, operations on the element are independent
of which one is selected.  The fact that instance arrays are not homogeneous
is the reason that Verilog does not allow them to be indexed by anything
but a compile-time constant.  The index is more like part of a compiler-
generated name for an instance than it is like a true array index.

Note that an array of virtual interfaces is a true array, since all of
the elements are required to have the same data type (a virtual interface
with a particular parameterization and modport).

If it is not legal to apply a defparam into an interface, and there is
no other way for the instances in an array of interface instances to get
different parameterizations, then an array of interface instances might
always be homogeneous.  In that case, the language could be extended to
define arrays of interface instances as unpacked arrays (effectively
being a constant of the same type as an array of virtual interfaces).
But right now, the LRM doesn't make this distinction between arrays of
interfaces versus modules.

I can also see some other possible extensions to the language that would
allow arrays of interfaces to be heterogeneous.  The language already
allows an array to be connected to a non-array port of an instance array,
with the meaning that each instance is connected to an element of the
array.  I can imagine the same being allowed for the parameter override
of an instance array: specifying an array parameter for the override of
a non-array parameter in the instance array, with the meaning that each
instance parameter is overridden by an element of the array parameter.

Another possibility could arise when configs are extended to handle
instance arrays.  If separate instances in the array can be configured
independently, then they could be bound to different interface definitions,
or to different parameterizations (using the config extension in the 2009
LRM).  If we want to guarantee that arrays of interfaces are homogeneous,
the extension to configs would have to ensure that all instances in the
array were configured identically.  For example, the instance names might
leave out the index for an instance array, and always apply to the entire
array.

There might be a trade-off between the advantages of being able to treat
an array of instances as an unpacked array, versus the advantages of being
able to parameterize or configure the elements of the array differently.


Now I will return to the original question.

An instance array is not an unpacked array, so the LRM does not allow the
array query functions to be applied to it.

I don't see a technical problem with allowing the array query functions
to be applied to instance arrays, as well as to unpacked arrays.  The
size and bounds are static information, and don't require run-time
indexing into the array.  So this capability could be added.

This still wouldn't allow a lot of the other capabilities of unpacked
arrays to be applied to instance arrays.  For example, most of the array
methods involve run-time iteration and indexing into the array, so they
could not be applied to instance arrays.

Steven Sharp
sharp@cadence.com


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