News

Language Features for Practical Reuse

From the discussion on this page, it is clear that a concurrent-structural specification language makes it easier to model hardware. However, such a specification style also forms the basis for component-based reuse in a structural modeling system. A more detailed argument for why this is so can be found in the following papers: A concurrent-structural modeling language is not sufficient to allow component-based reuse, however. A system also needs:

Specification Language Features and Abstractions

This section gives an overview of the features and abstractions that allow a specification language to attain the capabilities listed above. Clicking on the heading for any of the sections below will link to a detailed discussion of the concept.

Realize that the concepts below work synergistically to provide a system that provides the capabilities. Removal of one of the features diminishes or eliminates a capability from the overall system. For example, a structural modeling system goes a long way to providing clear descriptions and reusability, but flexible, composable components that are highly reusable also require component polymorphism and computation customization. On the other hand polymorphism and component customization don't get us much reusability of the type described above without a structural modeling system.

Data Abstraction

At the high-level, the specific bit pattern used to represent data is not relevant and can requiring a particular bit encoding for data limits reusability of components. Data abstraction is simply using high-level data types that abstract the underlying representation to represent data in the system.

High-level data types immediately improve the flexibility of components since the bit encodings are irrelevant for the high-level model. The flexibility and convenience provide the foundation that makes these other features usable.

Component Polymorphism

A polymorphic component is one that can manipulate different data types depending upon how it is instantiated in the system. It is a very powerful concept for modeling since many different designs often use similar components with differing data types. For example, processor microarchitectures use many components that consist of tables, queues, or queues that are also like tables. The differences in the functionality arises in how the structures handle timing, a bit of custom logic based on the data stored, and the actual data type of the values stored.

Component Computation Customization

Component polymorphism can greatly aid the environments in which a component can be used. However, if no mechanism to customize the computation based on the new data types is provided, then only components that do not manipulate the data (but only store it and pass it along) can benefit from the polymorphism in the system. A component computation customization interface along with polymorphism allows for far wider modular reuse of components in the system.

Component computation customization can also be used to specialize computation in ways that are not directly related to the choice of data types.

Parametric Scalability

Parametric Scalability is the ability to scale the interface "size" of a component based on parameters. For example, a reusable register file component should be able to have the number of read or write ports vary on a use by use basis. This can be done either explicitly, via a parameter for example, or implicitly, based on how many connections a user makes to a read interface.

Parametric Structural Composition

For even a minimum level of reuse, components should have parameters that can be set on a per-instance basis. This parameter can control sizing of regular data structures such as cache arrays and can even provide some of the other features listed here, such as computation customization.

During design, basic components will be combined in a model to provide more complex behaviors. Across designs that have similar complex behavior, modular reuse of the collection of components is highly desirable. This means that the language used to compose components into a model specification should also allow this composition of components to be controlled via parameters the customize the behavior of the component. For example, a memory subsystem component may be composed of cache components. Parameters on the memory subsystem should be able to control not only the size of the embedded caches but also the number of levels of cache as well as the delay for the cache lookups.

Simulator Abstractions

Since the model specifications under discussion will be compiled to simulators, there must be some way to specify what measurements should be taken during simulation. Data collection code is one of many different simulator artifacts that creep their way into model specification.

In order to keep model specifications a clear reflection of the hardware, mechanisms related to simulation, such as checkpointing and data collection should be kept as separate from the simulation as possible via simulator abstractions.

Compile-time Knowledge of Structure and Structure-based Analysis

Information on how to implement all the above features while retaining compile time analysis can be found in this paper.

Existing Modeling Systems

Not all of these features and abstractions listed here are novel. (Identifying that these particular concepts operate synergistically to provide more capabilities than the simple sum of the capabilities each concept provides in isolation is, however, a novel insight in high level modeling.) A summary of what features and abstractions other modeling systems provide is described here.

We have also implemented all of the above ideas and resolved many issues related to their implementation and interaction when developing the Liberty Simulation Environment. Our experience with this tool shows that the ideas greatly improve the speed with which systems can be modeled and increase clarity of model specification.