Parametric Scalability

In a structural system, components provide an I/O interface through the declaration of communication channels, often called ports. Users of a component instantiate the component and then connect the ports of the instance to other ports, usually on other component instances.

The number of requests-per-cycle that can be made on a component is determined by the number of messages that may be sent on a port in a given clock cycle. If the number of requests per cycle is fixed when the component is first created (instead of being allowed to vary on a use-by-use basis) then the reuse o the component is greatly limited. For example, a register file that only allows two reads per cycle for a simple 5-stage RISC processor would not be usable in a superscalar machine (since more than two read ports are required per instruction issued in a given cycle).

To address this block to modular reuse, the model specification system needs to provide a way for components to specify a scalable interface. This can be done by having communication channels that accept array data where the length of the array can be varied on a component instance by component instance basis. Alternatively, the system can allow the component to provide an array of communication channels with the same sizing property. Which system to choose depends heavily on the MoC used. This is discussed in the next section.

In the register file example, there may be a single port for read requests, but the port takes an array of requests. For the simple machine, the array would have size 2, for a superscalar machine, a larger sized array would be used. Naturally, the output ports that provide the data would be output an array and it would be scaled accordingly.

Synergies and Interactions

The choice as to the mechanism for parametric scalability is loosely dependent on the richness of the basic type system available for communication between component instances. For example if variable length arrays are supported, no additional support may be required.

The choice for the mechanism for parametric scalability on the other hand, is heavily dependent on the exact model of computation. For example, in a discrete-event (DE) system, arrays on the input ports are fine, though they can be inefficient if the values in different array elements stabilize at different times.

(This is a general problem with discrete event models and is often remedied by the use of triggers. Unfortunately, such triggers reduce the reusability of a component because they imply a specific control paradigm. This is an instance of the problem discussed in control abstractions, but is not related to the design of the system but to manual optimization of the model for simulation due to shortcomings in the model of computation.)

In a invoke-each-component-once MoC (described in a bit more detail here), this is not a problem and communication channels that define arrays work well, although this MoC has other problems that preclude modular reuse.

In a synchronous reactive MoC, on the other hand, an array of communication channels (called ports or signals) is distinctly different from a communication channel that accepts an array value. In one case, all the values in the array must stabilize simultaneously. In an array of signals, each signal may stabilize at different points within a clock cycle.

Beyond these concerns, the flexibility provided by parametric scalability is relatively independent of the presence or absence of other features, though its absence is more noticeable when it is the only barrier to reuse.