Siddharth Choudhuri Tony Givargis

1 System Architecture for Software PeripheralsSiddharth ChoudhuriTony GivargisCenter for Embedded Computer SystemsCenter for Embedded Computer SystemsUniversity of CaliforniaUniversity of CaliforniaIrvine, CA 92617, USAI rvine, CA 92617, USAe-mail: Software peripherals [1] have been proposed as adesign alternative to traditional peripherals. We propose a soft-ware architecture, design methodology and scheduling schemefor implementing software peripherals on general purpose pro-cessors, with fast context switch and high resolution timers. Ourdesign flow automatically generates code for scheduling softwareperipherals. We demonstrate the feasibility of our proposed workby experimenting with a set of five software peripherals scheduledto execute on a MIPS processor. Our performance evaluationsshow that the performance impact of the software peripherals onuser-level tasks is minimal ( , on a 100 MHz processor) strongly suggesting that with the right architecture, softwareperipherals can be efficiently accomodated in typical INTRODUCTIONThe complexity of embedded systems is on the rise.

2 This isdriven by several factors such as, the possibility of integratingmulti functional components into a single system , System-on-Chip (SoC) [2], the demand from consumer and other in-dustry segments to have end products that serve more than onepurpose (for example cell phones morphing into personal dig-ital assistants, communication device, gaming device). Thecomplexity of systems coupled with increasing time pressure tolaunch newer products has lead to the design of embedded sys-tems that are highly tuned for specific target applications. Suchembedded systems are based on a tightly coupled processor-peripheral , a processor-peripheral platform is designed for flex-ibility, cost and performance. Flexibility leads to design reuseand shorter time to market when developing new products de-rived out of existing, well known and tested platforms. Flexi-bility also reduces non-recurring engineering (NRE) costs.

3 Asingle platform consisting of processor-peripheral helps in costsavings during manufacturing. Performance is required to runcomplex software applications on these peripherals[1, 3] have been proposed to meet thechallenges of flexibility and cost in processor-peripheral plat-forms, while still meeting performance requirements. Softwareperipherals emulate the implementation of peripherals in soft-ware (processor) with minimal hardware support, if any. Thesoftware implementation produces bit patterns using the pro-cessor I/O pins such that the pattern generated has the samefrequency as the hardware implementation of the leads to greater flexibility, lower cost (reduced hardware)and easier functional upgrades. System design translates intoa processor with minimal hardware support that can be con-figured to have a combination of peripherals, each running onthe processor as a software task. With growing speeds of em-bedded processors, the performance requirements can be metwhile accommodating software peripheral this paper, we present software architecture and schedul-ing for software peripherals.

4 To our knowledge, the proposedapproach is a first step towards implementation of software pe-ripherals on general purpose processor architecture with sup-port for fast context switch and high resolution timer. Further,we propose a design flow to automatically generate a sched-ule layout based on interrupts followed by experimental resultsfrom remainder of this paper is organized as follows: Thenext section discusses related work and our contributions. Thedetails of system architecture is described in section 3. Theresults and analysis of results is provided in section 4 followedby summary and RELATEDWORKThe idea of software peripherals was proposed in [1, 4]. Thefocus in [1, 4] was on proposing the idea of software periph-erals, its usefulness and estimating the processor overhead im-posed by software peripherals. This work used a simplifiedmodel of peripherals to calculate the processor utilization foreach peripheral in isolation.

5 However, to realize a feasible sys-tem based on the idea of software peripherals would requirescheduling multiple peripherals as software tasks and a detailedmodel for each peripheral. In our work, we address the follow-ing issues (i) a methodology and design flow to implement soft-ware peripherals (ii) scheduling scheme that outputs a schedulelayout to be invoked with the help of a high resolution timer(interrupt) (iii) a detailed model of peripheral that implementsthe functionality of peripheral as a software task (iv) systemoverhead from [5, 6, 3] has an implementation of software periph-erals targeted for networking devices. Ubicom processors pro-vide an almost zero context switch overhead resulting in an ex-tremely efficient implementation of software peripherals. Ev-ery fetch-decode cycle is preceeded by a software peripheraltask instruction. In our work, we explore the possiblities ofrealizing software peripherals on conventional processor archi-tectures that do not have a datapath specifically designed forsoftware $ 2007 provides configurable processor based on standardmicrocontroller or microprocessor architectures.

6 Users can adddesired peripherals using a GUI based tool (FastChip configu-ration). Once designed, the peripherals are implemented ascores. Thus, the flexibility is only at the design phase and de-sign reuse is not an has been a growing trend of implementing conven-tional peripherals in software and reconfigurable hardware inorder to attain greater flexibility in design and reuse. Some ofthe examples are software modem, software defined radio andseveral other reconfigurable architectures [7, 8, 9, 10]. How-ever, implementing peripherals in reconfigurable hardware isorthogonal to our work, though the goal is to have flexibilityand reusability in design. Our goal is to have minimal hard-ware, if any, and push the peripheral functionality to software(processor).III. TECHNICALAPPROACHThe implementation of peripherals in software is transpar-ent to the user applications. Writing data to a peripheral atthe application level translates into a write request made by thedevice driver to the software peripheral implementation.

7 Thesoftware peripheral implementation translates the data it getsfrom device driver into a sequence of bit patterns. This bitpattern is sent to the physical I/O of the processor at a certainrate, resulting in a sequence of1s and0s at the output pinsof the processor that excatly mimics the peripheral function-ality infrequencyandsequence. Similarly, the software pe-ripheral is also responsible for reading I/O pins at a specific,pre-determined frequency and notifying the higher level tasksof any input events. Software peripherals run in the context ofan OS. This is due to the fact that the implementation requireslow level, privileged access to pin I/O routines and interrupthandlers, details of which are provided in the next System ArchitectureFigure 1 shows our proposed architecture for software im-plementation of peripherals. In general, a peripheral s opera-tion can be divided into: (i)Computation taskthat implementsthe functionality and (ii)Communication taskthat deals withbit I/O at the hardware our proposed architecture, theHigh Level Peripheral(HLP) Taskis responsible for the computation part of a givenperipheral.

8 It contains the implementation of the peripheral(which in a conventional architecture would have been in adedicated hardware). In case of a write request, the output ofthe HLP task is a sequence of bit pattern written to peripheralmemory buffer. During a read request to a peripheral, the HLPtask reads a sequence of bit pattern from the peripheral mem-ory buffer, processes the bit pattern and returns the result tothe device driver. Note that, the driver gets the same data thatwould have been returned by a hardware Memory Bufferis a shared memory regionbetween the HLP task and the Low Level Peripheral (LLP)task. It is a pool of buffers wherein each instance of a peripheralhas a read buffer and a write buffer, depending on the periph-eral functionality1. The content of buffers are bit patterns withstart and end pointers maintained by the HLP and LLP Peripheral ArchitectureLow Level Peripheral (LLP) Task :The LLP task is respon-sible for pin wiggling and reading the pin inputs ( , bit input-output).

9 In case of a peripheral write operations, the LLP taskreads the bit pattern from peripheral memory buffer and outputsit to the processor I/O pins. Similarly, during a read operation,the LLP reads the status of processor I/O pins and appends itto the appropriate buffer. The LLP task has stringent require-ments in terms of its periodicity. Not invoking LLP task at righttime(s) can lead to incorrect outputs and incorrect interpreta-tion of data read by the peripheral. This requirement makes theLLP task a hard realtime task. Since the peripheral character-istics are known apriori, LLP task is statically scheduled. Dueto the nature of the LLP task, it has to run on a high priorityinterrupt timer. The LLP task is invoked atleast as frequentlyas the fastest rationale behind dividing the peripheral functionalityinto HLP and LLP task is that a peripheral task needs to beinvoked atleast as frequently as the highest frequency periph-eral.

10 However, most of such invocations would be to read/writebit patterns (communication) and a few that implement the pe-ripheral functionality (computation). Given the high rate of in-vocation, a small interrupt service routine would suffice to dothe pin I/O. On the other hand, a software task with peripheralimplementation will need to be invoked less often but such atask would be computation intensive. Note that the HLP andLLP tasks have a producer-consumer relationship dependingon a write or read operation being order to implement the LLP task, certain architecture sup-port is required. An extremely high resolution timer interrupt isrequired to invoke the LLP task at high frequencies. Also, thecontext-switch overhead needs to be minimal or close to almost zero context switch is possible by using processorarchitectures that support register banking. One set of regis-ter bank can be dedicated to execute LLP task.