Project Summary
Distributed Hierarchical Digital Simulation
Zhang Zhengyu
Objective
The objective of this project is to prototype the next generation "component"
based electronic design system using pre-built design objects with embedded
simulation capability. Also we would like to demonstrate the feasibility
and evaluate the usability of such a system.
Introduction
A coding-debugging loop best describes how one does design today: coded
in HDL, a design will have to go through a sequence of simulation and revision
processeses until it is fully validated. Consequently, the availability
of the simulator, as well as the computing resources necessary to support
the simulation, has become burdensome. Furthermore, the traditional approach
does not address the collaboration aspect of the design well because early
designs did not require a collaborative environment . Finally, there hasn't
been a good methodology for designers to efficiently incorporate the previous
work into existing designs that are being developed.
Our approach based on the WELD paradigm aims to reduce the complexity of
the design process by hierarchically constructing a top level
design using many build-once and use-many-times distributed design objects
. With our new approach, the reuse of the old design is greatly simplified:
swapping components does not require significant modifications of other
part of the component hierarchy. Because components are distributed across
the network and the "simulator" is embedded into each component, the verification
of the complete design might be as easy as bringing up the Netscape browser
and pushing a button to do a simulation.
Architecture Overview
The 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 an 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抯 say components A, B and 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. So in every component
we need a piece of data structure called "scheduler" to serve this purpose
and because of that, every component only has the concept of "local time",
where the local time of each component is determined solely by messages
passed to it in the normal course of the simulation.
Based on the illustration of the previous example, a component must be
able to perform certain functions. First, it must be able to describe its
own behavior subject to external inputs. Second, it should be able to communicate
with other local or remote components. Besides, there are also some special
cases: for example, one component might retrieve data from and return data
to the high level component, in that case, a high level component is treated.
Last, it should be able to validate its own status and be aware of the
input source and output destination according to the the "component map",
which will be clarified later in the article.
For a high level component, the scheduler is needed to specify the interdependency
between all the sub-components in the same way how the corresponding hardware
modules be assembled together. We design the scheduler for the following
purposes: it must have the knowledge of where all the sub-components are
and be able to validate that information; it also should be able to interact
with users because users specify the formation of the component hierarchy.
At the back end, the design is translated into a component map and
distributed to all the lower level components. The component map for a
particular component stores the information about the addresses of all
the components of the same level and marks the source and the destination
of the data. Such kind of organization transforms many independent "unconscious"
components into "siblings".
The top level component reads inputs and feeds them to the sub-components.
Such a process will recurse until the base components have been reached
( base components are places where the real computation is done.) Then
results will merge back up until the top level is reached again and the
output will get back to the user at that level.
| Component Address
|
name
|
source
|
destination
|
Function Description
|
| win.eecs.berkeley.edu
|
A
|
B
|
D
|
Logic Unit (32 bit)
|
| deep.eecs.berkeley.edu
|
B
|
D
|
* external
|
SMD (32 bit)
|
| u21.cs.berkeley.edu
|
C
|
* external
|
D
|
D cache (32 bit)
|
| u23.cs.berkeley.edu
|
D
|
B
|
A
|
Bypass unit (32 bit)
|
Table I: A possible implementation of the component
map
Middleware consideration
Imagine that there are clusters of high power machines dedicated for simulation
purposes, and there are thousands of users running processes through the
world wide web. We
Object Duplication to Boost Performance
If test vectors are independent of each other we can duplicate the entire
hierarchy and place it onto the another machine cluster. By doing that,
we are able to reduce the simulation time into half.
Part of our motivation of using Java to implement our simulation system
is because Java
RMI
For a basic communication mechanism, the Java language supports sockets,
which are flexible and sufficient for general communication. However, sockets
require the client and server to engage in applications-level protocols
to encode and decode messages for exchange.
An alternative to sockets is Remote Procedure Call (RPC), which abstracts
the communication interface to the level of a procedure call. Instead of
working directly with sockets, the programmer has the illusion of calling
a local procedure.
RPC, however, does not translate well into distributed object systems,
where communication between program-level objects residing in different
address spaces is needed. In order to match the semantics of object invocation,
distributed object systems require remote method invocation or RMI. In
such systems, a local surrogate (stub) object manages the invocation on
a remote object.
The Java remote method invocation system has been specifically designed
to operate in the Java environment. While other RMI systems can be adapted
to handle Java objects, these systems fall short of seamless integration
with the Java system due to their interoperability requirement with other
languages For example, CORBA presumes a heterogeneous, multilanguage environment
and thus must have a language- neutral object model. In contrast, the Java
language's RMI system assumes the homogeneous environment of the Java Virtual
Machine, and the system can therefore take advantage of the Java object
model whenever possible.
However, the increasing popularity of Java has made this less a problem
and under some circumstances, this might even be the advantage because
it is much easier to manage communication between distributed objects based
the identical language model.
JAVA BEAN
JavaBeans is the platform-neutral, component architecture for Java. It's
the ideal choice for developing or assembling network-aware solutions for
heterogeneous hardware and operating system environments--within the enterprise
or across the Internet. In fact, it's the only component architecture you
should consider if you're developing in a Java environment.
Sample Source
Class Design_Object extends thread {
Design_Object(Scheduler s){
}
get_component_map_from_scheduler(){
}
get_data(){
if (local) {pass_variable_locally()}
else {open_socket_connection()}
}
put_data(){
if (local){pass_variable_locally()}
else {open_sock_connection()}
}
outputs simulate(inputs){
}
is_alive(){
}
main (arg[] argv){
put_data(simulate(getdata()));
}
The scheduler has the knowledge
of where all its children are and is able to coordinate the data flow between
children. We should be able to interact with the scheduler, decide how
the hardware will be assembled and the process would be like bringing up
a schematic editor and grabbing components from the library and wiring
them together. At the back end, it is the scheduler that is being edited.
The scheduler should validate all the children by remotely invoking the
"is_alive()" method of every child. It builds a component map in which
the siblings are listed according to its network address and the component
map should be sent to every child so that every child knows to whom it
should relay the data to.The scheduler is also aware of the data type mismatches.
It is important to point out that the scheduler only plays a role at the
setup stage of the simulation system. The source code will be like follows:
class Scheduler {
scheduler (Design_Object A, Design_Object
B, Design_Object C){
validate(A,B,C);
issue_component_map();
}
validate(Design_Object A, Design_Object B,
Design_Object C){
}
issue_component_map();
}
}
A high level component is built on top of some base component and is also
an instance of design object. It takes care of the I/O and dispatches data
to its children . Its simulation method doesn't have real meat but just
a stub.
Class Boss extends Design_Object
{
Design_object A =new Design_object("A");
Design_object B =new Design_object("B");
Design_object C =new Design_object("C");
Scheduler s = new Scheduler(A,B,C);
Boss(Design_object A,Design_object B, Design_object C){
}
get_component_map_from_scheduler(){
}
outputs simulate(Input inputs, Design_object
A,Design_object B,Design_object C){
C.simulate(B.simulate(A.simulate(inputs)));
}
main (arg[] argv){
put_data(simulate(getdata(),A,B,C));
}
}
2. imple
Progress Achieved
In the past three months, I have made progress on several areas which include:
-
Literature survey on the distributed object technology like CORBA and
DCOM.
-
Singled out Sun's JDK1.1 RMI as the API of the choice
-
Outlined a detailed implementation at pseudo-code level
-
A working demo of a component-based simulation environment: two levels
of abstraction built on top of some hand-coded components.
Future Plans and Projected Milestones
For the coming quarter, I will be implementing such a design system based
on existing specification. As a new component technology, JavaBean enables
fast application prototyping using pre-built components so that objects
could be manipulated visually. It will be interesting to see how we can
incorporate this technology into our system.