design and verification of peripheral control circuits in esterel

CONCURRENCY AND COMPUTATION: PRACTICE AND EXPERIENCEConcurrency Computat.: Pract. Exper. 2010; 22:981–994Published online 8May 2009 inWiley InterScience (www.interscience.wiley.com). DOI: 10.1002/cpe.1426

Design and verification ofperipheral control circuits inEsterel‡

S. Singh∗,†

Microsoft Research Cambridge, 7 JJ Thomson Avenue, Cambridge CB3 0FB, U.K.

SUMMARY

We present a case study showing how an existing concurrent programming language can be used toproduce either efficient control-oriented circuits or embedded software from the same description. Thisdescription is also amenable to fully automatic formal verification and can be used to produce pairsof reconfigurable components which can be dynamically scheduled into either hardware or softwareresources. By using an existing concurrent language we increase the productivity because we can makeuse of readily available tools for debugging, analysis and verification. We believe that a language and asystem that generates good software and hardware is a promising starting point for helping mainstreamsoftware developers target future manycore systems which will comprise a mixture of software andhardware components as well as provide a valuable technique for producing interchangeable reconfigurablecomponents for run-time reconfigurable FPGAs. Copyright © 2007 S. Singh. [Correction made here afterinitial online publication]

Revised 4 February 2009; Accepted 10 February 2009

KEY WORDS: circuit synthesis; synchronous hardware descriptions; formal verification

1. INTRODUCTION

Digital circuits are inherently parallel entities and design techniques for describing and implement-ing hardware are necessarily shaped by the need to either capture or infer parallel behavior. Thedominant techniques for describing and implementing digital hardware today require the designer

∗Correspondence to: S. Singh, Microsoft Research Cambridge, 7 JJ Thomson Avenue, Cambridge CB3 0FB, U.K.†E-mail: [email protected]‡Revised version of Singh S. Hardware/software synthesis and verification using Esterel. In McEwan AA, Schneider S, IfillW, Welch PH (eds). Communicating Process Architectures 2007. IOS Press: Amsterdam. Published with permission fromIOS Press.

This article was published online on 8 May 2009. An error was subsequently identified. This notice is included in theonline and print versions to indicate that both have been corrected [18 June 2009].

Copyright q 2007 S. Singh.

982 S. SINGH

to express their system in terms of an event-based simulation system. However, there has longbeen a desire to allow digital designers and software engineers to express their computations in aform that resembles a mainstream programming language and then have that representation auto-matically compiled into circuits. Most of the research in this area has focused on starting with aC-like language that is typically augmented with ad hoc concurrency constructs or annotations orby analyzing nested loops to infer parallelism. Although such systems can perform well for certainkinds of descriptions that can be readily expressed or recognized, they do not take advantage ofevery opportunity for parallelism and the designer’s control over the synthesized circuit architectureis rather indirect. This paper presents a case study of an alternative approach that involves using anexisting concurrent programming language to model and formally verify control-oriented circuits.This approach puts the control of the top level architecture back into the hands of the designer byallowing the structure of the system to be captured by concurrent code resulting in a system withfar greater flexibility.The use of an existing concurrent language has many advantages. One can immediately make

use of the readily available compilers, debuggers, analysis and verification tools. Another ad-vantage is that a system can be co-designed using a single language for the hardware and soft-ware sub-components as well as their interconnection. Having a single model for both increasesthe productivity and in particular facilitates co-verification. Conventional approaches for the de-sign and implementation of systems that comprise hardware and software (i.e. co-design) typ-ically involve totally separate flows for the design and verification of the hardware and soft-ware components. The verification of the combined hardware and software system still remainsa significant challenge. The software design flow is based around imperative languages withsemantics that model Von Neuman style architectures. The most popular software languageshave semantics that can only be expressed in an operational way, which is rather unsatisfac-tory from a formal verification and static analysis viewpoint. Conventional hardware descriptionlanguages have semantics based on an event queue model which also lends itself to an oper-ational style semantic description which is different from the semantic model typically usedfor software. This immediately poses a problem for any verification techniques based on staticanalysis (e.g. formal verification) which need to analyze a system that comprises software andhardware.Using an existing language (and then perhaps going on to refine it based on experience) also

avoids the very difficult task of designing a new programming language or the unsatisfactory pathof adding pragmas or ad hoc features to an existing language which is not well suited for expressingconcurrent computations.The ability to produce a pair of implementations (one hardware, the other software) is very

valuable for run-time dynamically reconfigurable systems in which a function may be mapped intoeither hardware or software depending on the available resources and deadlines.In the following sections we mention some of the existing work in the area of compiling software-

based descriptions into hardware. We then introduce the synchronous reactive programming lan-guage Esterel and demonstrate how Esterel programs can be synthesized into circuits using acommercially available compiler. The formalism captured in the Esterel programming language isoutlined [1] and we report the result of experiments that evaluate this methodology for the synthe-sis of both hardware and software. We also report our experience of performing static analysis ofhardware systems with properties expressed as synchronous observers which are also expressed in

Copyright q 2007 S. Singh. Concurrency Computat.: Pract. Exper. 2010; 22:981–994DOI: 10.1002/cpe

DESIGN AND VERIFICATION OF PERIPHERAL CONTROL CIRCUITS 983

Esterel and formally verified using an embedded model checker. We outline the future directionsfor this work before drawing conclusions from our case study.

2. BACKGROUND

The procedure of converting software models into efficient digital circuits inevitably involves theproduction of a parallel description as a stepping stone towards low-level register transfer levelcode. Much of the existing work on synthesizing circuits from programs and parallel descriptionshas taken C-like imperative languages as their starting point and added features for either ex-plicitly specifying parallelism (e.g. Handel-C [2]) or by developing technology to automaticallyinfer parallelism, e.g. Catapult-C [3]. Some researchers have proposed radically new languages—hardware design languages with carefully designed support for concurrency, e.g. Bluespec [4]. Itis important to recognize that a lot of work that has been done in the apparently separate fieldsof automatic (implicit) program parallelization and C-to-gate synthesis is essentially solving thesame problem although the two research communities often use very different tools, techniques andterminology.Examples of C-to-gates flows that infer parallelism include the SPARK system [5] from Gupta

et al. and the ROCC system [6] from Najjar et al. These systems perform operations like loop un-rolling and automatic pipelining in order to influence the throughput, area and clock frequency [7].More recent C-to-gates work in the context of reconfigurable systems includes the DWARVproject [8] at the Technical University of Delft.The desire to use a regular programming language for digital design was voice as long ago as

1997 by Gupta and Liao [9]. The work we present here, which is an extended version of [10], alsoadvocates using what is originally designed as a programming language for software as the startingpoint for producing control-orientated circuits. The distinctive aspects of our approach includethe adoption of a language with very clear and formally defined concurrent semantics, whichare amenable to automatic formal verification. Although we believe that synchronous languagesprovide a promising approach for allowing software engineers to develop control-oriented circuits,we believe that the scope of such work does not extend to all kinds of circuits. For example, formore data-path-orientated stream processing circuits approaches like those adopted in the Streams-Clanguage seem much more appropriate [11].

3. ESTEREL CIRCUIT SYNTHESIS

Esterel has a semantic basis that is appropriate for synthesizing either hardware or software. Thisproperty prompted us to devise an experiment, which uses Esterel to describe a system that isfirst implemented entirely in software and then entirely in hardware. If we can get such a flowto work then we would have achieved several desirable properties including the ability to pro-duce the corresponding hardware and software from the same specification and the ability toformally analyze the hardware or software. Furthermore, we would have a lot of flexibility to par-tition the system description so that some of it is realized in hardware and the rest is mapped tosoftware.


984 S. SINGH

There are many useful applications for the ability to obtain either a hardware or a softwareimplementation from a single specification (or a hybrid of both). We are particularly interested in thecase where dynamic reconfiguration [12] of programmable logic devices is used to swap in and outhardware blocks to perform space/time trade-offs. A hardware block may be swapped out to makeway for a more important calculation in hardware or because it implements a calculation that can nowbe performed in software. In this case the function of the hardware block is replaced by a softwarethread on a processor (also on the reconfigurable logic device). This novel application requires thehardware and software components to have identical semantics. Conventional approaches involvedesigning both the hardware and software independently followed by an informal verificationprocess to establish their equivalence. The problem of trying to produce matching software andhardware blocks is one of the major impediments to the research efforts in the field of task-baseddynamic reconfiguration. We avoid the duplication of the implementation effort by ensuring thatboth resulting implementations have the same behavior and we can also prove formal propertiesabout our generated circuits.As an example of a quite simple hardware/software trade-off experiment we present the case

of a peripheral controller which can be implemented either in hardware or software. We chose areconfigurable fabric realized by Xilinx’s Virtex-II FPGA and it is on this device that we performthe hardware/software trade-offs. We use a specific development board manufactured by Xilinxcalled the MicroBlaze Multimedia Development Board, as shown in Figure 1, which contains aVirtex-II XC2V2000 FPGA.

Figure 1. The Xilinx Virtex-II development board.



Software threads execute on a 32-bit soft processor called MicroBlaze, which is realized as aregular circuit on the Virtex-II FPGA. For the purpose of this experiment we need to choose aninterface that runs at a speed, which can be processed by a software thread running on a softprocessor. We selected the RS232 interface on this board, which has all its wires (RX, TX, CTS,RTS) connected directly to the FPGA (there is no dedicated UART chip on the board). Now wehave the choice to read and write over the RS232 serial port either by creating a UART circuit onthe FPGA fabric or by driving and reading the RX and TX wires from software.The send and receive portions of an RS232 interface were described graphically using Esterel’s

safe state machine notation. The receive portion is illustrated in Figure 2. This version does not usehardware flow control.This state machine waits for a start bit and then assembles the parallel character representation

from the serial data from the RX wire and if a valid parity is produced it emits the consumedcharacter. Not all the operations required to recognize a valid character on the RX serial line areconvenient to describe using a graphical notation. For example, here we describe the notion ifshifting in a new character bit into an internal buffer using a text (in a textual macrostate). The sendcomponent is shown in Figure 3.It is possible to hierarchically build layers on top of these descriptions to add additional features,

e.g. a FIFO for the read and send channels. Graphical and textual descriptions can be freely mixed

Figure 2. The receive component of the RS232 interface.


986 S. SINGH

Figure 3. The send component of the RS232 interface.

with the graphical descriptions being automatically converted into their equivalent Esterel textualequivalents.Esterel has been used for some time for the synthesis of C software from either Esterel textual

descriptions or from the graphical state machine representations. Esterel also has the ability tosynthesize hardware, which can be the output in industry standard representations. Esterel can emithardware descriptions in VHDL, Verilog and System-C [13] as well as many other formats. Weexperimented with Esterel Technology’s implementation (called Esterel Studio) by generatingVHDL netlists and pushing them through Xilinx’s flow, which performs synthesis, mapping, place-ment and then produces a final FPGA implementation bitstream.The generated VHDL was simulated using the commercial Modelsim simulator and produced

the same waveforms as the built-in simulator provided by Esterel Technologies (which can dumpand display VCD files). The generated VHDL was also processed by Xilinx’s implementation toolsand required no adjustment for an implementation bitstream to be produced.The receive circuit is implemented using 21 look-up tables, which represents less than 1% of the

capacity available on an XC2V2000 FPGA and is competitive with hand-crafted implementations.We have experimented with the synthesis of several types and sizes of designs from Esterel. Wenoted that in all cases the generated VHDL results in implementations which are comparable withhand-crafted behavioral descriptions or readily available IP-blocks. This is an important requirementsince the inability to produce reasonable quality circuits would rule out this approach for makinghardware/software trade-offs.



We show below the interface for the VHDL generated in the case when only the receive componentis synthesized.

1 library IEEE;2 use IEEE.STD LOGIC 1164.all;3 use IEEE.NUMERIC STD.all;4 use work.receive data type pkg.all;5 use work.receivedata pkg.all;6 entity receive is7 port (clk: in std logic;8 rst: in std logic;9 rx: in stdlogic;10 valid: out std logic;11 chr: out std logic;12 chr data: out unsigned (7 downto 0)13 );14 end receive;

One point to note is that the signal that is emitted by a character is recognized and representedin Esterel as a value signal. A value signal can be either present or absent (as represented by thevalue of the chr signal) and it also has a value, which is represented by the bit-vector chr data.In this case the chr signal can be used as an interrupt or flag to some other circuit (e.g. a FIFO)or software process (e.g. an interrupt handler), which can capture the character that has just beenread. The clk signal corresponds to the baud rate of the RX input.If this circuit were to be used as a peripheral on the OPB bus then an extra component is required

to relate the clock frequency of the OPB bus to the baud rate of the peripheral. A clock dividercircuit for performing this function is easily described in Esterel. An implementation of an RS232UART with an OPB interface is shown in Figure 4.We have tested the resulting circuit by executing it on the MicroBlaze Multimedia board. Using

an integrated logic analyzer and by connecting an external terminal to the RS232 port, we wereable to observe the correct characters being recognized by the receive circuit.Next we configured the Esterel software to generate C rather than VHDL. This generated code

which generates code to implement the UART functionality. Our target embedded system was stillchosen to be the MicroBlaze Multimedia board and we instantiated a soft MicroBlaze processor onthe FPGA. We also instantiated a timer circuit that generated interrupts at the same frequency as thebaud rate. The interrupt handler code sampled the input of the RX input wire and used this valueas an input to the Esterel generated state machine. For each signal that can be emitted we definea call-back handler routine. In our case we defined a routine that simply wrote out the characterthat was read by the state machine. We performed the same experiment as before and observed theembedded software correctly reading characters from a remote terminal. This demonstrated that forthis case the Esterel flow successfully yielded both a hardware and software implementation fromthe same specification. In the software case the complete functionality of the UART was realizedin code: the only input was the RX bit, which was sampled at the baud rate. Now the developercan choose between a hard or soft implementation of an UART depending on constraints like areaand speed. We successfully tested the UART at up to 19 200 baud.


988 S. SINGH

Figure 4. An RS232 UART with an OPB interface.

4. CHECKING ASSERTIONS USING SYNCHRONOUS OBSERVERS

Given that we have the basic ability to synthesize either hardware or software from the samespecification based on a clean semantic we next decided to see if we could stay within the Esterelmethodology to try and prove the properties about our circuits.The emerging techniques for specifying assertions typically involve using an extra language

which has suitable operators for taking time (past, present and future) and logic relationshipsbetween signals. These languages are often concrete representations of formal logics and assertionlanguages are really temporal logics which can be statically analyzed. Can the graphical safe statemachine notation provide an alternative way of specifying properties about circuits which has theadvantage of being cast in the same language as the specification notation? And can these circuitproperties be statically analyzed to formally prove the properties about circuits?To investigate these questions we performed another experiment where we design a peripheral

for the IBM’s OPB bus which forms the part of IBM’s CoreConnect IP bus [14]. We chose theOPB bus because it is used by the MicroBlaze soft processor. This makes it easy for us to test andconfigure an implementation of this peripheral from the soft processor implemented on an FPGA.An example of a common transaction on the OPB bus is read or write request to a peripheral

from a master. The key feature of the protocol that we will verify with an example is that a read orwrite transaction should be acknowledged within 16 clock ticks. Unless a control signal is assertedto allow for more time, if a peripheral does not respond within 16 ticks, then an error occurs on



the bus and this can cause the system to crash. The state machine we use for the master side ofthe transaction is shown in Figure 5 and the state machine we use for an OPB slave transactionis shown in Figure 6. The behavior of the arbiter is modeled by the state machine shown inFigure 7 and the 16 tick timeout of the slave peripheral is modeled by the state machine shownin Figure 8.We considered the case of a memory-mapped OPB slave peripheral, which has two device

registers that a master can write into and a third device register that a master can read from. Thefunction performed by the peripheral is to simply add the contents of the two ‘write’ registers andmake sure that the sum is communicated by the ‘read’ register. A safe state machine for such aperipheral is shown in Figure 6.This generated VHDL for this peripheral was incorporated into Xilinx’s Embedded Developer

Kit and it was then used as a building block of a system, which also included a soft processor, anOPB system bus and various memory resources and interfaces. We wrote test programs to checkthe operation of the peripheral with a 50MHz OPB system bus. The peripheral always producedthe correct answer.Having successfully implemented an OPB peripheral from the Esterel specification we then

attempted to prove an interesting property about this circuit. We choose to try and verify theproperty that this circuit will always emit an OPB transfer acknowledge signal 16 clock ticks afterit gets either a read or a write request. If we can statically prove this property we know that thisperipheral can never be the cause of a transfer acknowledge timeout event.We expressed this property as a regular Esterel safe state machine as shown in Figure 9. This

synchronous observer tracks the signal emission behavior in the implementation description andemits a signal if the system enters into a bad state; i.e. a read or write request is not acknowledgedin exactly two clock ticks.

Figure 5. A master transaction state machine.


990 S. SINGH

Figure 6. An OPB slave transaction state machine.

One way to try and check this property is to try and use it in simulations to see if an error casecan be found. Esterel Studio supports this either by direct simulation within the Esterel frameworkor by the automatic generation of VHDL implementation files and test benches which can checkthe properties specified as synchronous observers.However, the Esterel Studio system also incorporates a built-in model checker (Prover-SL from

Prover Technology), which can be used to try and prove such properties. We used a recent version ofthe Esterel language that allows us to reason about data as well as control which is an improvementfrom the previous versions of the language. We configured the model check to see if the error signalcorresponding to a bad state being entered is ever emitted, i.e. might the circuit take longer thantwo clock ticks to acknowledge a transfer? It took Esterel Studio less than one second on an IntelQ6600 processor machine to prove that this signal is never emitted.

1 \$ esverify −v OPB.eid −checkis0 XFERACK MISSING2−−− esverify: Reading model from file ”OPB.eid”.3−−− esverify: Checking if output ”XFERACK MISSING” is 04−−− esverify: Start model−checking properties5−−− esverify: Verification complete for signal XFERACK MISSING: −−− esverify: −−6−−− esverify: Model−Checking results summary7−−− esverify: −−− esverify: Status of output ”XFERACK MISSING”: Never emitted.

We then produced a deliberately broken version of the peripheral which did not acknowledgeread requests. Within two seconds the software was able to prove that there is a case when theacknowledge signal is not asserted after a transaction and provided a counter-model and VCD file.



Figure 7. The arbiter state machine.

Figure 8. Timeout of slave after 16 clock ticks.

A conventional approach for catching such approach bugs involves either simulation (which haspoor coverage) or the use of bus monitors which snoop the bus at execution time looking forprotocol violations. A failure to acknowledge a transaction is one of the types of bugs that suchsystems can be configured to catch. However, it is far more desirable to catch such problems witha static analysis.


992 S. SINGH

Figure 9. A synchronous observer that checks for timeouts.

Figure 10. A synchronous observer that checks for the stable RNW signals.

We have also checked a series of other properties expressed as synchronous observers andformally verified them using the internal model checker. An example of another property is thatthe RNW control signal that indicates either a read or a write operation should not change duringa transaction. This property is expressed by the Esterel synchronous observer shown in Figure 10and is verified within a second for our OPB-based UART.

5. FUTURE WORK

Using a software language for hardware description often gives rise to new requirements to bettersupport low-level bit operations as well as features for concurrency. The Esterel language is currentlygoing through a standardization process which is adding many useful features including hardware



description. These features include more flexible handling of numeric values and their mappinginto corresponding bit-vectors to facilitate the integration with existing VHDL and Verilog-basedback end synthesis tools.

6. CONCLUSIONS

Initial experiments show that serviceable hardware and software performing the same function canbe produced and implemented on real hardware and embedded processors from a single Estereldescription. The possibility to enter system specifications graphically makes this method muchmore accessible to regular engineers than competing formalisms which uses languages that arequite different to what engineers are used to. For any realistic system the developer still has to writesome portions textually and become aware of the basic underlying principles of Esterel. It remainsto be seen if the cost of learning this formalism is repaid by increased productivity, better staticanalysis and the ability to trade-off hardware and software implementations.The current Esterel standardization process is likely to result in a language which is far better

suited for hardware description while retaining its unique advantages for implementing control-orientated software. This makes Esterel even more suitable for the co-design of control-orientatedsystems that span hardware and software.Another appealing aspect of this flow is the ability to write assertions in the same language as the

system specification. This means that engineers do not need to learn yet another language and logic.Furthermore, the formal nature of Esterel’s semantics may help to make static analysis easier. Ourinitial experiments with using the integrated model checker are certainly encouraging. However,we need to design and verify more complex systems before we can come to a definitive conclusionabout this promising technology for the design and verification of hardware and software from asingle specification.A very useful application of this technology is task-based dynamic reconfiguration. This method

would avoid the need to duplicate implementation effort and it would also allow important propertiesof dynamic reconfiguration to be statically analyzed to ensure that reconfiguration does not breakworking circuits.The advent of multi core and many core processors that comprise a heterogeneous mix of re-

sources which may even include embedded FPGAs present significant programming challenges andmay present mainstream developers with what are today regarded as hardware design tasks. Thecase study in this paper gives us some confidence that a co-design approach based on concurrentprogramming in Esterel can be developed into a software-based model for programming a varietyof computing devices ranging from processors to embedded FPGAs.

REFERENCES

1. Berry G, Sentovich E. Multiclock Esterel. CHARME, Livingston, Scotland, 2001.2. Celoxica Inc. Handel-C language overview. Available at: http://www.celoxica.com, 2004.3. Takach A, Bower B, Bollaert T. C based hardware design for wireless applications. Design, Automation and Test in

Europe, Munich, 2005.4. Nikhil R. Bluespec systemVerilog: Efficient, correct RTL from high-level specifications. Formal Methods and Models

for Co-Design (MEMOCODE). IEEE Computer Society, 2004.


994 S. SINGH

5. Gupta S, Dutt ND, Gupta RK, Nicolau A. SPARK: A high-level synthesis framework for applying parallelizing compilertransformations. International Conference on VLSI Design, January 2003.

6. Najjar WA, Bohm APW, Draper BA, Hammes J, Rinker R, Beveridge JR, Chawathe M, Ross C. High-level languageabstraction for reconfigurable computing. IEEE Computer 2003; 36(8):63–69.

7. Buyukkurt BA, Guo Z, Najjar W. Impact of loop unrolling on throughput, area and clock frequency in ROCCC: C toVHDL compiler for FPGAs. International Workshop on Applied Reconfigurable Computing, Delft, March 2006.

8. Yankova YD, Kuzmanov GK, Bertels KLM, Gaydadjiev GN, Lu Y, Vassiliadis S. DWARV: Delftworkbench automatedreconfigurable VHDL generator. 17th International Conference on Field Programmable Logic and Applications,August 2007.

9. Gupta RK, Liao SY. Using a programming language for digital system design. IEEE Design and Test of Computers1997; 14.

10. Singh S. Hardware/software synthesis and verification using Esterel. Communicating Process Architectures, McEwanAA, Schneider S, Ifill W, Welch PH (eds.). IOS Press, 2007; 371–378.

11. Gokhale M, Stone JM, Arnold J, Kalinowski M. Stream-oriented FPGA computing in the streams-C high level language.8th IEEE Symposium on Field-Programmable Custom Computing Machines, Napa, 2000.

12. Weinhardt M, Luk W. Task-parallel programming of reconfigurable systems. Field-Programmable Logic and Applications,2000.

13. Bruschi F, Ferrandi F. Synthesis of complex control structures from behavioral systemic models. Design, Automationand Test in Europe, Munich, 2003.

14. IBM. The CoreConnect bus architecture. IBM Data Sheet, 1999.


design and verification of peripheral control circuits in esterel

Documents