Knowledge based automatic simulation model generation system

Knowledge based automatic simulation model generation system

S. Kang

Abstract: The main purpose of the research was to discover an easy fast and reliable way to generate simulation models and to create a model library. To solve this problem, the automatic element routine generation system (AERO) has been developed as an efficient way for automatic model development using domain specific automatic programming techniques. Behavioural and structural models are generated from Boolean equations, truth tables, HDL descriptions, schematic diagrams or incomplete specifications. By utilising this approach, simulation automation can be achieved by providing the same environment for model generation and simulation. Results show that the system could greatly reduce the cost of simulation model generation for CAD systems and consequently reduce the design cycle con- siderably.

1 Introduction

It is clear that simulation at various levels is an essential and commonly used method for verifying the design of digital systems. A simulation model is a program code which represents the functional behaviour of an element and is written in a simulator's target language. The performance of a simulator greatly depends on the number of models in the model library and the efficiency of the model. Since a simulator can only simulate systems constructed of the primitives in the model library, if there are not sufficient models, a large system may not be handled by the simulator. Also, if the model is written in an inefficient way, the speed of the simulator is slow. Therefore, it is very important to find an effective way of developing a model library as well as for generating efficient models. Until recently, simulation models were developed through a knowledge intensive design process which is difficult, expen- sive, time consuming and error prone. Additionally, it is not easy to predict the performance of functional elements. To overcome these difficulties, an automatic method of model generation is required. Therefore, automatic model generation is clearly necessary and

0 IEE, 1997 IEE Pwceedzng~? online no. 19970910 Paper received 16th May 1996 The author is with the Department of Electrical Engineering, Yonsei University, Scoul, Korea

very significant, since it has the potential of saving hundreds of man-years of code development.

Automatic programming [l] is the automation of some part of the computer programming process. As an application of artificial intelligence, automatic programming tries to help human beings write programs in a higher level of abstraction and instruction which are more natural to a human than lower level program- miiig details. By improving the programming environ- ments and the specification method for the desired program, the programmer is not only allowed to think of the problem at a more natural level, but is also relieved from keeping track of inordinate amounts of detail. Automatic programming is concerned with methods for selecting programming constructs, methods for utilising fragmentary information, methods for synthesising code from examples of the desired behaviour, and methods for utilising domain knowledge. There have been numerous attempts to develop automatic systems which can, in general, generate programs from a simple specification. However, these have had limited success. On the other hand, several successful automatic programming systems have been developed by restricting the application domain [2]. These are called domain specific automatic programming systems. Either the domain knowledge can be provided by the user as a part of an interactive specification process, or it may initially exist in the system. The way of representing domain knowledge and the interaction between the domain knowledge and the programming knowledge are dictated by the specific application domain.

An automatic program generation system, which automatically generates functional elements based on the concepts of domain specific automatic programming [2], has been developed. The ideas shown in [3] are for the general approach for model generation in a simulation environment, but these were not imple- mented. The attempt to generate 3-value simulation models was done in [4]. However, this deals with only gate level circuits and requires very limited size circuits. In [5], the model generation is done for sequential elements, but it has the same limitations as in [4]. The automatic functional model generation system (AFMG) [6] is the first simulation model generation system. It can generate functional models from the gate to behavioural levels. The possible inputs include schematics, truth tables, equations or hardware description languages (HDLs).

In this research, to expand the application of domain specific programming techniques [2] to the CAD area, the AERO (automatic element routine generation system) was developed. This is the CAD tool for designing

IEE Pvoc -Circuits Devices Syst., Vol. 144, No 2, April 1997 88

simulation models and a library using domain specific programming techniques. Using this system, simulation automation can be achieved by providing the same environment for model generation and simulation. As a model generator, the performance of AERO is superior to the previous system [6] since it allows various descriptions and provides more domain knowledge. It can generate models from the switch to the functional level for logic, fault and error simulation. The simulator generation time is far superior to the time that human programmers take to develop a simulator. Also computation time using the generated simulator is efficient.

schematic

I preprocessinq unit

level ised net lists

schematic ----c

generator - oct - net l ist

I I

I

generation unit

postprocessing unit

s imulator n

Fig. 'I Co$gurum of AERO

2 System configuration

To implement efficicnt domain specific automatic programming techniques, knowledge of the application domain must be kept in some form of rule base to guide the program synthesis. Also, the system must provide an efficient user interface to get specifications and knowledge. Additionally, in order to handle the user's incomplete or imprecise specifications. the system musl be capable of interpreting the user's intention.

To generate simulation models effectively, the follow.- ing must be considered:

The system must generate high performance models since models affect the overall performance of a simulator.

The system must verify generated models, since the correctness of the models determines the accuracy of the simulator.

The system must generate models which can easily interface to various simulators with minimal modification.

The system should generate concise models to mini-. mise the usage of memory.

The generated models for sequential devices musl. have some mechanism to allocate data for each1 instance of the element, including internal memory states.

The automatic element routine generation system (AERO) is a powerful simulation model generation system which can automatically generate simulation models from various descriptions, using domain specific automatic programming techniques. As shown in Fig. 1, the AERO system includes several subsystems, i.e. preprocessing unit, model generation unit, model verification unit, postprocessing unit, knowledge base and model library. This system can generate models written in the simulator target language from HDL descriptions, truth tables, Boolean equations and schematic diagrams.

3 Preprocessing unit

Fig. 2 shows a configuration of the preprocessing unit. The preprocessing unit includes parsers and translators which have interactive user interface facilities. Not only should the AERO front-end provide model specifications as inputs to AERO but also collect and store feedbacks from other AERO subsystems. The feedbacks include both informative error messages if the input to the back-end was somehow rejected by the transformation process, and performance data and representation objects if the transformation process suc- ceeded. The error messages inform users of reasons of

---c - net l ist - generator

TDL - parser

con t ro i

genera tor ---L SHDL/VHDL --c parser -* flow ------L control f lows

- I i n te r face H 1 -

system U equation

Boolean

in termediate t r u t h tables t r u t h table t rons la tor

specif icat ion

Fig. :! Con/igui.ution of preprocessing unit

89

failure, such that users can modify their input specifications interactively and resubmit their request. The performance data and representation objects are stored in the knowledge base, so that the stored input descriptions and representation objects, corresponding to some well defined and verified simulation model, can be used as a black box to construct other more complicated elements. This approach enhances the reusability of works achieved in previous efforts. The user needs to understand only the behaviour of the simulation models as specified in their input description, without being concerned about their implementation. To provide a versatile and user-friendly environment, the AERO preprocessing unit includes a user interface system (UIS), a schematic interface system, parsers, translators and an incomplete specification handler. All these components are designed to provide a versatile aud user-friendly euvironment.

By co-operating with the library handler, the UIS displays the existing models which can be used to build new models or store the generated models by co-operating with the library handler. Also, it can be used to add the corresponding model specification into the model library. Using the user specified group name, the UIS either successfully locates the already existing group and displays all models within this group to users, or creates a new group if it cannot find the specified group. If users enter a new model name, the system will read in this name, and ask for further information including the number or states desired for this model, the bit representation for each state, and the type of input description. If the model name is already defined in the specified model class, the model description will be retrieved and displayed for further reference or modification. The model description type is used to select the appropriate data structures, algorithms and transformation rules. By interactively que- rying users for signal representations, the UIS participates in the automatic signal modelling process. The UIS also works with the incomplete input handler (ISH) to perform the consistency check and to derive the complete truth table description. The sample ques- tions are shown in Fig. 3.

1 What is the model group name? 2 What is the model name? 3 . How many states are desired for this model? (2-10) 4 Do you want to specify bit representations? 5. What is the type of your input specification? (a-b)

a Truth table c Schematics d TDL e Behavioural SHDL g Shuctural SHDL

b Boolean equations

f Behavioural VHDL h Structural VHDL

Fig. 3 @,mtionnuire of user inteface system

The schematic interface system provides a higher level, and easy-to-use, graphics user interface to AERO users for specifying desired models at structural level. The schematic interface system is developed on the OCT environment [7, 81. Using this, users can select primitive models and other predefined functional models to define a new functional model, and then define the interconnections among these elements. The infor- ination of the elements and their interconnections is used by the schematic interface to create a net list which will be finally passed to the AERO model generation unit for generating the target model.

YO

For HDL input specifications, parsers are used to transform specifications into some intermediate representations. For different types of specifications, a par- ticular parser and appropriate internal data structures are developed to perform the transformation process using yacc and lex. For structural HDL descriptions, the parser transforms the language descriptions into internal representations, which are passed to the net list generator for further processing. For the behavioural cases, control flows and equations are created by the parser.

When truth table descriptions-one of the easist and most natural ways to describe a reasonable size circuit -are entered, they are translated by the translator into internal data structures. If the Boolean equations, or the gate implementation, of a circuit are known, it is convenient to use equations to describe the circuit. These equations are translated into internal data structures.

For a truth table input description there can be incomplete specifications. For incomplete specifications, the ISH can send the users the error message and continue to fill in the missing information by consult- ing the knowledge base. If there exist predefined rules for the class of the target model, the ISH will use the rules to derive as many entries as possible of the missing information. If there are still some missing entries after all applicable rules in the knowledge base have been used, the UIS will be invoked to ask the users to provide new rules. p=q knowledge

II control flows L a

signal modeller

Boolean

intermediate truth tables

I I

i

primit ive m o d e l k r

Fig. 4 Configration of model generation unit

4 Model generation unit

U

functionai mod e I le r

Using the information from the preprocessing unit, the model generation unit (MGU) synthesises models. From the synthesised models, it can generate ‘C’ models according to user’s command. The structure of the MGU is shown in Fig. 4. The model generation process is performed in three phases: the signal modeller, the primitive modeller, and the functional modeller. The general simulation models can be classified into structural and behavioural models. A structural model describes a circuit by connecting low level primitives. A behavioural model is used to describe the functional behaviour of a circuit. This system can generate both structural and behavioural models. The model consists of entity declarations, architectural bodies and configu-

IEE Pwc.-Circuits Devices Syst., Vol. 144, No 2, April 1557

ration declarations. An entity represents a part of a well defined hardware design. An architecture specifies the relationship between the inputs and outputs of a design entity and a configuration specifies the binding of components to entities. With the information about inpui. and output signal names, the entity parts can be completed.

4. I Signal modeller The signal modeller determines the bit representation of the electrical signals. During the automatic signal modelling process, the schema generator is used to cap- ture the important information and store the transformed knowledge as a set of rules. This set of rules is called transformation schema and stored in the knowledge base. The transformation schema can be used effi- ciently by the signal modeller, to guide the automatic model generation process for achieving a higher level of design automation. The signal modeller customises the user specified logic values and bit representations dynamically to make the model generation process very flexible.

VA u n k n o w n

....a...

* f. I I1

t i m e

- t i m e I L 1 L j no representation

I 1

( V I ' I 1 I I I 1 I I time

L U P H D N L E Fig. 5 Modelling oj'electricul signak (i) Elea.rical signal (ii) 2-valucd modelling (iii) 3-v.ilued modelling (IV) 5-v:dued modelling (v) 7-valucd inodelling

In :2-valued modelling, only two logic values, L and H, ar'e used. The disadvantage of this modelling is that no representation is possible for the voltage range between the lower and upper cutoff voltages. Also, the initial behaviour of the device cannot be represented. To obtain a more realistic representation, more logic value:; should be used to model the signal. The 3- valued model, adding an X to represent an unknown signal value to 2-valued logic, can represent the signals between L and H, and initial behaviour. In the 4- valued model, a high impedance logic value 2 is included. This logic value is useful to represent the tristate devices. In 5-valued modelling, along with L, H, and X , U(D) is used to represent signals whose voltage is increasing (decreasing) and E is used to represent

IEE Proc.-Circuit.s Devices Syst., Vol. 144, No. 2, April 1997

errors or unknowns. To achieve a more realistic representation of signals, 7-valued modelling is used. In 7- valued modelling, N and P are added to 5-valued modelling. The value N(P) represents the mostly negative (positive) value. The %valued model uses 2 (high impedance), with seven logic values in 7-valued modelling. The greater the number of logic values used in the modelling, the more accurate is the representation achieved and the more complex the models generated. Fig. 5 shows some examples of representing the electrical signal by 2-, 3-, 5-, and 7-valued signal models.

For any k-valued signal model, k distinct logic values can be represented by sets of bits with at least [log, k ] bits in the set. Selecting a bit representation is very important since the number of Boolean operations in the models should be minimised. This is due to the fact that the complexity of models significantly affects the performance of simulation with the generated models. The several bit representations are shown in Table 1.

Table 1: Bit representations

2-value model 3-value model 5-value model

Logic Bit Logic Bit Logic Bit

L 0 L 00 L 000

H 1 H 01 H 01 1

X 1 x D 010

U 001

E 1 xx

4.2 Primitive modeller Primitive elements are defined as the basic set or elements whose functionality is described by using only the logic states created in the signal modeller. They can be used to build other more complicated elements. The primitive modeller is used to specify the behaviours of the desired primitive models.

The general simulation models can be classified into structural and behavioural models. A structural model describes a circuit by connecting low level primitives. A behavioural model is used to describe the functional behaviour of a circuit. This system can generate both structural and behavioural models. The model consists of entity declarations, architectural bodies and configuration declarations. An entity represents a part of a well defined hardware design. An architecture specifies the relationship between the inputs and outputs of a design entity and a configuration specifies the binding of components to entities. With the information about input and output signal names, entity parts can be completed.

The transformation process of a truth table specification is as follows. The knowledge used to construct the truth table is essential for processing the element specification provided by the user. The knowledge of super- imposing the bit representation onto the truth table to create multiple truth tables, each of which describes logic operations in terms of each bit in the bit representation, is critical to the transformation process. Also, the knowledge of mapping a truth table into a Kar- naugh map might play another important role during the transformation. Finally, from the performance point of view, the knowledge of how to obtain the minimised Boolean equations from a truth table or a Kar- naugh map is critical to the whole model generating process. For generating the optimised Boolean equa-

91

tions, the primitive modeller uses various techniques including the McCluskey minimisation algorithm.

The given Boolean equations are transformed into a set of enhanced equations, which are used by the code generator to synthesise the target element routine. Based on the selected signal representations, appropriate data structures and algorithms are used for creating the transformation schema which defines the transformation rules. According to the bit representations in the signal modeller, optimised transformation rules are generated for three primitive operations, which are the 2-operand AND, the 2-operand OR and the 1-operand NOT. Each rule defines a corresponding transformation method for each individual bit operation. The transformation schema contains two different types of rules: the formatting rules and the variable substitution rules. The formatting rules are used to concatenate signal variables using bit-wise logic operators 7, & and 1 . Each formatting rule has a corresponding variable substitution rule. The variable substitution rule defines the way that a deferred variable is substituted by a signal variable dynamically when the required signal name is available during the generation process.

When the given input specification is in the form of structural HDLs or netlists, it can be divided into elements and interconnections. Each element is transformed into a primitive model defined in a model library using the given bit representation.

When the given input specification is in the form of behavioural HDLs, the transformation process of control flows is necessary along with transformation of Boolean equations. The intermediate representations of control flows mainly consist of assignment statements, IF statements, FOR loops and REPEAT loops. Some control flows, such as the IF statements, can be converted into Boolean equations [9]. The assignment statement is handled exactly in the same way as the Boolean equations. Then, all the enhanced equations are merged with other control flows, such as loops, to form the core code segment.

A loop statement is transformed to a certain loop construct in the C language in a straightforward way. Consider an example shown in Fig. 6. In Fig. 6 a 3- valued model is assumed and two bits are used to represent each logic state. In this example, signal a is represented by two bits (a0 and a l ) and signal b is represented by two bits (bo and bl) , respectively.

I I 1

An IF statement contains two types of components: the condition expressions and the Boolean equations. IF statements are transformed into enhanced equations by converting the logic condition expressions to enhanced Boolean expressions and then merging the

enhanced expressions with other enhanced equations transformed from the Boolean equations identified in the statement. Consider an example of IF transformation shown in Fig. 7. In Fig. 7, 3-valued logic is assumed, and the logic signal H is represented by bits 01.

AND2(i, 0 )

int iC21 C21 , oCll C21 ;

int aO, ai; int bo, h i ; int C O , c i ;

{

0 CO1 CO1 = CO; oCOlCi1 = cl;

1

Fig.8 3- id i ed model for 2-input A N D

a

H L

X L x x

X L

b

a

I a l a 0 I

I a I

b

1 a l a 0

blbO , 11 0 Lx- -x; x

1 0 0 x x x C

Fig. 9 n 3-value truth table; h superimposed truth table; c splitting truth tables

Procedure of'the primitive modeller

As an example, consider an example of a 2-input AND model shown in Fig. 8. Assume that the signal modeller assigns bit0 = 0 and bitl = 0 for L, bit0 = 0 and bitl = 1 for H , and bit0 = 1 and bitl = 1 for X. To look into the transformation process of the above 5- valued model, each step is shown in Fig. 9. The 3-valued truth table of the 2-input AND gate with inputs a and b is shown in Fig. 9a. Under the above 2-bit representation, this truth table is converted into the superimposed truth table shown in Fig. 9b. Then, the two truth

IF c == R THEN

b = y

Fig. 7 Example of IF transformation

IEE Pvoc -Circuits Devices Syst., Vol. 144, No. 2, April 1997 92

tables, shown in Fig. 9c, are created by splitting the table of the original two-bit representation into two tables of single bit representations, with each new table describing the logic operation of each individual bit of the output signal and by replacing each input logic into 3-valued representation. Each of these two Karnaugh maps can be used to generate a minimal logic equation. The two optimised Boolean equations are the same as in Fig 8.

Suppose that logic L is represented by bit patterii 000, logic H is represented by bit pattern 110, the state U (for signal going up) is represented by bit pattern 010, the state D (for signal going down) is represented by bit pattern 100, and the state E (for error or unknown value) is represented by bit patterns 001, 01 1, 101 lor 111. A C model for 2-input OR based on the above bit assignments is shown in Fig. 10.

OR;! ( i , 0)

int. i C2l C3l , 0 C11 C3l ;

int aO, al, a2; int bo, bl, b2; int C O , c l , c 2 ;

i

a0 = iC0l Col ; a1 = iCol C11 ; a2 = iC01 121 ; bo = icl] 101 ; bl = i[ll c l ] ; b2 = iCi1 C2l ;

CO = (a01b0); cl = (allbl); c2 = ((-aO&b2)1(-ai&b2)~(a2&-bO)~(a2&-bl) (a2&b2)l(a0&~al&~b0&bl)~(-aO&al&bO&~bl));

O C O l CO1 = C O ;

OCOI c11 = c l ; OCOl c21 = c2;

Fig. 113 5-vultied model for 2-1npiil OR

Fig.1’

MUX21(i, 0) int i[31 121, 0[1l C21 ;

int aO, ai, bo, bl, C O , ci, do, d l ;

a0 = i[Ol CO1 ; ai = iC0l Ci1 ; bO = i[11 101 ; bl = i[ll[11 ; CO = iC21 [ O l ; ci = i12l Ci1 ;

{

2-to-I MUXJbr deluy futilt simulation

Consider path delay fault simulation [lo] using four values as an example Logic L IS represented by bit pattern 00, logic His represented by bit pattern 10, logic X

IEC Puuc Lu(uit5 Devicu Sy\i Vol 144 No 2 Apid 1997

is represented by bit pattern 11, and logic 2 is represented by bit pattern 01. The evaluation routine for a 2-to-1 MUX is shown in Fig. 11.

For all feedback signals inside a sequential model, dynamic memory allocation is required. During the first instance of any element routine called by the simulator, this element routine must allocate run-time memory for all of its internal state variables. The dynainically allocated memory is used to reference, update and store the internal state of every instance of this element routine. Right before a call to an instance of a model is completed, the model has to store the internal state, defined by internal state variables, back to the run-time memory for the current model instance. Additionally the model should pass the run-time memory pointer back to the simulator, and the simulator should store this state information in its internal table. For subsequent calls to the same instance of an element routine, the simulator must provide the run-time memory pointer as an input parameter to the element routine so that the element routine can use this pointer to restore its previous state. This state variable handling process is also required for generating sequential models.

5 Functional modeller

The AERO provides a powerful hierarchical partition- ing approach to synthesise the complex simulation models. By selecting the construction components and specifying their interconnections, a new model can be generated by the functional modeller. A lower level element routine used as a construction uiiit can be a model generated from various descriptions. Once a model is generated, it can be used as a new construction component to build the more complex structural models. This hierarchical approach makes it possible to generate simulation models of large systems.

The function modeller uses the information provided by the primitive modeller and information regarding the levelisation and the state variables. There are two different approaches for generating element routines. One approach is to expand the hierarchical structure using lower level elements. The other approach does not flatten the high level model into the lower level primitive elements. Instead, the second approach dynamically links the low level element and treats the component elements as predefined functions. The flat- tening approach may run faster because there is no overhead of function calls. However, the code size of a flattened simulation model of a complex element can exceed acceptable limits. In addition to the advantage of generating models with a much smaller code size, the dynamic linking approach can generate high level models even when the lower level component models are not yet available. After the high level model has been generated, the component models at the lower level can be generated without changing or regenerating the high level model.

The loop detection process is used to identify sequential elements. If a loop is found, a state variable is automatically defined for each detected feedback loop, and some sequential circuit specific transformations need to be done during the levelisation process and the code generation process. If there is no loop detected the levelisation process is performed.

The format of the generated model is shown in Fig. 12. Each generated model is a C function with

93

several lines of comments. The function can have three parameters: the inputs, the outputs and the state pointer. The declaration part declares variables, signals pointers and the part for handling state variables. In the main body, the component elements are evaluated according to the order of the levelised net list. For a sequential circuit, the main evaluation block is in a loop and will be executed repeatedly until the feedback signals converge or the preset iteration limit is reached. Finally, the output parameters are set, and the values of the state variables are saved in the run-time dynamic memory.

Comments ModelName ( i n p u t s , o u t p u t s , s t a t e - p o i n t e r )

Dec la ra t ions of v a r i a b l e s {

I n p u t s o u t p u t s S i g n a l s Feedback S i g n a l s Temporary Var i ab le s

D e c l a r a t i o n s of p o i n t e r s f o r s e q u e n t i a l p a r t I f ( s t a t e - p o i n t e r I = NULL )

I n i t i a l i z e v a r i a b l e s and s i g n a l s REPEAT

a l l o c a t e memory f o r i n t e r n a l s t a t e s

Eva lua te i n t e r n a l elements i n o r d e r I f ( feedback s i g n a l s a r e s t a b l e )

BREAK loop UNTIL ( l oop coun te r r eaches p r e s e t va lue ) S e t ou tpu t parameters Save s t a t e s of feedback s i g n a l s

1

Fig. 12 Format qfthe generated model

The domain related knowledge and program synthesis knowledge are used to guide the transformation process for automatically converting the user specified high level input descriptions into the desired functional models. The program transformation is simply changing a program description or part of a program description into another form. The AERO uses transformation several times at different stages. The required tasks in each component are accomplished by one or more transformations. This top-down and divide-and-conquer approach makes the design and implementation of the AERO feasible.

6 Model verification unit

When simulation models are generated automatically it is necessary to verify the correctness of these models. The goal of the model verification unit is to verify simulation models. Some difficulty exists with respect to the determination of the consistency among models, at various levels.

Simulation at various levels is used to veify the correctness of models. The simulator can handle multilevel primitives. The information about these primitives is derived from a model library. The basic configuration is shown in Fig. 13. From the given descriptions of models, expected desires are extracted and stored. This process is straightforward, to provide an environment to simulate a given model directly. If the user wants to see the results for each simulation pattern, they can be provided. If the user specifies the number of simulation

patterns, then, according to the given number, the pattern set is generated. Also, if the user provides a simulation pattern set, it can be used for simulation. Then, according to the size of a described circuit, a random pattern set, or an exhaustive pattern set, may be generated by the pattern generator. Then, the simulation results are passed on to the comparator. After compar- ison, if all the results are the same, the model is said to be correct. However, if any of the results are not the same, an error message is provided and the simulation patterns in disagreement are provided to the user for further consideration.

comparator + verify

Fig. 13 Configuration of simulation approach

7 Library

The model library has several sublibraries to store the same device using different levels of descriptions. The structure of the model library is shown in Fig. 14. The library handler is used to display all existing models and specifications. Also it is used to place new specifications into the library. After a target model has been generated successfully, the library handler can be invoked to store both the model specification and the generated model. It provides information to the UIS for available models together with their class name, model name, the number of signal states and their bit representations. It is also used to link the structural models to their components and add the generated models to the specific simulators.

, t&A ......

3-valued 5-valued . . . . . O b model for model for _ _ _ _ _ , 61 61 . ' . fi

Fig. 14 Structure oJ model librarj

The knowledge base contains domain specific knowledge, used in model generation and verification. The rules in the knowledge base are organised in a hierar-

IEE Puoc.-Circuit.y Devices Syst., Vol. 144, No 2, April 1997 94

chical structure similar to the clasdobject structure provided in an object-oriented environment. The knowledge stored in the knowledge base is classified into several categories including: 1. information about specific simulators, such as logic

values, memory state handling, element routine call- ing, etc

2. information about input descriptions 3. inforrnation about handling incomplete apecifica-

4. information about model verification. tions

8 Postprocessing unit

The postprocessing unit generates an I/O interface for specific simulators. Since every simulator has its own way of using simulation models, the postprocessor should be capable of handling the variation. To do this, it requires various pieces of information about simulators, including how to call an element routine and how to keep the state variables. This information is stored in the rule base.

9 Results

To prove the performance of the AERO, many simulation models for various simulation are generated. By adding an interface between the simulator and the generated models, these models can also be used foi othei simuliations.

Using the AERO, many models were generated using ISCAS benchmark circuits [l 11. The results of model generation are shown in Table 2 including circuit sizes, model generation times, number of simulation patterns, and simulation times. The generated primitive element routiines have the model execution times in the micro- second region, which are compatible with the model execution times of manually written element routines. The circuit size is the number of gates, assuming that the ciircuit is flattened inio a gate level if it was riot at the gatc levcl. Although the model gcncration timc increases according to the circuit size, the automatic model generation time is acceptable because of its speed and accuracy The AERO waq tested on a UNIX based SPARC20 workstation with memory size of 64 Mbyte. For simulation results, 1024 random patterns were used for [12].

Table 2: Results of model generation

Generation Simulation time, s time, s Circuit No. of gates

c432

c499

c880

c1355

c1908

c2670

c3540

c5315

c6288

c7552

160

202

383

546

880

1269

1669

2307

2416

3513

0.233

0.317

0.600

0.833

1.067

1.817

2.250

3.433

4.083

4.833

7.013

14.317

19.600

26.833

35.067

47.817

64.250

106.433

163.083

261.833

To prove the efficiency and accuracy, the 3-valued parallel fault simulation is performed using the gener-

IEE Pvoc.-Civcuits Devices Syst., 1/01, 144, No. 2, Apvil 199i

ated models. The results are shown in Table 3. These results are derived using the PARSIM simulator [12]. For these results, 1024 random patterns are used.

Table 3: Results of fault simulation

Circuit Faults

c432 524

c499 758

c880 942

c1355 1574

c1908 1879

c2670 2747

c3540 3428

c5315 5350

c6288 7744

c7552 7550

Fault coverage, %

95.99

97.49

98.20

89.07

94.40

81.61

94.04

95.73

97.32

91.08

CPU time, s/pat

0.009

0.032

0.026

0.183

0.185

0.580

0.31 1

0.534

1.021

1.345

Also, the mixed level path delay fault simulation results are shown in Table 4. The models were generated using 4-valued logic (0, 1 , X , 2). For these results, 1000 raridom path delay faults and 1024 random patterns are used for benchmark circuits [13]. In the Table, the number of detected paths for robust lest, strong iionrobnst test and weak nonrobust test, and the simulation time, for each circuit, are presented.

Table 4: Results of delay fault simulation

Circuit ROB SNR WNR CPU, s

s713

s820

s832

s953

SI 196

s1238

s 1423

s 1488

s1494

s5378

556

72

131

510

226

3

180

152

147

383

144

193

185

63

45 1

494

37

174

138

51

242

106

131

25

187

244

110

147

125

51

51.14

145.08

152.03

159.85

196.68

233.01

231.39

204.87

205.70

465.36

As a final example, the design error simulation [I41 results are shown in Table 5. The models were generated using 3-valued logic. In the Table, the number of design errorb, simulation coverage metric arid simula- Lion time for each circuit are presented. For these results, 1024 random patterns are used.

Table 5: Results of design error simulation

Circuits Errors SCM, Yo CPU, s

c432

c499

c880

c1355

c 1908

c2670

c3540

c5315

c6288

c7552

2489

3012

5171

7380

8775

13728

19130

33874

33472

38777

97.99

98.24

98.36

89.30

94.21

83.78

94.88

94.94

92.46

89.34

2.15

3.60

6.73

18.02

10.43

22.35

38.75

25.42

33.67

47.25

95

These results show that automatic model generation is efficient, and the model generation time of the AERO is superior to that of experienced human programmers. This result demonstrates the substantial advantage of the automatic model generation approach, especially compared to the many man-hours of effort which are usually required by the more error prone manual approach. Also, the results show that the generated models are efficient and accurate. If users are careful when writing the specifications, the generated code can approach the efficiency of the code written by a human programmer. Additionally, the generated models from the AERO can be used for various simulators.

10 Conclusion

Generating simulation models is a knowledge intensive, time consuming and error prone task in implementing a digital logic simulator. To overcome this problem, the AERO has been developed to generate simulation models in an efficient way by using domain specific automatic programming techniques. Using the AERO, the process of developing functional models becomes a much easier task than hand-writing the high level device specifications. The AERO provides the flexibil- ity of generating models conforming to the user specified signal representations and provides the capability of iwoniplete specification handling and input verification. In addition, since the designer need not worry about the details of low level coding, the chance of errors in the design cycle can be reduced significantly. As a result of providing an efficient and reliable way to generate simulation models and to create a model

library, the AERO could significantly reduce the development time and cost, and consequently improve the quality of the digital system design process.

11 References

1

2

3

4

5

6

I

8

9

10

11

12

13

14

BARR, A., and FEIGENBAUM, E.: ‘The handbook of artificial intelligence, Volume 2’ 1981 BARSTOW, D.: ‘Domain-specific automatic programming’, IEEE Trans. Suftw. Eng., 1985, pp. 1321-1336 SZYGENDA, S.A.: ’The simulation automation sytem using automatic program generation for hierarchical digital simulation systems’. Proceedings of IMACS European Simulation conference; August 1990 CHUANG, C., and SZYGENDA, S.A.: ‘The automatic element routine generator: An automatic programming tool for functional simulator design’. 25th Annual Simulation symposium, 1992 YANG, H.. and SZYGENDA, S.A.: ‘A domain-specific automatic programming system for the element routine generation’. Proceedings of Summer Simulation conference, 1991 HAN, C.H., KANG, S., and SZYGENDA, S.A.: ‘AFMG: automatic functional model generation system for digital logic simulation’. ASIC Conference, 1991 HARRISON, D.: ‘Symbolic editing with VEM’. University of California, Berkeley, 1989 SPICKELMIER, R.: ‘Release notes for Oct tools distribution 3.0’. Electronics Research Lab., University of California, Berke- ley, 1989 LEVENDEL, Y., and MENON, P.R.: ‘Fault simulation’ in PRADHAM. D.K. (Ed.): ‘Fault tolerant computing’ (Prentice- Hall. 1986), pp. 184-264 KANG, S., UNDERWOOD, B., and LAW, W.: ‘Path delay fault simulation for a standard scan design methodology’. Proc. ICCD, 1994 BRGLEZ, F., and FUJIWARA, H.: ‘A neutral netlist of 10 com- binational benchmark circuits and a target translator in FOR- TRAN’. Proc. of ISCAS. June 1985, pp. 695-698 KANG, S.. and HAN, C.H.: ‘Parsim manual’. The University of Texas at Austin, June 1990 BRGLEZ, F., BRYAN, D., and KOZMINSKI, K.: ‘Combina- tional profiles of sequential benchmark circuits’. Proc. ISCAS, 1989, pp. 1929-1934 KANG, S., and SZYGENDA, S.: ‘Modeling and simulation of design errors’. International Conference 011 Computer design, 1992; pp. 443446

96 IEE Proc.-Circuits Devices Syst., Vol. 144, No. 2, April 1997

Documents

Knowledge based automatic simulation model generation system