A Hardware/Software Prototyping Environmentfor Dynamically Reconfigurable Embedded Systems

Josef Fleischmann

Technical University of MunichInst. of Electronic Design Automation

D-80290 Munich, GermanyJosef.Fleischmann@e-technik.tu-muenchen.de

Abstract

Next generation embedded systems place new demandson an efficient methodology for their design and verifica-tion.These systems have to support interaction over a net-work, multiple concurrent applications and changingoperatingconditions. Therefore, besides existing require-ments like low cost and high performance, new demandslike adaptivity and reconfigurability arise. Traditionaldesign methodologies do not support exploration andimplementationof this flavor of networked embedded sys-tems.In this paper, we present a suitable methodology andaflexible experimental environment which supports designexplorationand prototyping of dynamically reconfigurableembeddedsystems based on Java specifications.

1. Introduction

Today,electronic products face a heterogeneous, rapidlychangingmarket in which the key factors for success areefficientproduct development and the ability to quicklyrespond to customer demands. This leads to the require-ment that a product should not only be adaptive via soft-ware updates, but it should also be flexible within thehardwarepart via field programmable hardware. The situa-tionbecomeseven worse for embedded systems because inmanycases their behavior has to be adaptive to the workingenvironment. More specifically, we consider networkedembeddedsystems which are able to run multiple concur-rentreal-time media applications such as audio and video.Forinstancethe frame rate of a video stream is changed bythevideo application manager if the network is congested.Thusa trade-off between picture quality and bandwidth ofthenetworkbecomes possible. In audio applications, com-pletely different compression algorithms are employeddependingon network load [11].

Combining programmable hardware, such as field-pro-grammablegate arrays (FPGAs) with microcontrollers orevendigital signal processors (DSPs) gives an entire adap-tive system. However, a flexible, configurable hardwaresolutionis also associated with costs in terms of area andtimingperformance when compared to ASIC designs. As atrade-off,hybrid embedded systems with partially fixedandpartiallyadaptable hardware combined with a proces-sorareemployed.

Ourtarget architecture basically consists of a set of pro-cessingelements (processors, FPGAs) which execute con-

1092-6100/98 $10.00 @ 1998 IEEE

Klaus BJJchenrieder, Rainer Kress

Siemens AG

Corporate TechnologyD-81730 Munich, Germany

{Klaus.BuchenriederIRainer.Kress}@mchp.siemens.de

currently. Therefore, the specification language mustsupport constructs for expressing concurrency. Several lan-guages have been proposed for describing embedded sys-tems [4], [5]. We decided to use Java which was originallydesigned for the use in embedded electronic applications toovercome the major weaknesses of C and C++ [3]. Java is amulti-threaded language and supports system descriptionsas sets of concurrent behaviors. As Java has certain built-inmulti-threading primitives, expressing concurrency andmanagement of different flows of control is greatly simpli-fied. Threads also provide an efficient way for task distribu-tion and multiprocessing. Java has all benefits of object-oriented languages. Because of its class, package and inter-face concept, it encourages modular and small programs.Especially for designing embedded systems, features likemulti-threading, exception handling, synchronization, codereuse (e.g. Java Beans), security and network programming(e.g. function shipping for maintenance and softwareupdates) are of great importance. The prospect of commu-nicating with an embedded system from anywhere on theInternet is pushing more and more designers towards Java[12]. For modeling real-time systems, language extensionshave been proposed [9], [10]. However, the major issuewhich currently hinders the wide-spread adoption of Javaas a development language is its execution performance.But as soon as just-in-time compilation tools and nativecode compilers mature, the performance gap will be closedand Java will increasingly be adopted in the domain ofembedded hardware/software systems.

Related work concerning networked embedded systemsconcentrates on developing stochastic models for perfor-mance verification [6]. Our goal is to provide a semi-auto-mated co-synthesis and co-simulation framework whichsupports fast prototyping of hardware/software systemsspecified in the Java language. Within this co-design envi-ronment, it is possible to evaluate different design alterna-tives and gather profiling information during execution ofthe alternative prototype designs within a simulation test-bench. The most appropriate mapping of functionality tohardware and software parts is determined in the partition-ing step. Also, portions of the design which are imple-mented in reconfigurable hardware and portions whichremain unchanged during run-time can be identified. Back-annotation of data gathered during the co-synthesis, co-emulation, and profiling steps provides the necessary infor-mation to guide the partitioning and optimization process.

105

The remainder of this paper is organized as follows. Insection 2 we introduce the new concept for co-synthesisand co-simulation of reconfigurable hardware/softwaresystems based on the Java specification. This includes codegeneration for software and hardware parts, generation ofthe hardware/software interface and managing the execu-tion of the generated prototype. The current implementa-tion of the experimental hardware platform and results arepresented in section 3. Finally, some concluding remarksand an overview of our future work are given in section 4.

2. Co-synthesis environment

Our framework supports a software oriented strategy forco-synthesis as we start from a Java specification and iden-tify parts which are to be implemented in hardware. In con-trast to previous approaches we integrate co-verification ofthe system prototype by co-emulation of the hardware/soft-ware architecture. Verifying the correct interaction betweensoftware and hardware is a key problem in the design of acombined system. Thus, we propose a design flow whichincludes a complete synthesis flow and accommodates fastprototyping. After identifying a suitable partitioning of thesystem, the appropriate hardware/software interface is gen-erated by an interface generator. The software part isinstrumented and bytecode is generated for execution onthe Java virtual machine. The hardware part is synthesizedand mapped to the reconfigurable FPGA target platform.The interface is partially realized in software and in hard-ware. The complete design flow of the prototyping environ-ment is shown in figure 1. A description of the individualsteps is given in the following.

2.1 Partitioning

During the specification phase, only the software branch(left path in figure 1) is used for functional validation andprofiling. After that, the initial specification is partitionedinto a part for the execution on the host PC (software meth-ods) and a part which is executed onto the FPGA hardwareplatform (hardware methods). Currently, the granularity ofthe partitioning is the level of Java methods. For futureenvironments, a partitioning based on loops or on basicblock level will be examined. All methods chosen for hard-ware can also run on the host PC, but not vice versa. Thismeans that during code generation bytecode is generatedfor all methods whereas FPGA configuration files are gen-erated for the individual hardware methods only. The run-time system (RTS) reads information from the partitioningstep and decides according to the partitioning whether amethod is scheduled onto the host PC or onto the FPGAhardware. The RTS also manages dynamic reconfigurationof the hardware at run-time.

For each hardware method, an interface description isautomatically generated. It consists of aRT-level VHDLframe for inclusion into the hardware building block, and ahardware method call for inclusion into the software code.

Code generation for the hardware as well as for the soft-ware part is based on the Java compiler guavac [1]. Guavacconsists of a scanner, lexical analyzer, and a part for theevaluation of the internal tree representation. The transla-tion of a Java method into bytecode or VHDL is sketched

I

,

in figure 2. Up to the internal tree representation, code gen-eration for hardware and for software is both the same. Theinput is divided by the scanner into a token stream. Next,the tokens are mapped to an internal tree representation(expression trees) according to the semantic rules. Ofcourse, also manually designed VHDL components canbeused for the hardware part.

2.2 Hardware code generation

Code generation for the hardware part consists of threemajor steps:. High-level synthesis (HLS) of the selected Java

methods, which are to be implemented in hardware

operatorlibrary

softwaremethods

testlibrary

Fig. 1. Prototyping environment

106

J

.Register-transfer-level synthesis of the VHDLdescription which has been generated by the HLS Toolin the previous step and logic optimization of theresulting netlist.Layout synthesis and generation of the configurationdata for the target FPGA hardware platform

High-levelsynthesis. In the high-level synthesis step,mainemphasis was laid on producing synthesizable VHDLcode.Semi-automatic synthesis will be an essential featureofourco-design framework, as we want to encourage itera-tionsduring the design exploration phase. Therefore, a syn-thesis tool has been developed, which is based on anoperatorlibrary. For all selected Java methods which com-plywith the restrictions of our current library synthesizableVHDLis generated. Based on the internal tree representa-tion,high-level synthesis step is performed using standardtechniques.The design representation is split into a data-pathpart and a controller part. Expressions and statementsare converted into corresponding VHDL constructs for adatapathdescription. The sequence of execution and loopcontrol constructs as well as conditional constructs aretransformedinto a finite state machine (FSM) representa-tion.The HLS tool also produces corresponding synthesisscriptswhich are used afterwards for logic synthesis.RT-Ievelsynthesis. The output of the HLS step is a reg-ister-transfer level description containing combinationalbuildingblocks for the datapath and a finite state machinefor the controller part. Before logic synthesis of the RT-

PARSER

,[i]~G:dWJ[3[]]IT]l§[Jmrn[3[]]IT]w~

int func(int a){ ,

Int z,r = 0;for (z=O;z<a; z++)r+= a;

} return r;

Internal Tree Representation

Token Stream

~~~0: iconst 01: istore-32: iconsf 03: iload "24: iload-16: iUcm[>ge 139: iload 3

10: iload-111: iadd-12: istore 313: iinc vindex:2 by 116: goto 6552419: iload 320: iretumJAVABytecode VHDLComponent

Fig. 2. Transformation of the Java specification intobytecode and RT-levelVHDL

A 1: IN JAVA INT'R"ET:OUT JAVA_INT);

ARCHITECTURE HWof ex tunc ISCOMPONENT add intPORT(...) -

WHEN State 3...RET <= VI_3;

1

level description, an automatically generated VHDL framefor interfacing the hardware method to the software parti-tion is added to the hardware description produced in theprevious step. The VHDL frame consists of a reconfigura-tion controller and an interface for passing arguments andresults to the Java hardware method. This interface isdescribed in more detail in section 2.4. The complete RT-level description is synthesized with SYNOPSYSDESIGNCOMPILER.

Technology mapping, placement and routing. Theresulting EDIF netlist of the RTL synthesis step is furtherprocessed with commercial tools. After technology map-ping, placement and routing has succeeded, a valid config-uration file for the hardware method is written. This file isadded to a hardware method library. The run-time systemtakes the necessary configuration files from this library.

If the placement and routing fails for the target FPGAdevice, no configuration file is generated and of coursenone can be added to the hardware method library. Thus,this method has to be executed on the host PC. Currently,no support for partitioning a single hardware method ontoseveral FPGA devices has been implemented. Besides thissemi-automatic code generation for the hardware, manu-ally designed configuration files for the FPGAs can be inte-grated as native methods into the Java code.

2.3 Softwarecode generationCode generation for software part is done using conven-

tional compilation methods. As mentioned earlier the JavaParser transforms the specification into a token stream(figure 2). From the token stream the expression trees arebuilt according to grammatical rules. Possible optimizationof the code can occur at this stage. A list of all expressiontrees is processed to get a list of bytecodes which are savedas .class-files. These object files are stored in the softwaremethod database (refer to figure I).

2.4 Interfacing hardware and software

In order to facilitate the exchange of data between thehardware and the software part of the system a specialinterface concept and an automated interface generatorhave been developed.The software part. Since the chosen level of granularityis the Java method level, only little extensions were neces-sary on the software side. As previously mentioned, in thecurrent implementation of our co-design environment soft-ware methods are executed by the interpreter. Forinterpreting Java bytecode, we use the GNU InterpreterKAFFE,as the sources are in the public domain. For using itin our co-design framework several extensions to the inter-preter were necessary. First, the interpreter must be able toread in the partitioning information, i.e. which function isto be executed in hardware and which method in software.If the control flow during bytecode interpretation reaches ahardware method, then mechanisms for synchronizationand communication become necessary. Method argumentshave to be delivered to the hardware driver and the corre-sponding results must be read back. During execution of amethod in hardware, the calling thread in software is sus-pended. The calling thread resumes normal operation after

107

- - -- - -- - - - ~------

the results of the hardware method have been sent back. Inthe current implementation only one thread at a time isallowed to access the emulation hardware, therefore a suit-able synchronization mechanism has been implemented.For evaluating system performance, the interpreter had tobe equipped with functions for gathering profiling data.Therefore, routines for measuring times for data processingand for communication between hardware and softwarehad to be integrated in the Java run time system.The hardware part. The same way the software part hadto be extended for communication, the hardware designalso needs extensions for exchanging information when-ever a request for processing data occurs. Thus, a conceptfor a flexible, parameterizable communication interface forthe hardware design has been developed. Depending on thenumber and size of arguments that the hardware methodhas to process, an appropriate interface frame is generatedfor each Java hardware method. The interface generatoruses information provided by the high-level synthesis tooland automatically generates a register-transfer leveldescription of the VHDL frame with the correct size. Thestructure of this interface frame is depicted in figure 3. Theframe consists of a set of registers for storing input and out-put data of the corresponding Java method. Furthermore, itcontains a small logic block for handling control signalswhich are necessary for interaction with the run-time sys-tem. This includes signals for starting, resetting the hard-ware process and a ready signal which indicates that thecomputation in hardware has finished and that the resultscan be read back.

The VHDL component for the Java hardware methodwhich has been generated during high-level synthesis isembedded into the VHDL frame produced by the interfacegenerator. Then the complete design is synthesized for theFPGA platform as described in section 2.2.

2.5 Run-time system

The run-time system (RTS) is responsible for managingexecution and interaction of hardware and software meth-ods. Therefore, it relies on a database which contains theset of methods which are executable in either hardware orsoftware and a number of methods for whIch both hard-ware and software implementations are available. The soft-ware executables (Java classes) are stored in Java bytecodeformat and the corresponding hardware blocks which areemulated on the FPGA board are stored as configurationbitfiles.

During co-simulation the run-time system schedulesmethods for execution according to the current partitioning

EQ)

~CJ)Q)Ei=c::Ja:

~

Fig. 3. VHDL frame

I

table. Software methods are executed on the Java VirtualMachine (JVM) on the host workstation as shown infigure 1. As we chose a software-oriented approach, theexecution flow of the combined system is dominated by thesoftware part of the system.

The run-time system also manages execution of tasksonthe emulation platform. The set of currently availableFPGAs and communication channels is specified in a con-figuration filt!. During co-simulation when control flowinone of the threads reaches a hardware method, the run-timesystem determines whether the corresponding configura-tion bitfile has already been downloaded to an FPGA. Atthe beginning of the co-simulation procedure none of theFPGAs is configured with a bitstream. In this case, the run-time system determines an available FPGA and triggers thedownload mechanism. In case the bitfile has already beendownloaded to an FPGA, the RTS determines the addressof the FPGA containing the currently requested hardwaremethod, and starts transfer of data which has to be pro-cessed by this method. After the emulated method has fin-ished processing, it sends an interrupt signal to the RTS andthe results from the computation can be read from theresult register of the FPGA design. As previously men-tioned, only one thread at a time is allowed to access theemulation hardware in our current implementation. Duringemulation of a hardware method on the FPGA, the callingthread is suspended but any other software thread can beexecuted on the Java virtual machine at the same time.

2.6 Simulation and Refinement

Executing simulation with the actual hardware givesfeedback for the initial partitioning process via the profil-ing step. The prototype is executed in a testbench environ-ment where several test cases exist in a test library. Thesetest cases consist of data sets for the execution of the Javaspecification. A profiling step measures execution times forthe hardware and the software part, as well as the commu-nication time via the interface. These results are directlyfed back to the partitioning process. The goal is to improvethe partitioning especially when the granularity of the par-titioned parts changes or if methods are clustered. Thisfeedback loop is currently under development.

3. Experimental results

For verifying the feasibility and studying different con-cepts of our new approach, an implementation of the pro-posed design flow and the corresponding hardware/software co-emulation engine has been done. Our initialimplementation was based on an dedicated prototypingboard containing four SRAM based FPGAs [2]. This solu-tion was found to be inefficient for dynamically reconfig-urable embedded systems. Chip reconfiguration requirestoo much time in traditional FPGA architecture, and partialreconfiguration during run-time is impossible. Further-more, a rather sophisticated mechanism for interfacingbetween processor and FPGA hardware had to be devel-oped. Because of these experiences, we decided to use anew FPGA architecture in our new implementation whichovercomes this limitations. An overview of the hardware/software prototyping platform is given in figure 4.

108

]

Hardware. The workstation is used to enter the Javaspecification,compiling Java to bytecode and executing thebytecodefor the software part of the system. Furthermore,the different synthesis tasks necessary for moving dedi-catedJava methods to the FPGA emulation board are car-ried out on the host workstation. The run-time system isalso implemented in software on the host. For implement-ing the hardware part of a prototype, a dedicated FPGAboardis connected to the workstation over the PCI bus. Weusedthe XC62ooDS board which basically provides a PCIinterface, and a reconfigurable processing unit XC6216.Thecard also includes two banks of memory, which maybe accessed from either the FPGA or the PCI bus. For amoredetailed description see [8].

Performance. For evaluating the performance of ourplatformand identifying bottlenecks, we used some smalldata-oriented examples specified in Java. The XC6216reconfigurableprocessing unit that is currently used has avery limited gate capacity (approx. 16000 gate equiv.).Largerdesign examples will be tested as soon as a largerchipof the XC6200 family or a board with more chips isavailable.The most prominent feature of this FPGA is itsintegratedmicroprocessor interface. As this interface sup-portsdirect register reads and writes over an address and adatabus. Thus transfer of arguments and results betweenhardwareand software parts of the prototype is greatly sim-plified('wireless I/O'). Similar to a memory access, allconfigurablecells and registers on the chip can be readfromand written to at run-time. The second important fea-turefor our target application area is the high-speed recon-figurationcapability of the chip, which is mandatory in asystem which has to adapt to different operating condi-tions.For our sample designs the times needed for recon-figurationof the complete hardware part varied between 18and300ms depending on the size of the design. After addi-tionaloptimization of reconfiguration process over the PCIinterfaceof our board, these times have been cut down to4.5to 29 ms. When testing the speed of the hardware/soft-wareinterface, we found that in one second about 84000registerwrites (32bit) or 63000 register reads are possible.However, the PCI interface implementation on theXC6200DSboard has been identified as a bottleneck. Forreading and writing to the on-board SRAM, only datatransferrates of about 4 and 7 MB/s respectively can beobtained(dependingon board frequency) and this is signif-icantly lower than in typical PCI applications. Relatedresearch [7] showed that with the XC6216 significantspeedups for image processing applications can beobtained.For estimation of worst case behavior, we used anapplicationconsisting mostly of multiply and add opera-tions,whichare ideally suited for a standard microproces-

0- PCI-Bus

Fig.4. Experimental platform

sor like a cached Pentium 133 as used in our host PC. Forour dynamic Java application (including 3 hardwaredesigns; 82 dynamic reconfigurations) execution times of4.ls for the hardware/software prototype compared to 2.8sfor the pure software execution were measured. These arevery promising results concerning performance of the exe-cution of a hardware/software system prototype, as 80-90%of the execution time are due to communication over thePCI interface. Therefore, we will benefit greatly from animproved version of the PCI interface which will becomeavailable in the near future.

4. Conclusions

When developing complex systems, intelligent trade-offsbetween hardware and software components are necessary todeliver the design best satisfying performance and cost con-straints. Therefore, designers need a complete developmentframework that facilitates such trade-offs. A new concept fortool-assisteddesign exploration and fast prototyping of hard-ware/software systems has been proposed in this paper.Starting from a system specification in Java, a novel designflow has been presented which is targeted to next generationembedded systems including reconfigurable hardware. Itsupports trade-offevaluation, interface generation and verifi-cation of the design by co-emulation. The focus of currentresearch is on the implementation of different signal process-ing applications within the prototyping framework. Futurework will concentrate on integrating a seamless VHDL toFPGA synthesis design flow. For instance, currently avail-able tools for this new FPGA architecture still require man-ual intervention of the designer during layout synthesis.

5.[1]

[2]

References

D. Engberg: GUAVAC home page; Internet URL: http://http.cs.berkeley.edul -engberg/guavac/, 1997.J. Fleischmann, K. Buchenrieder, R. Kress: Co-Design ofHardware/Software Systems based on Java Specifications.Tech. Report TUM-LRE-97-4, Tech. Univ. of Munich, 1997.J. Gosling, B. Joy, G. Steele: The JavaTMLanguage Speci-fication; Addison-Wesley, Reading Massachusetts, 1996.D. Gajski, F. Vahid, S. Narayan, J. Gong: Specification andDesign of Embedded Systems. Prentice Hall, 1994.R. Helaihel,K.Olukotun:Javaas a SpecificationLanguagefor Hardware-Software Systems. In Int. Conf. on Com-puter-Aided Design (ICCAD), 1997.

[6] A. Kalavade and P. Moghe: On the Performance Verifica-tion of Embedded Systems with Concurrent DynamicApplications. In Asilomar Conf, Nov. 1996.

[7] T. Kean, A. Duncan: A 800MpixeVsec ReconfigurableImage Correlator on XC6216. In Int. Workshop on Field-Programmable Logic and Applications, 1997.

[8] S. Nisbet, S. A. Guccione: The XC6200DS DevelopmentSystem. In Int. Workshop on Field-Programmable Logicand Applications, 1997.

[9] K. Nilsen: Embedded Real-Time Development in the JavaLanguage. In Embedded Systems Conf. West, 1996.

[10] R. Passerone, et al.: Modeling Reactive Systems in Java. InInt. High Level Design Validation and Test Workshop, Nov.1997.

[II] H. Schulzrinne, et al.: RTP: A Transport Protocol for Real-Time Applications. RFC 1889, Audio-Video TransportWG, Jan. 1996.

[12] T. Williams: Java goes to work controlling networkedembedded systems.Computer Design 35, No.9, Aug. 1996.

[3]

[4]

[5]

109