SMPS An FPGA-based Prototyping Environment forMultiprocessor Embedded Systems

SMPS:An FPGA-based Prototyping Environment for Multiprocessor Embedded Systems

Ankit Mathur ankit@https://www.wendangku.net/doc/1c17794983.html, Network Appliance,

Bangalore,India

Mayank Agarwal Soumyadeb Mitra magarwa2@https://www.wendangku.net/doc/1c17794983.html, mitra1@https://www.wendangku.net/doc/1c17794983.html, Department of Computer Science,

University of Illinois at Urbana-Champaign,USA

Anup Gangwar anup@cse.iitd.ac.in

M.Balakrishnan

mbala@cse.iitd.ac.in

Subhashis Banerjee

suban@cse.iitd.ac.in

Department of Computer Science and Engineering Indian Institute of T echnology Delhi,India

ABSTRACT

Streaming media applications represent an important class of applications for embedded systems.Recent advances in design-space exploration of architectures for such applica-tions have pointed towards the suitability of Multiprocessor System on Chip(SoC)solutions.Multiprocessor SoCs not only o?er higher performance,but can also lead to solutions which are cheaper cost wise.A typical synthesis methodol-ogy for such architectures would require a validation stage at the end of?nal system integration.The wide availabil-ity of cheap and large FPGA devices,advances in automatic synthesis from VHDL/Verilog and abundance of high perfor-mance computing platforms enables the design of a generic validation system for such Multiprocessor SoCs.

In this paper we present the design and implementation of Srijan Multiprocessor Prototyping System(SMPS).SMPS is a system for rapid prototyping and validation of single chip application speci?c multiprocessor systems.The indi-vidual computing elements are RISC processors,coproces-sors which lie in the processor pipeline,and ASICs which connect directly to system bus.The system is a tightly coupled multiprocessor with shared memory and shared ad-dress space.A Real-time Operating System(RTOS)pro-vides task scheduling and access to shared resources.SMPS can support this entire design-space.The system is pre-sented as a parameterized VHDL based on the open source Sparc V8compliant Leon processor and a homegrown light-weight RTOS,RtKer-MP.The entire VHDL is con?gurable using a GUI,has support for cache coherency,choice of arbi-tration policy and easy integration of custom processing en-gines.RtKer-MP allows for a pluggable scheduler,dynamic and static scheduling policies,static and dynamic task mi-Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for pro?t or commercial advantage and that copies bear this notice and the full citation on the?rst page.To copy otherwise,to republish,to post on servers or to redistribute to lists,requires prior speci?c permission and/or a fee.

FPGA’05Monterey,California USA

Copyright200X ACM X-XXXXX-XX-X/XX/XX...$5.00.grations domains and variable interruption frequencies for separate processors.The pluggable scheduler interface al-lows for quick exploration of various scheduling policies for

a feedback to the estimation systems.

1.INTRODUCTION

Embedded multiprocessor platforms are becoming quite popular both in the research domain as well as commercial domain[3][9][12][1][20][10][11].While commercial ven-tures are focussing more on the high performance achieved by these multiprocessors,researchers are focussing on archi-tecture customizations on a per application(domain)ba-sis.A driving force is the fact that multiprocessor solutions may lead to solutions which are cheaper cost wise than their uniprocessor counterparts[22][4].

However,the design-space for multiprocessor systems is huge which makes it practically impossible to explore it ex-haustively.Moreover the lack of retargetable tools such as compilers and simulators for such vast design-space com-plicates the problem further.Researchers try to utilize a top-down approach,with separate tools for each stage[19] [1][5].The speed of execution of tools decreases when one moves from top to bottom and the accuracy of results in-creases.Approach is to achieve quick design-space pruning at the top-level and do a more re?ned search at the lower levels.Typical tools at the top-level include hardware and software estimators for estimating cost of synthesized com-ponents and software performance on customized architec-ture respectively and partitioners,which decide to which processing element(ASIC or Processor)a particular piece of computation is mapped.At the lower-level a retargetable compilation system coupled with a retargetable multipro-cessor simulation system gives the system performance.A ?nal prototyping stage using FPGA devices with all the sys-tem components in place serves as a proof-of-concept as well as gives con?dence that the system works.More details on application speci?c multiprocessor synthesis are present in Section3.

In this paper we present Srijan Multiprocessor Prototyp-ing System(SMPS),which can be e?ciently utilized for val-idation of application speci?c multiprocessor systems.Our

system consists of a tightly coupled multiprocessor architec-ture,Leon-MP and a light weight retargetable parameter-ized RTOS,RtKer-MP.The entire system is easily down-loaded onto reasonably large FPGA devices such as Xilinx XC2V3000-FF-1152-5.The ready availability of large and fast FPGA devices coupled with cheap and e?cient synthe-sis tools makes such a system extremely practical.Also, SMPS can be used to provide accurate feedback to estima-tion tools and partitioners while the algorithms for these tools are still evolving.

The rest of this paper is organized as follows:Section2, discusses the previous work done in this domain.Section 3,gives an overview of a synthesis methodology for mul-tiprocessor embedded systems,Srijan.Section4,presents details about the multiprocessor architecture and parame-terized components of the hardware part of SMPS.Section 5,discusses RtKer-MP,a lightweight parameterized RTOS with a pluggable scheduler.Section6,gives more details on the implementation of this system.Section7,discusses some results and Section8presents conclusions and gives directions for future work.

2.RELATED WORK

A variety of Rapid Prototyping systems are available in both research as well as commercial domain[15],[21]RPM Rapid Prototyping System[6][18]etc.Also there are soft-ware which allow one to explore system-level alternatives [16],COSSAP/CoCentric System Studio from Synopsys,Sig-nal Processing Workbench(SPW)from Cadence and are termed as rapid prototyping systems.However,our focus is on actual prototyping and validation which is comparable to systems o?ering rapid prototyping facilities using FPGA devices.

Predominantly the systems reported either in research or commercial domain(e.g.[15])are suitable for one ap-plication(or domain).In such systems user can rapidly change the system con?guration using a few available al-terntatives.On the other hand there are general proto-typing platform(e.g.[6],[18]etc.)which allow users to prototype large systems using inexpensive large number of FPGA devices.However,as large FPGA devices are now available inexpensively,the simplicity of prototyping using a single large FPGA device,coupled with widely available CAD tools speaks heavily in their favour.In principle we are also o?ering a parameterized system for a special do-main,which allows con?guration using a wide variety of pa-rameters,similar to[15],since such systems are speci?c to application,no comparison is possible with other such ap-plication speci?c or general prototyping platforms.In our knowledge,no such system as is being reported here,exists.

3.DESIGN FLOW FOR MULTIPROCESSOR

EMBEDDED SYSTEMS

Figure1,shows the architecture design space being tar-geted under the Srijan project.Processing elements can be plain RISC processors,Application Speci?c Instruction Pro-cessors(ASIPs)or ASICs.The system uses shared bus and shared address space for communication amongst processing elements.Memories can either be connected to processing elements(local memories)or connected to the bus using memory controllers.Application representation under Sri-jan is using Kahn Process Network semantics(KPN)

[17].

Memory Bank

Figure1:Srijan Architecture Design Space

In KPN processes communicate using FIFO channels which are assumed to be unbounded(in?nite size).As is easily ob-servable there is tremendous amounts of architectural?ex-ibility.However,to properly utilize this?exibility e?ecient design-space exploration mechanisms need to be

devised.

Figure2:Srijan Synthesis Flow

Figure2,gives the synthesis?ow for a methodology for synthesis of application speci?c multiprocessor systems,Sri-jan[1].Application,represented using KPN semantics,sys-tem level constraints such as those on total power,area and performance and component library containing processing elements,memories etc.are the inputs to this synthesis system.The system level design space exploration is per-formed using hardware and software estimation systems and the system level partitioner.Partitioner invokes hardware and software estimators to evaluate individual design alter-natives at a very high level of abstraction details of this are present in[11].

Once the system level alternatives have been decided,the

choices are passed onto the various subsystems.These in-clude the C-to-VHDL translator,for synthesis of various co-processors and ASICs,processor customization subsystem, RTOS customization etc.Processor customization can in-clude customization of processor datapath width,addition of coprocessor which lie in the processor pipeline etc.RTOS customization includes formation of task migration domains (more details are present in Section5),decision on interrup-tion frequency for individual processors etc.It need to be noted that for design-space exploration C-to-VHDL transla-tion is not required,a retargetable code generator,coupled with a retargetable simulation system provides the necessary performance numbers.After the design-space exploration is over,?nal system integration with all the synthesized VHDL modules is performed and a FPGA prototype is formed. 4.LEON-MP:A PARAMETERIZED SCAL-

ABLE MULTIPROCESSOR SYSTEM

Let us now look at the hardware portion of our prototyp-ing system in more detail.Leon-MP,the hardware compo-nent of SMPS,is a tightly-coupled shared-memory shared address-space multiprocessor system.It is based on the open source Sparc V8compliant Leon uniprocessor core. LEON2uniprocessor[13]is a synthesizable VHDL model of a32-bit RISC processor compliant with the SPARC-V8 Instruction Set Architecture.The integer unit consists of a5-stage pipeline,and there are separate instruction and data caches.Full source code is available under the GNU LGPL license,allowing free and unlimited use in both re-search and commercial applications.The model is highly con?gurable,and particularly suitable for system-on-a-chip (SOC)designs.Extending this work to develop Leon-MP for SMPS,however,presented its own set of multiprocessor-related issues and challenges.Here we present the design and features of Leon-MP and try to capture the major is-sues encountered during its development.We also describe the major customization opportunities o?ered by our sys-tem.

4.1Design of the Leon-MP

System

Figure3:Leon-MP system architecture Figure3shows the block diagram of Leon-MP system.It is a tightly coupled multiprocessor system with a a variable number of Leon[14]processors attached to the shared AHB bus.It provides two snoopy protocols mechanisms for cache coherence,invalidate and update.Separate IRQ controllers and timers are associated with each processor to provide variable timer interruption frequency and reside on APB bus.Also,these IRQ controllers can be used for interfacing with external peripherals.The timers and IRQ controller con?guration registers are accessible at unique locations on the APB bus.Also,the application designer may choose to deliver certain interrupts to certain processors only.All pro-cessors share the two UARTs which provide communication with external world.The multiprocessors currently does not contain any memory management unit(MMU).Access to memory is managed through a memory controller.Also, there is debug support on the system,and one can attach a(optional)Debug Support Unit(DSU)to any Leon IU, which allows non-intrusive debugging on the testbed.It can communicate with an outside debugger such as gdb.

Some registers are added to the AHB bus as slaves.Two of these,the Boot Register,and the Boot Processor Stack Pointer Register,are used for synchronization during the booting process.Slave processors wait for the contents of these registers to be written by the Boot Processor so that they can start operation.Some other registers also reside on the AHB,referred to as the Lock Locations.These are non-cacheable memory locations and are used to implement atomic locks.Atomic instructions such as swap and ldstub are guaranteed to behave properly when using these memory locations.These lock locations have high-speed,low-latency access,as they reside on the AHB.They can be used to im-plement the semaphore operations in Operating Systems. Each processor is assigned some CP U Id by means of a number hard wired in a reserved?eld of a CPU register. Based on these Id s,one of the processors is designated as the Boot P rocessor(BP),which takes control during the booting process,after which it functions as a normal pro-cessor.Rest of the processors act as Application P rocessors (AP).

4.2Issues and Challenges in developing Leon-

MP

There were a number of challenges and issues encountered in the design and development of Leon-MP system.Our de-sign decisions were motivated by high performancee as well as?exibility and ease of customizability.Simple protocols were chosen since they consume less logic and in such a con-strained environment,they are empirically found to perform well.Here are some of the major issues encountered:

Booting:As soon as the processors are given a reset (external input),they start executing from absolute loca-tion0x0.The boot code residing at this location recog-nizes each processor separately using a unique processor ID which is hardcoded during synthesis inside each proces-sors processor status register(PSR).While all the proces-sors with IDs other than zero(slaves)go into a loop,the processor with ID zero(boot processor)performs a num-ber of tasks.The slaves busy wait on a register synthe-sized onto the AHB bus,this is shown in Figure3as boot register.The boot processor is responsible for initializa-tion of peripherals,detecting the on-chip memory and?-nally waiting for a program to be loaded into memory using the serial port.Once the program is loaded into memory the boot processor stores start address of the program in the boot register,and stores its stack pointer in the stack pointer register,which is shown in Figure3,as BP SP Reg.As soon as the slaves see a non-zero value into the boot register,they read the BP SP Reg.and set their own

stack pointer using the following formula:Stack P ointer= BP SP Reg.?20?1024?P rocessor ID.This provides an initial separation of20KBytes to each of the processor’ss stack pointers.Having set their stack pointer,the processors jump into the code location pointed to by the boot register. Synchronization:An interesting feature of the testbed is Lock Locations.These are?ve registers which are sit-ting on the AHB bus and provide one cycle access for both read and write.These locations are used by the RTOS run-ning on this setup to provide mutual exclusion(mutexing) to threads using semaphores.During the course of develop-ment of this testbed,we realized the high logic area required for maintaining hardware cache coherence.In this testbed, we have SRAMs acting as the shared memory.These pro-vide three cycle standard read and write access and2cycle burst mode read and write access.In view of this,all the caches are write through.To maintain cache coherence all that is required is to update the values in caches while data is being propagated through the shared AHB bus.However, to avoid race conditions during mutexing,high amount of additional logic is required which makes little sense for Em-bedded Systems.An empirical study by us revealed that the Embedded Multiprocessor applications make use of RTOS provided mechanisms to achieve mutexing.Moreover,the number of locks required by RTOS to achieve this is not high.In view of the above discussion,lock locations are a meaningful addition to such multiprocessor Embedded Sys-tems.

Cache Coherence:For reasons identi?ed above,the cur-rent system has the implementation of a very simple proto-col,which is based on a write-through mechanism.We give the choice of having an invalidate or an update protocol. This protocol is justi?ed since the cache size is very small, and moreover,the penalty of fetching from the main memory is not too large(3cycle normal and2cycle burst).Future directions could include implementation of more complex protocols with many more states such as the Berkeley pro-tocol and Illinois protocol.Here,however,we would need to weigh the bene?ts obtained against the cost of extra logic consumed.

Bus Arbitration:A round-robin arbitration policy is implemented.Initially the bus is allotted to processor with highest index(3in case of quad processor)if it is request-ing the bus.Once this processor releases the bus,then it is checked whether there are any requests from the just next priority processor(index2here),followed by processor with index1and subsequently with processor0.After servicing the processor with index0,it again starts with processor with index3and this keeps repeating.

Testing and Debugging:The VHDL model of the LEON processor comes along with a SPARC disassembler in the DEBUG package.It is used by the test bench to disassem-ble the executed instructions and print them to stdout(if enabled).Thus,as the VHDL model of the processor exe-cutes instructions,the SPARC disassembler implemented in the debug package pops up the instruction being executed over the simulator console.However,in case of multiproces-sor,one also needs to know the processor on which it is being executed.This information is important for understanding the?ow of instructions on di?erent processors and the e?ect of the arbitration policy on bus allocation.To achieve this, we have extended the disassembler to su?x each instruction with the processor number on which it is being executed. This can be used to study the?ow of events in the system.

4.3Customization Opportunities in Leon-MP Leon-MP o?ers numerous architecture customization https://www.wendangku.net/doc/1c17794983.html,ing a GUI,we can select a number of parame-ters such as the number of CPUs,cache sizes of the di?erent processors,whether to add a hardware multiplier/divider unit to the processors.The GUI can also be used to se-lect the desired bus arbitration policy,as also the choice of cache coherency protocols between write-invalidate and write-update protocols.In addition,the testbed contains many components which can be programmed at run-time to achieve heterogeneous con?gurations.There are separate timers for each of the processors and these can be con?gured to have separate interruption rates for individual processors. Thus,application portions which need high throughput can have slow interruption rates and big time slices,whereas components which need to respond to stimuli fast can have high interruption rates.Separate programmable IRQ con-trollers allow the ability to select the type of interrupts that are to be delivered to a particular processor.For example, one processor can service all the I/O interrupts,another can service network,etc.Since the IRQ controllers are memory-mapped,processors can also interrupt each other by means of Inter-Processor Interrupts.Also,IRQ controllers can be simpli?ed based on the types of interrupts they are going to service.

FPU

Local Memory

Figure4:A Heterogeneous Multiprocessor Con?g-uration

Leon-MP is easy to extend by adding custom policies and components.For instance,user-provided ASIC modules can be easily added on the bus for hardware portions of the sys-tem.Figure4shows an example of a con?guration that can be achieved with Leon-MP.The application has a hardware portion which is implemented as an ASIC and is supported on the high-speed bus as a master.Besides this,there are three processor on the bus.These processors are customized for the software components mapped onto them.One of the processors has?oating-point intensive code mapped onto it and hence is enhanced by adding a Floating Point Unit (FPU)coprocessor.Another processor has a local memory attached to it to reduce tra?c on the global shared memory. Currently,we are working on adding support for di?erent functional units and local memories for individual proces-sors in Leon-MP,as well as develop a library of hardware components that can be added onto the system.

5.RTKER-MP:A PARAMETRIZED RTOS

FOR LEON-MP

The Leon-MP system,like any typical embedded environ-ment,is highly constrained in terms of memory and process-ing resources.For the type of applications being targeted, individual tasks would typically have timing and other con-straints to meet.A light-weight real-time operating sys-tem(RTOS)is required for real-time task scheduling and for management of shared resources among the competing tasks.Such an RTOS would be minimal by providing sup-port only for the basic primitive operations.For additional features required such as device support and?le systems, custom components would be added on a per application basis.

5.1Need for Our Own RTOS

In the Srijan framework,there are further opportunities to customize RTOS for an application.Since the partitioning of tasks among processors is static,with no global migration allowed,there is scope for di?erent local scheduling policies in each partition rather than a common global scheduling policy.A partition could possibly consist of several proces-sors.Further,parameters which characterize these schedul-ing policies,such as time slice,may be customized for each scheduling policy selected.An intelligent partitioning algo-rithm would,based on the scheduling model,group together related tasks which would perform better under a common scheduling policy on an appropriate computation unit.Also, given the partitioning and architecture information,schedul-ing estimates can be generated.If constraints are not met with the help of previous output of partitioner,these can be used to re?ne the partitioning.Re?nements would try to generate better schedules.This iterative re?nement might be carried out till the constraints are met.

We needed an RTOS that is able to exploit all the above peculiarities of our framework e?ciently,besides being suit-able for the above re?nement process.Flexibility in the choice of components as well as scheduling and migration policies was also required.Due to these considerations we developed RtKer-MP,which is a home-grown multiprocessor RTOS for SMPS.

5.2Design of

RtKer-MP

Figure5:RtKer-MP Organization

Figure5shows the organization of RtKer-MP.RtKer-MP is a light-weight kernel with support for threads,semaphores and real-time interrupt handling.The hardware-dependent code consists of booting,context-switch,interrupt handling and C library code.RtKer-MP either provides minimal C library(printf/malloc)for a given architecture,or uses a minimal library from some other source(e.g.newlib).For the Leon-MP system,a minimal C library is available and is used.The next few sections describe the salient features of RtKer-MP and issues in design and implementation. 5.3Scheduling in RtKer-MP

As?gure5shows,scheduler is in application space in RtKer-MP.The scheduler code has been modularly sepa-rated from the main kernel through a clean and well doc-umented API.This allows the application developer to ex-ploit the peculiarities of an application to write and plug in his/her custom scheduler conforming with the Scheduler API,thus optimizing on algorithms and data structures used for scheduling.Or else,the developer can choose from a pre-de?ned set of schedulers like?fo,edf,priority,etc.The func-tions in the Scheduler API,along with some other structures, form the scheduler object,which needs to be registered with kernel during initialization.A developer need not know the implementation details of kernel to implement a scheduler, the Scheduler API is all that is required,is provided and is well documented.

RtKer-MP schedules threads using the scheduler object which has functions like create thread(),heir thread()and init().The scheduler is responsible for maintenance of task queues,task counts,and for updating the information on execution times and deadlines.Also,priority assignment and inheritance is also the responsibility of scheduler.In other words,it is the scheduler which really determines the real-time behaviour of kernel.For instance,if it is a hard real-time system,then the scheduler might internally invoke an admission test on the task before including the task into its queues.Or,it might invoke the recovery task,the pointer to which then needs to be passed by the application coder in the task structure.In this manner,RtKer-MP achieves a clean separation between policy and features.

Since it is an RTOS for multiprocessor systems,there are separate scheduler objects for each CPU.A global data structure contains pointers to the individual scheduler ob-jects.Task partitions consisting of multiple CPUs can be created by having their pointers point to the same scheduler object.Also,associated with each partition is a sched lock, which is required for mutual exclusion in access to partition data structures.

5.4Important Issues in developing RtKer-MP While scheduling was an important issue,there were nu-merous other issues and challenges in developing RtKer-MP. This section describes some of the important ones in detail. Initialization:During hardware bootup,the boot pro-cessor(BP),before freeing the Application Processors,ini-tializes some of the lock locations to non-zero values to indi-cate that they are not free.Then,the BP jumps to the code location.Application processors(APs),also having been freed,jump to the code location.The?rst part of the code executed by all the processors makes a call to the initializa-tion function,rtker init.In this function,the BP initial-izes common structures,interrupts,trap handlers,etc.In the meantime,the APs wait on the lock locations described above,the control being implicitly with BP.After BP com-

pletes its exclusive portion,it releases the lock.Then the APs get the lock one by one,do the processor-speci?c ini-tializations through the function thread lib init,which ini-tializes,among other things,the scheduler structures.

After all the initializations have been made,BP returns back to the application code.APs,on the other hand,make a call to suspend thread,and the scheduler for each sched-ules the idle thread for that particular CPU.They idle away, till there is a thread ready to be scheduled on that CPU.The BP,which returns to the application code,then is expected to create all the threads of the application,which can then subsequently be scheduled on some CPU in their designated partition.

Synchronization:As explained in[8],for any kernel to function in a proper way,it has to provide internal lock-ing and protection of its own structures.This would,for example,prevent two processes from modifying the kernel data structures concurrently,something which could lead to inconsistency in those structures.Another situation that could arise in the absence of locking could be allocation of the same memory block to two processes which make simul-taneous requests.Such issues are particularly important in the case of multiprocessor systems sharing data structures, since multiple copies of the OS might be trying to access and/or modify these structures concurrently.

In RtKer-MP,we use the technique of?ne grained locking to reduce the amount of time locks are held and reduce the critical latency times so as to provide real-time behaviour. We have separate locks for unrelated structures.Thus,for instance,separate locks protect scheduling and semaphore structures.Also,separate locks protect the scheduler ob-jects of di?erent partitions.These locks protect the critical sections of the RTOS such as the sections where the next thread to be scheduled is obtained from the scheduler ob-ject,the semaphore queue operations,etc.

Testing and Debugging:The testing and debugging environment was constrained by the absence of a simulator for our multiprocessor platform.The available simulator from Gaisler research is for uniprocessor LEON,and there too,only the binary is available.Development of the simula-tor is a work that is currently in progress in our group.Our environment,therefore,was limited to the uniprocessor sim-ulator,and simulation of the VHDL code for the hardware as described in https://www.wendangku.net/doc/1c17794983.html,ing that simulation approach, one can simulate a code on the architecture.The constraints with this approach are two-fold:(a)the simulation is very slow as compared to any instruction set simulator,and(b) the only information it gives is the instruction sequence exe-cuted on the processor.Due to the speed of simulation,one can only simulate small pieces of code on the VHDL model of the processor.

5.5Customization Opportunities in RtKer-MP This scheduler API design gives a lot of?exibility in terms of scheduling and task migration policies.As described in[7],there are three categories of scheduling algorithms based on the task migration strategy,i.e.Full migration, Restricted migration,and No migration(partitioned).Our scheduler framework allows implementation of all these three categories of algorithms.For instance,for full migration,all pointers to scheduler objects point to the same structure,allowing a global task queue and a global scheduling policy. Similarly,no migration can be implemented by having sep-arate individual pointers to scheduler object per processor. Thus,a task can be scheduled only on the processor to which

it is bound,even if some other processor is idle and this task

is ready to be scheduled.Moreover,the pluggable scheduler interface allows for quick exploration of various scheduling policies for a feedback to the estimation systems.

6.IMPLEMENTATION PLATFORM

In section3we described the high-level design method-ology for developing application-speci?c multiprocessor em-bedded systems.Subsequently we described Leon-MP and RtKer-MP,the important components of SMPS.Now we describe how the synthesis methodology maps on to SMPS and the role of di?erent components.For this,we?rst de-scribe the setup where actual prototyping is done.Next we detail the development cycle for this system.The important issue of performance monitoring and how communication is done are also addressed here.

6.1Prototyping Setup

Our hardware prototyping platform is based on an FPGA board from Alpha Data Parallel Company,ADM-XRC-II [2].The ADM-XRC-II is a high performance recon?gurable PMC(PCI Mezzanine Card)based on the Xilinx Virtex-II range of Platform FPGAs.Its features include high speed PCI interface,external memory,high density I/O,programmable clocks,temperature monitoring,battery backed encryption and?ash boot facilities.It comes with a comprehensive cross platform API,and supports various operating systems. This board contains a Xilinx XC2V3000-FF1152-5device. The card itself is sitting inside the PC box and is connected

to the PCI bus using a PCI to local bus converter.Some pins of the FPGA are available externally for

interfacing.

Figure6:Hardware Layout of Leon-MP

Figure6shows a block diagram of ADM-XRC-II board with external connectivity.It also shows which part of the multiprocessor is mapped where.The external hardware in-terface circuitry contains error and power LEDs along with reset switch and voltage level conversion circuitry.The volt-age conversion circuitry is required as the FPGA operates

on LVTTL logic(0to3.3volts)whereas the RS-232C op-erates on di?erent range(-12to+12volts).Multiproces-

sor UARTs are mapped to host UARTs,which are used for program loading and communication.This board connects

the FPGA directly to the local bus and enables its opera-tion.The ADM-XRCII board has high performance PCI and DMA controllers,local bus,RAM banks,user front panel and rear panel connectors.Downloading of bit ?le is done through the PCI interface by which the board is connected to the host computer.

The interface board takes signals from Leon-MP synthe-sized on ADM-XRCII board.The error pin of Leon-MP is mapped to the Error LED on the interface board and it glows when the error signal is asserted by Leon.Leon’s ex-ternal Parallel I/O pins are connected to the PCs UARTs through an interface circuitry for the necessary voltage con-version from ADM-XRCII’s CMOS/TTL level to the RS-232compliant levels of the PC UARTs.A MAX-232chip does the necessary voltage-conversion for ADM-XRCII in-puts/outputs to RS232PC interface.In this manner,UART signals of the testbed as shown in ?gure 3are mapped to serial ports of the host.These are used to load application code onto the testbed and to do standard input/output with the running

system.

Figure 7:Actual System Prototype

Figure 7shows a photograph of the hardware setup.The ADM-XRC-II board is visible inside the CPU box of the computer.External wires coming out of this board connect to the external hardware interfacing circuitry,shown along side the power supply.Oscilloscope connected to the probe points can be used to observe the serial data.

6.2Application development and Loading

As described in section 3,using various exploration,esti-mation and partitioning tools,the partitioning of tasks be-tween hardware and software,and of software tasks among procesors is decided.Architecture customization to be car-ried out is also identi?ed.For the hardware portions,ASICs can be developed and added onto the system bus in Leon-MP or chosen from a library if it is available.CPU cus-tomization can be carried out in Leon-MP through a GUI con?gurator as described earlier.If the desired option is not supported,such as a custom FU,user-provided modules can be integrated with the system.

Figure 8illustrates the software development ?ow for the prototyping system.The multi-threaded application code,compliant with RtKer-MP API,and written in the C pro-gramming language is compiled with the help of the

LECCS

Figure 8:Software Development Flow

[14]toolkit which is a set of cross-compilation utilities for Leon Processor.The application code is responsible for call-ing the RTOS initialization functions with proper parame-ters,create the appropriate partitions and register corre-sponding scheduler structures with the kernel.LECCS al-lows cross-compilation of C and C++applications for LEON.The compiled code is linked against the RtKer-MP library for implementations of the RTOS API functions.It is fur-ther linked with the Rtems Library to obtain the binary code.Veri?cation is done to establish the functional cor-rectness of this application.This could be done with the help of a functional simulator such as TSIM [14]or a multi-processor simulator.

Having veri?ed the application,the binary is converted to the S-Record format next.This format contains the Stripped Relocatable Symbols,with the help of objcopy bi-nary utility,and is ready to be loaded onto the actual hard-ware.Motorola S-Records are an industry-standard format for transmitting binary ?les to target systems.S-Record follow the standard

S