(Still Under Construction)
written by Jimmy Zhang
The objective of this project is to prototype a component-based behavior
simulation system using Java. In comparison with the traditional "whole
circuit to one-simulator" approach, we partition the top level digital
circuit hierarchically and map the behavior of each function block into
a component. The behavior simulation at the top level can be emblemitized
as many self-simulating components concurrently interacting with each other.
We believe the simulation environment based upon our new approach is more
adaptive, scalable, and efficient in performing behavior simulation for
digital systems with various complexities at all abstraction levels.
There are two main applications for doing behavior simulation. The first is in the evalution of a new design. Information related to functional or logic correctness can be obtained from behavior simulation for high level specification or a VLSI circuit while breadboarding is impractical. A second application exists in the area of fault analysis. Here, the test engineer may desire information related to what faults are detected by a proposed test sequence or what is the operational characteristic of the circuit under specific fault conditions? These and other questions can be dealt with effectively by the process of fault simulation.
Event driven and native compiled mode are the most commonly used techniques to implement the simulator. When implemented using the event driven technique at gate level, the simulator is able to exploit the infrequency of logic switching in a digital circuit. Only the logic gates with changing inputs are processed. In this type of simulator, the names of the active logic gates are first placed inside a data structure called event list (scheduler) according to the chronology of the switching activities, then the simulation is carried out by processing the event list and performing the computation in the scheduled order. On the other hand, simulators implemented using native compiled mode technique is generated by mapping the behavior of a function unit into platform-specific machine level instructions which is directly executable by RISC hardware. As the result, such a kind of simulation sometimes runs 2 to 25 times faster than the simulation based on event driven technique.
In the traditional "whole circuit to one-simulator" approach, while the top level functional representation is usually hierarchical, the format at the lower level has mostly been flat. Designers may declare procedures for various types of building blocks; nonetheless, this hierarchical structure is collapsed by the preprocessor where the information about each atomic element has to be referred to globally (e.g. in the case of event driven logic simulator, the event list must keep the track of every single gate instead of the subcircuit). This extra indirection has made the plug-in of a existing design considerably more complicated.
Meanwhile, as the complexity of the design increases, it is no longer the case that one person or even a small team of engineers can accommodate such a task. Nowadays, more designs are being done in a distributed fashion-that is-a design project is divided into many small pieces and each member in a design team works on one part of it. This indeed causes difficulties for the testing engineers who want to verify the whole design because different parts must be integrated first. Imagine what happens when one part of the design is updated. The whole simulator created for old version has to be discarded and a new simulator needs to be rebuilt. What if updates occur really often? Much time is wasted on setting up the simulation instead of actually doing it. Hence, a methodology adaptive to rapid-evolving design style will play a crucial role in the overall success of the design. Also, the simulation performance has long been an important issue: a formal simulation with billions of input vectors easily takes several week to finish and any enhancement in the basic algorithm can achieve a significant amount of time-savings. Given the fact that there are numerous, heterogeneous computing resources distributed across the network, wouldn't it be nice to efficiently leverage them to improve the performance?
We claim that our new approach offers inherent advantages in dealing with the above issues over the traditional simulation systems. Our new approach requires the designer to compile his own part of the design into a component: to debug his own design, the designer simply asks the component to simulate itself; after he notifies testing engineers of where the component resides, the test engineers integrate different components remotely by some network protocols and the whole simulation system is now up and running. If one designer updates his part of the design to a new version, he only needs to build a new component to replace the old one and the entire simulation system runs without any additional modifications-no new simulator has to be rebuilt. And this simplifies the reuse of the previously designed components as well as the components from external sources. Furthermore, assume that every components possesses sufficient local processing power and the bandwidth of the network interconnection is reasonble enough, a multitude of synchronized self-simulating components can transform the network into a giant parallel multi-processor supercomputer! Finally, 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. They will have the option to mix and match different components and run press-button simulation from any remote client machine, while the actual computation is totally done distributedly. This scenario fits right into the WELD's big picture.
In order to achieve performance gain for the component based simulation system, we will have to ensure the efficiency of each single component. Each base component should possess enough local processing power impose a properly demanding load onto its local computing resource just enough to squeeze out maximum performance. Also, the bandwidth of the interconnect link must be sufficient and stable to guarantee the global synchronization of all the components within the system.
Ideally, the perfomance scales linearly with the number of processors if component pipelining is realized. By component pipelineing we mean that multiple input vector or input vector set are overlapped: the work to be done in a pipeline for an input vector (set) is broken into small pieces, each of which takes a fraction of time needed to compute the final output. For example, in Intel's Paragon supercomputer, every processor has its own memory subsystem and OS; processors are interconnected via the ultra-high bandwidth fiber optical data links. Assume our simulation system is placed onto such a computer and we tune the system according to the requirements list above, every component will compute its current output vector at one clock cycle, then use it to drive a next stage components and compute the next output vector at the next clock cycle: at almost any particular moment, our system guarantees that no single processor is idle; thus, the efficiency of the overall system is maximized. And yes, our new model is a very natrual way of doing simulation in parallel.
In real world, we have to deal with various type of computers linked with networks with different quality of service. With certain reasonable assumptions about all the resources available, it is still possible to improve the simulation performance to the largest extent. To tackle the problem of low bandwidth networks, we propose that a component computes a set of input vectors instead of single vector in one time unit and the size of such a set should be adjustable to optimize the performance. In other words, we want a component to spend most of its time running simulation instead of hankering for the next input.
According to our currently proposed model, a base component is able to self-simulate and interact with other components. In principle, the realization of self-simulation is the same as what the old compiled-mode technique does: we map the netlist description into java code and compile down to byte-code level. There are two cases we need to consider for component interaction. In the first case, several successive components reside locally and their interaction is completely within the memory system; in the second case, components are remotely connected and their interaction is via the network protocols. The input/output interface of a component is designed to take care of both situations. One should be able to switch a component between two modes easily.
A high level component is formed by wrapping together several lower level components (children). It has the same structure as its child: it has all the data type and methods that a base component has and also communicates with the other component at the same level of abstraction through same type of input/output interfaces. It also accomplishes the same simulation task as what a base component does but uses a different mechanism. In the case of self-simulation, event-driven technique is employed. Namely, the computation is performed by transferring the job to the components at the next lower level. The scheduling of the process, the arrangement of the components or the sequence of the computation is pre-configured and stored in the event list. In Figure 2, there are five sub-components inside a super-component. These five sub-components, with each submitting to the event list, are cascaded into a closed loop and the simulate method for the super-component, instead of being the mapping of the overall structral description, are merely function calls to invoke the simulate method of all its sub-components.
If a user wants to simulate the entire design, he interacts with 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 send 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. Figure 3 showes such a component based simulation system.
At java code level, the top level object is called Component object with default methods such as RUNME() and Probe() as well as default class variables like Event_list and I/O_Interface. I/O_Interface will be implemented as another class with its own set of methods and variables dealing with network protocols plus providing temporary data storage. Two types of subclass will exist as the subclass as Component object. One is called BasicObject that corresponds to the base component. The other is called MasterObject that corresponds to the all other levels of components. The front end is proposed somewhere Digsim alike for now and is tentative.
The final goal is undetermined which could be a set of APIs or a Digsim type simulator although I am seriously thinking about the some other possibilites such as a simple compiler to turn a piece of VHDL code into a network dispatchable, byte code level component or any combination of them.
Some literature survey has been done. So far, we found that all the related publications focus on the implementation techniques i.e. event driven or compiled mode. Various scheduling methods have been exploited. Two actual implementations have been created to make comparison in terms of performance and scalability issues.
The coming quarter will be divided into two phases. During the first phase, a distributed version of component-based simulation enviroment will be constructed based upon the current working demo. More components will be built; in particular, there will be a new type "dummy component" designed to handle the remote component interaction. During the second phase, I will start writing a GUI component constructor which offers click-button generation of byte-code level components either from scratch or by wrapping some other existing components. A front end which visualizes the back-end simulation process is tentative depending on the time constraint.