Interface-Based Design

AbstractA new system design methodology is proposed that separates com-munication from behavior. To demonstrate the methodology weapplied it to a simple ATM design. Since verification is clearly amajor stumbling block for large system design, we focussed on theverification aspects of our methodology.

In particular, a simulator was developed that is based on the com-munication paradigm typical of our methodology. The simulatorgives substantial performance improvements without sacrificinguser access to detail.

Finally, the potential for this methodology to improve verification,modeling and synthesis is explored.

1. IntroductionThe design of large electronic systems such as an ATM network, acomputer network, an automotive engine control unit, a multipro-cessor system, is indeed very complex. Complexity arises not onlyfrom the ever increasing functionality of the systems but also frommore and more stringent requirements imposed upon them: time-to-market constraints, safety and performance requirements arepopulating the nightmares of system designers.

Time-to-market pressure together with the multitude of compo-nents that are needed to implement the required functionality makeit impossible for a single company to design and manufacture anentire electronic system in time and within reasonable cost. Hence,design re-use and Intellectual Property (IP) trading should now beconsidered a necessity. The recent Virtual Socket Initiative (VSI)[1] is a fist step towards a methodology supporting the trade of IPblocks. However, present design methodologies are at a loss whenIP blocks coming from different design groups are mixed andmatched to create a new product. In particular, verifying whether adesign satisfies all constraints and requirements is today a mostdifficult design step. To address this problem, we emphasized thatdesign tools are not enough, new methodologies have to be put inplace [2]. This paper is concerned with an important aspect of adesign methodology that favors design re-use and verification:interface-based design.

The design methodology originally proposed in [2] was based onthree cornerstones:

■ Formalization, which consists of capturing the design and itsspecification in an unambiguous, formal "language'' withprecise semantics.

■ Abstraction, which eliminates details that are of no importancewhen dealing with high-level design or checking whether adesign satisfies a particular property.

■ Decomposition, which consists of breaking the design at agiven level of the hierarchy into components that can bedesigned and verified almost independently.

These three theoretical tools can be used to simplify design andverification in many different ways. An important one consists of"orthogonalizing" the properties of a design. For example, decom-posing the verification problem into a functional verificationphase, where the timing aspects of the design are ignored, and intoa timing verification phase, where only limited information aboutfunctionality is considered, has been a major design methodologyimprovement.

In this paper, we propose a way of orthogonalizing an electronicdesign along different dimensions: behavior and communica-tions. This idea is based on the realization that there is a commonstructure of electronic systems consisting of a set of entities (eitherhardware, software or both) that are connected together. Each ofthe entities may either be a similar structure consisting of otherinteconnected entities or a basic block of the design, the leaf of thehierarchy. The interconnection is a symbolic way of indicatingcommunication that takes place among entities. In fact, an inter-connection of software models is certainly an abstraction sincethere are no wires there to use for the communicating entities!

Examining most of the methods used to design such systemsshows that communication is often intertwined with behaviorand/or with its physical carrier so that it is difficult to talk about the"abstract" communication aspects of a design. This is particularlytrue at the RTL level and below.

Inspired by [3,4,5,6,7,8], we believe that it is possible to clearly

Permission to make digital/hard copy of all or part of this workfor personal or classroom use is granted without fee providedthat copies are not made or distributed for profit or commercialadvantage, the copyright notice, the title of the publication and itsdate appear, and notice is given that copying is by permission ofACM, Inc. To copy otherwise, to republish, to post on servers orto redistribute to lists, requires prior specific permission and/or afee.

DAC 97, Anaheim, California(c) 1997 ACM 0-89791-920-3/97/06 ..$3.50

Design

Interfaces Behaviors

Figure 1: Separating Behaviorfrom Communication

James A. RowsonAlta Group of Cadence Design Systems Inc.

jimr@altagroup.com

Alberto Sangiovanni-VincentelliUniversity of California at Berkeley

alberto@eecs.berkeley.edu

identify what role communication plays atall levels of the designand keep it separate from component behavior (see Figure 1). It isour intention to show how the design of an electronic system canbe carried out intotwo almost independent steps: the design andselection of the functionality of the components of the design andthe way in which these components interact through a communica-tion mechanism. In particular, we believe that a specific methodol-ogy can be used to carry out the design of communications in atop-down, constraint-driven fashion.

2. Interface-Based DesignWe propose a new way of describing designs that includes commu-nication abstraction. Because the focus of such a method would beon how the modules interface with each other, we'll call this newmethod interface-based design.

Telecommunication developers have long used protocol stacks toprovide an abstraction mechanism for their complex communica-tion systems. Protocols use hierarchical principles to hide complextime or encoding behavior of the lower levels of the communica-tion stack. Each layer of the stack provides System Access Points(or SAPs), which are points of contact between that stack layer andthe one below. These SAPs are analogous to ports on a module.

As a more pragmatic example, a bus could be described as a sim-ple hierarchical protocol. The top layer of the protocol is the set ofpossible bus transactions: read, write, burst read, burst write, read-modify-write. Each of these transactions can be further describedusing some protocol on a given set of pins, say PCI bus or EISAbus.

In order to generalize these concepts to all levels and types ofdesign, we need to formalize better what is the basic communica-tion mechanism that we propose and how to refine it.

2.1 Models of ComputationLee [11] has proposed over the years that systems be designedusing a heterogeneous collection of models of computation. Amodel of computation is a self-consistent set of rules or laws ofphysics that are useful for modeling at an abstract level. Com-monly used models include Dynamic Data Flow, CommunicatingFinite State Machines, Synchronous Data Flow and DiscreteEvent. Each of these models has certain properties that are quiteuseful in design.

If the differences between the most popular system level modelsare analyzed, it becomes clear that the major difference is in themethod of communication between concurrent objects. Dataflow[9] (both dynamic and static) communicate using queues, neverlosing a token. Discrete Event [10] (DE) level performance model-ing uses a single entry queue to hold tokens until the receiver canbe invoked. Each model of computation relies on specific proper-ties to be guaranteed by the communication mechanism. In DE,there is no guarantee that every event will be seen by the receiverbecause the receiver may not be sensitive to that event when it isemitted. On the other hand, there is a global order that can beestablished between events in unrelated portions of the design.Dataflow guarantees the safe arrival of every token and that thesequence of tokens on each communication path is defined. Thereis, however, no global ordering for tokens in unrelated designparts.

Others have also proposed models of computation. Chiodo et al.[12] have proposed a model (Codesign Finite State Machines)based on FSMs communicating among themselves with eventbroadcasting that allows for asynchronous communication. Notethat in this case the composition of the FSMs under the eventbroadcasting communication model cannot be claimed to have the

same property as an FSM. Both DE and event broadcasting wereselected because of their simplicity and generality. However, whileother more complex models of communication could be expressedin terms of event broadcasting, it was not clear how to use thismodel to do top-down design of the communication part of thedesign.

2.2 Incrementally Refining a Model ofComputation

The interface-based system design methodology that we proposeadopts the token passing methodology from dataflow and discreteevent system level while providing a method to refine communica-tion mechanisms incrementally and hierarchically.

A token represents a complete communication between two ormore design entities. Some examples of tokens include bus writes,bus reads, bursts, and variable length encoded data.

The process of refining token passing down to an implementationis similar to the successive refinement concept proposed by severalresearchers especially in the formal verification community. Onesimple method of communication refinement could be imple-mented by replacing the abstract, simple token exchange in themodel of computation by another design that has two parts: a mas-ter and a slave (see Figure 2).

The master side initiates the communication by accepting thetoken from the sender and breaks the token down into a series ofdata and handshaking events on some new communicationpaths.The slave recognizes the handshaking events and gathers thesent data, reconstructing the token for delivery to the receiver. Themaster part of this new communication design will be synthesizedwith the sender, the slave synthesized with the receiver.

This methodology is clearly not limited to hardware. It is appropri-ate for describing communication between multiple softwarethreads (shared memory, queues, posted events, etc.) or betweenhardware-software (polling, interrupts, etc.) or software-hardware(I/O instructions, memory mapped registers, coprocessor).

3. Interface-based Design ExampleHierarchical stepwise refinement is an essential part of interface-based design. To illustrate the concepts, we use a mixed hardware/

sender receiver

master slave

substitute

repartition

Figure 2: Refining Communication

software design that is communicating across a network usingATM packets. For example purposes we will only look at a smallportion of the overall system, namely a software thread that issending packets through a hardware transmitter (see Figure 3). Weimplemented this example in an experimental simulator namedCheetah that is described in more detail in the next section.

At the most abstract level, the ATM packets will be modeled as atoken. The token contains 53 bytes of data (5 header bytes and 48payload). To debug system functionality, we can pass these tokensaround without regard to how long they take to be transmitted. Atfirst, it is immaterial that the packet creation is software and packettransmission is hardware, and in fact the exact line between hard-ware and software should remain fuzzy as long as possible to keepimplementation options open. Simulation at this abstract level canbe done in the DE domain by passing tokens between abstractbehaviors simply by exchanging pointers.

Simulation results from Cheetah at this level consist of a simpletrace of the ATM packets crossing through the interface betweenthe blocks.

As we refine the system we need to make design implementationchoices. We can now explicitly choose to put the packet creation insoftware and transmitter in hardware. The communication betweenthem will be across the processor's bus. At this point we have notchosen the processor bus (or the processor, for that matter), so wewill model this refinement using an abstraction of a bus that han-dles reads, writes, burst reads, and burst writes. Each of thesetransactions will, for the moment, take a constant amount of time.

Refining the token passing into a series of bus transactions can bedone in many different ways. In this example, we'll only considerthe differences between individual writes and burst writes. Sinceeach ATM packet has 53 bytes, we can transmit it in several differ-ent ways, from one byte per write to all 53 bytes in a single bursttransaction. To make the protocol a bit more robust, we will add awrite to a special location as the first bus transaction, followed bywrites of the real data to another address as shown in Figure 4. Thedata transactions can be burst transactions of various lengths orcould be individual writes. In a real system, we would probably be

packing bytes into words for efficiently, but for this example wewill just put each byte into a separate write (or separate part of aburst write).

Of course, we are dealing with a more complex system than justthe packet creator and transmitter, so other communication pathswill also be sharing the processor bus. We need to make sure thatour protocols are being refined correctly, that the transmitter isfaithfully reconstructing the packets and that other traffic on thebus is also getting through. At this point, we cannot yet do accurateperformance studies (although if we made a slightly more accuratebus model, we could get a first feel of bottlenecks). Arbitration ofthe bus has to be modeled at this level, and we can start to assignmemory maps and get the programmer's model of the systemdecided upon.

Simulation results from Cheetah at this level of refinement allow

PacketCreator ATM Transmitter

ATM Packets

PacketCreator

PacketCreator

ATM Transmitter

ATM Transmitter

Bus Transactions

Signal transitions

Figure 3: CommunicationRefinement

@50

0 <

- 0

@50

1 <

- by

te[0

]

@50

1 <

- by

te[1

]

@50

1 <

- by

te[2

]

@50

1 <

- by

te[3

]

@50

1 <

- by

te[4

9]

@50

1 <

- by

te[5

0]

@50

1 <

- by

te[5

1]

@50

1 <

- by

te[5

2]

1 53

ATM Packet

Refinement

Figure 4: Refining the ATM cell

the user to "expand" the ATM packets into the more detailed bustransactions that implement the protocol.

The next refinement is to select a bus implementation. We mightchoose a PCI bus or an EISA bus, but for this example we chosethe PI-bus from the Open Microprocessor Initiative in Europe [15].The PI-bus is a synchronous bus intended for on-chip work. Nowwe can get cycle accurate knowledge of how each bus transactionis happening. Buses can have multiple masters, so the arbitrationof bus access is important. Here, arbitration is modeled to the cycleaccurate level, as is the performance.

Simulation results here allow the user to "expand" down throughthe bus transaction level and into the cycle accurate pin transitiondetail as shown in Figure 5. Within Cheetah this last level of detailisn’t simulated, but is instead recreated on demand from the user.

Now that we have selected a bus, it is possible to do detailedthroughput versus latency studies. The burst mode we can use tosend ATM packets will offer high throughput for the ATM packetsat the cost of higher latency for normal bus transactions for othersusing the bus. Only with models that show a more detailed timingmodel of the bus can we make these studies. Optimally we wouldlike a cycle accurate detail, but we at least need to be statisticallycorrect (what might be called a cycle approximate model).

4. The Cheetah SimulatorWe have written a simulator, namedCheetah, that is designed tosupport interface-based design. Cheetah was developed to exploretwo areas: simulation speed and modeling style. Simulation speedcomes from abstracting the interface, in particular avoidingdetailed simulation of the interface internals. Modeling styleexploration included investigations into how to simulate an inter-face abstractly and configure different interface implementationsinto the simulator easily.

The Cheetah simulator is an event driven simulator. Events areused to trigger actions in modules and interfaces. Full objects(instances of a Java class, in this case) are passed from module tomodule through abstract interfaces. We can substitute differentinterface implementations without changing the module code. TheATM example shown in Figure 3 and described in the next sectionhas three different interface implementations that satisfy the sameabstract interface.

Speed of simulation in Cheetah is obtained by avoiding unneces-sary events and computations within the interfaces. During simula-tion, the interface simply passes tokens through, delaying them bya quickly computed delay before passing them onto the receiverand before letting the sender know the transaction has finished. Nodetailed cycle accurate simulation is done although the delay rep-resents the cycle accurate time.

Synchronization, as for arbitrating access to a bus, is performedusing a typical DE resource object, which knows how to allocate ashared resource to multiple requestors. No events are posted to themain event queue for handling synchronization, instead a localalgorithm awakens the waiting requestor.

By abstracting synchronization and avoiding unnecessary eventsand computation, we can get performance similar to that of othertoken passing, queuing level performance analysis simulators.

For analysis purposes, designers would like to be able to expandthis token level simulation into its constituent parts so that they cananalyze resource usage, see opportunities for optimization, andunderstand how a bus protocol is working. As with most simula-tors, Cheetah allows probes on the interfaces between modules.The probed data captures the transaction, its beginning and end,and any synchronization or parameterization data necessary toreconstruct the cycle accurate behavior of that interface for thattransaction.

On demand from the user, the probe data can then be expanded bythe interface into what appears to be more probed data of assign-ments to the lower level details within the interface. In effect, weare resimulating each probed transact ion in isolation to create newprobed data for display.

The interface, then, consists of a type specification (what type ofdata is carried by a single transaction across this interface), a delaycalculation that is cycle accurate for the given transaction, and aprocedure to expand or resimulate a previously handled transac-tion.

Interfaces can be hierarchical, allowing the parent interface tobreak a big transaction up into a series of smaller transaction onthe children interfaces.

Expand ATMs

Figure 5: ATM packets sent over a PI Bus

Expand Bus Transactions

Interfacestart

finish

start

finish

add tohistory

expandhistorytrace

postevent

eventdone

Simulator Kernel

Simulator UI

Sla

ve

Mas

ter

Figure 6: Interface interactions

Each interface can be thought of as serving several purposes asshown in Figure 6.

The master starts a transaction by creating the transaction objectand passing it to the interface. The interface then performs itsabstract implementation, which for the simplest cases is to just usethe global event queue to delay for a computed amount of time.The slave is notified that a new transaction has started. The inter-face may start building a history trace object using an optionallyprovided probe. When the abstract implementation is done, boththe master and slave are notified that the transaction is finished andthe optional trace object is added to the simulation history.

Later on, the user interface can come back to the interface and askthat a given trace be expanded into more detail. In the currentimplementation of Cheetah, this procedure will then create newhistory trace objects that show how the original transaction wouldhave simulated if it was being done in detail.

The Cheetah simulator gains performance from abstraction in bothtime and space as shown in Figure 7. The time abstraction avoidsmultiple assignments to a single signal because we only deal withthe transaction object. Similarly space abstraction avoids assign-ments to multiple signals. In the case of a bus, the space expansionincludes the address and datalines, as well as many handshaking,request, acknowledge, and state signals. The best simulator perfor-mance is at the most abstract level, and was approximately 25x theslowest simulation we saw during the ATM methodology experi-ment.

Cheetah is in an experimental condition, so it is difficult to get anaccurate performance comparison against an RTL level simulator.To get some sort of relative performance comparison we use eventsas our metric. Many designs are event queue limited, which meansthat their performance (in clocks simulated per second ofwallclock time) is proportional to the number of events required tosimulate a clock cycle. Our bus model avoids using events to simu-late the detailed cycle level behavior, so each bus transaction onlyrequires one event. An HDL simulator would require at least oneevent per bus signal transaction. Our bus has a minimum 7 signalassignments per bus transaction.

Based on this relative performance argument, our most accuratesimulation would be about 7x faster than an equivalent RTL simu-lation. Our most abstract simulation would then be approximately175x the performance of a cycle accurate RTL.

5. SummaryWe have proposed a new methodology for system level design thatseparates communication from behavior. This interface-baseddesign methodology seems to provide numerous advantages indesign modeling and exploration, synthesis, and verification.

A simulator (Cheetah) was built to explore the performance andmodeling implications of this methodology and was found to givencycle accurate simulation with substantially fewer events posted to

an event queue than would be required in an HDL simulator. Fullcycle accurate detail can be reconstructed post-simulation.

By adopting this methodology, we expect to see improvements inthree major areas: modeling and design exploration, synthesis, andverification.

5.1 Modeling and Design ExplorationModeling is improved in two important ways:

■ better design reuse

■ easier exploration of the design space

By separating communication from behavior, we have orthogonal-ized two extremely important design considerations. This separa-tion makes it possible to mix and match communicationtechniques with behaviors. We can model some behavior and thensnap on different bus interfaces. Alternatively, we can create acommunication architecture and plug in different IP.

Design exploration is enhanced by providing a new place to con-figure the design. Using VHDL configurations as the archetype,we can switch in different communication architectures withoutmodifying the original design.

5.2 SynthesisBy separating communication and behavior, new opportunities forsynthesis are also created:

■ improving the productivity of logic synthesis

■ solving a major stumbling block for high level synthesis.

Despite the use of synthesis for a decade, design reuse is still citedas the most important desired productivity step. By incrementallyinserting the communication logic into the behavior, blocks andcommunication schemes can be more easily reused.

Coelho [13] has shown that having an abstraction of the communi-cation between modules can provide importantdon’t care informa-tion that leads to better synthesis results.

High level synthesis suffers from a lack of composition methodol-ogy. Each block can be synthesized using high level synthesis, butno methodology exists to easily compose separately synthesizedmodules together. By imposing a communication mechanism on abehavior, the designer is also imposing a set of high level con-straints on the two modules, which is suitable for guiding the highlevel synthesis of each for smooth composition.

5.2.1 VerificationPerhaps the most important impact could be felt in the verificationarea. Important improvements could include

■ verification performance

■ enabling formal verification

■ testbench generation and reuse

■ measurement of functional coverage

■ block-based design verification methodology

Higher level abstractions provide better performance, in general,but at the cost of accuracy or visibility into the fine detail. If weseparate communication from behavior, we can avoid simulatingthe communication once it has been verified and instead abstractthe communication into a minimal set of delays. On demand, wereconstruct the fine detail if desired by the user. A simulator thatrelies on these techniques is briefly described in Section 4.

Formal verification is an extremely powerful technique thatrequires abstract descriptions coupled with a formal description of

Time

Space

Figure 7: Performance gains from time and space

# clocks

# signals

the environment around the design. By keeping the modulesbehavioral and separate from the communication we can help keepthem simpler and more likely to be amenable to formal techniques.The formal specification of the communication protocols can pro-vide the necessary environment description that can help isolate ablock, further simplifying the design to be verified. In addition,formal verification can be used to verify that an interface refine-ment continues to uphold the original abstract properties of theoriginal communication (each model of computation will have dif-ferent properties that need to be checked). Balarin [16] has someinitial work in this area for CFSMs.

Testbenches are an unsung but extremely important design task.Most designers will admit to the testbench being at least as muchwork as the design. A formal, perhaps declarative, description ofthe communication protocol being used on a block could be usedto automatically generate test fixtures that stimulate and check adesign. Some tools like this, from companies such as InSpec,already exist as a separate add-on to an HDL design description.By putting the communication descriptions right into the designlanguage, test generation and checking can be a natural fallout ofthe design process. Further, by creating the test generation at ahigh level and keeping it separate from the communication mecha-nism, any manual work creating tests can be more easily reusedfrom design to design.

Code coverage [14] has emerged as a technique to answer the diffi-cult question: Have I simulated enough yet? The known techniquescan be used to analyze coverage of behavior. With a formal proto-col description of a communication mechanism, a new kind of cov-erage analysis is possible, checking to see that all the types andtemporal combinations of transactions have happened.

Designing complex systems by reusing large building blocks ispartly difficult because of verification. By separating communica-tion and behavior it should be possible for the author to verify theIP block against an abstract interface definition. The IP user couldthen use a high level description of the block, checking for interac-tions between the blocks and using functional coverage to makesure that all interface interactions had been investigated, but notneeding to dive deeply into the block to verify its functionality.Different blocks can be tried out, with the correct interfaces syn-thesized as needed between them. The separation of communica-tion and behavior can help segment an unsolvable verificationproblem into a collection of more manageable ones.

5.2.2 Future WorkFuture work will involve several types of research:

■ Theoretical: What are the types of properties in differentmodels of computation and how might they be preservedduring refinement?

■ Language: What kind of description language would embodythis methodology most effectively? How can an interface bedescribed declaratively so a single description can be used togenerate, recognize, and check its protocol?

■ Formal verification: Can we formally prove refinement of acommunication style?

■ Simulation: With more realistic examples, what performanceimprovement will we get?

■ Modeling: How can we mix together large complex IP withoutknowing how they are built inside?

■ Refinement: How do we refine a collection of interfaces ontoa communication architecture that involves shared resources,addressing, arbitration, etc.?

■ Synthesis: How can an interface description be used to setconstraints on the synthesis of a module? How can weminimally incorporate the interface behavior into a module?

Acknowledgments

This work has evolved partly because of many valuable conversa-tions with Dan Yoder, Chris Ditzen, A. Richard Newton, PatrickScaglia, Luciano Lavagno, Cary Ussery, Misha Burich, RickMcGeer, Felice Balarin, Ken McMillan, Christopher Hoover, andWendell Baker.

References

[1] Virtual Socket Interface (VSI) website: http://www.vsi.org

[2] A. Sangiovanni-Vincentelli, P.C. McGeer, A. Saldanha,"Verification of Electronic Systems,"Proc. of 33rd IEEE/ACM Design Automation Conference, Las Vegas, 1996.

[3] G. Borriello "A New Interface Specification Methodology andits Application to Transducer Synthesis," University ofCalifornia Technical Report, UCB/CSD 88/430, 1988.

[4] C. A. Wood, P. D. Gray, A. C. Kilgour, "Experience withChisl, a Configurable Hierarchical Interface SpecificationLanguage," Computer Graphics Forum, vol. 7, no. 2, pp. 117-127, 1988.

[5] A. Seawright, F. Brewer, "Clairvoyant: A Synthesis Systemfor Production-Based Specification," IEEE Trans. on VLSISystems, vol. 2, pp 172-185, June 1994.

[6] L. Lavagno, A. Sangiovanni-Vincentelli, H. Hsieh,"Embedded System Co-Design,"Hardware/Software Co-Design, pp. 213-242, Kluwer Academic Publishers, 1996.

[7] J. Oberg, A. Kumar, A. Hemani, "Grammar-based HardwareSynthesis of Data Communication Protocols," presented at theInternational Symposium on System Synthesis, La Jolla,November 1996.

[8] S. Vercauteren, B. Lin, H. De Man, "ConstructingApplication-Specific Heterogeneous Embedded Architecturesfrom Custom HW/SW Applications,"Proc. of 33rd IEEE/ACM Design Automation Conference, Las Vegas, 1996.

[9] E. A. Lee, D. G. Messerschmitt, "Synchronous Data Flow,"IEEE Proceedings, September, 1987.

[10] P. A. Fishwick,Simulation Model Design and Execution,Prentice Hall, New Jersey, 1995.

[11] J. T. Buck, S. Ha, E. A. Lee, and D. G. Messerschmitt,"Ptolemy: A Framework for Simulation nd PrototypingHeterogeneous Systems," Int. Journal of ComputerSimulation, special issue on "Simulation SoftwareDevelopment," vol. 4, pp. 155-182, April, 1994.

[12] M. Chiodo, P.Giusto, H. Hsieh, A. Jurecksa, L. Lavagno, andA. Sangiovanni-Vincentelli, "A Formal Methodology forHardware/Software Codesign of Embedded Systems," IEEEMicro, August 1994.

[13] C. Coelho Jr, "Analysis and Synthesis of Concurrent DigitalSystems Using Control-Flow Expressions," StanfordTechnical Report, CSL-TR-96-690, 1996.

[14] A. Hosseini, D. Mavroidis, P. Konas, "Code Generation andAnalysis for the Functional Verification of Microprocessors,"Proc. of 33rd IEEE/ACM Design Automation Conference, LasVegas, 1996.

[15] Open Microprocessor Initiative web site:http://www.omimo.be/index.htm

[16] F. Balarin, H. Hsieh, A. Jureckska, L. Lavagno, A.Sangiovanni-Vincentelli, "Formal Verification of EmbeddedSystems based on CFSM Networks,"Proc. of 33rd IEEE/ACM Design Automation Conference, Las Vegas, 1996.