Manifesto write-up
There are many commercially available tools to perform digital
simulation and they basically work in the same way: a simulator is synthesized
by mapping the entire digital system either at the gate level or behavior
level into a piece of runnable code, then one executes the simulator to
check for the behavior of the design. We name this type of simulator synthesis
methodology as "whole circuit to one-simulator" approach.
To cope with the complexity of a large digital system, the "whole
circuit to one simulator" approach is somehow insufficient due to
its lack of organizational principal that can guide designers in formulating
the overall design. We need strategies to help us structure large systems
so that they will be modular, that is, so that they can be divided "naturally"
into coherent parts that can be separately developed and maintained.
Our proposed approach is "component based" and it is
particularly appropriate to the construction of design for a digital systems.
For each module in a digital system, we construct a corresponding computational
object called "component" which encapsulates the behavior of
that module, or in other words, a component is capable of "self-simulating".
Our hope in this approach is that extending the model to accommodate new
physical module will require no strategic changes to the overall design,
only the addition of the new symbolic analogs of those modules—components.
If we have been successful in our system organization, then to add a new
feature or debug an old one we will have work on only a localized part
of the system.
According to our current model, there are two kinds of components
in our simulation system: base components and high level components. Base
components possess behavior corresponding to the function modules at the
bottom level of the abstraction hierarchy of a physical system; they are
indivisible entities and can be thought of as the "bricks" of
the complete simulation system. If we knit these "bricks", that
is, we pack base components and regard the collective behavior of these
base components as the behavior of a single entity, we then have high level
components. However, such "abstracting" is not going to end here,
obviously, we can keep building one level of abstraction on top of another,
until we have a abstraction "pyramid". To complete the definition
of the a high level components, we claim that except the bottom part of
such a abstraction "pyramid"(certainly we call the bottom part
"base component") , components at all other levels are high level
components. In particular, the one at the peak which encapsulate the overall
behavior represents the entire design.
Components "talk" with each other. One type of interaction
occurs within the same abstraction level-- a component is "driving"
and being "driven" by its neighbors. To illustrate this, let’s
say component A, component B and component C are at the same level of abstraction,
A gets input from somewhere and computes the output; B brings in this output
and does the computation to drive C. We define the output from C as the
output of the whole system consisted of A, B and C. It is important to
point out that the topology of the system is simplistic and can be, in
reality, much more sophisticated. Another type of interaction is between
two adjacent abstraction level. In the above system, if we wrap A, B and
C into a high level component called SUPER, then SUPER must be able to
define the computation sequence: it orchestrate A, B and C when to compute
and where to look for inputs. We need a piece of data structure called
"scheduler" to serve this purpose.
When one wants to perform simulation, one feeds the inputs to
the top level component. The top level component accepts the inputs, distributes
the inputs and scheduling messages to lower level components. Lower level
components receive their assignments and pass tasks to next lower level.
Eventually, the inputs will reach the base components and it is the base
component that does the real simulation work. All other levels of components
serve as messaging and controlling nodes.
Certainly, we keep all the components in a single machine and
do the simulation locally; however, one of the most important features
of our component based simulation is its ability to distribute the components
across the network. Components taking on many machines interconnected via
network transform the whole network into a giant multi-processor computer
and if the efficient leverage of the computing resource is realized, we
might greatly improve the simulation performance. Such kind of distributed
simulation also empower electronic designer new methodologies that was
never before available: the full-fledged design can be wrapped into a super
component and placed on the world wide web to make it available to third-party
designers or potential OEMs, designers will have the option to mix and
match different components and run click-button simulation from any remote
client machine, while the actual computation is totally done distributedly.
To conclude, component based simulation provides a more viable
methodology for digital simulation than the traditional "whole circuit
to one-simulator" approach. What we plan to offer is a working distributed
component based simulation system, a set of APIs that will facilitate the
construction of this type of simulation system and a GUI component composer
which will enable user to build and wrap component visually. Our language
of choice is Java, the language that offers cross-platform software environment
intended for distributed systems.