On Hardware and Hardware Models for Embedded Real-Time Systems Jakob Engblom∗ Dept. of Information Technology, Uppsala University P.O. Box 325, SE-751 05 Uppsala, Sweden [email protected] / http://www.docs.uu.se/~jakob effects if deadlines are missed or some other timing- Abstract related bugs manifest themselves. When developing embedded real-time systems, de- When building an embedded real-time systems, the signers and programmers rely on various forms of choice of hardware platform is very important to create scheduling and timing analysis. At some point, all an analyzable and predictable system. Also, the quality such analyses must account for the hardware used to of the models of the hardware used in software tools obtain execution time information, and if the analysis is very important to the correctness of timing analysis method does not accurately reflect the hardware char- and the integrity of the system. acteristics, the result is likely to be a bad analysis and In this paper, we discuss some of the aspects of how potentially a bad system. to build hardware models that are correct visavi the The choice of hardware, specifically the microproces- hardware, and how to select hardware that allows real- sor or microcontroller to use, has a profound influence time systems to be constructed in a reliable fashion. on the analyzability of a system. The timing behav- The purpose of this paper is to inspire some discus- ior of a complex CPU core is very hard to understand sion regarding how real-time systems are designed and (even without a cached memory system). Thus, sys- built and verified, from software, hardware, and tools tems have to be designed to facilitate analysis, from standpoints. the hardware and up. Keywords: Embedded Systems, Real-Time Systems, 2. On the Quality of Hardware Models Computer Architecture, Hardware Selection, Hardware Analysis, Hardware Modelling In embedded systems development, hardware mod- els (software running on the cross-development system) 1. Introduction are used for most of the development work and analysis Thanks to the ever-advancing performance of em- of a system. The quality of such models form a key part bedded computer technology, an increasing number of of the correctness argument for a system. The use of systems are being built and designed where micropro- a bad hardware model (even for eminently predictable cessors and microcontrollers perform substantial con- and analyzable hardware) will put the system integrity trolling tasks. Vehicles, appliances, industrial plants, at risk. toys, mobile phones: embedded systems are every- Looking at the design flow for hardware models, sev- where around us. Most of these embedded systems eral sources of errors can be identified. Figure 1 shows a have real-time constraints, and potentially dangerous schematic flow of the design and implementation work separating a CPU simulator (the most important type ∗ This work is performed within the Advanced Software of hardware model) from the physical chips shipped by Technology (ASTEC, http://www.docs.uu.se/astec)compe- tence center, supported by the Swedish National Innovation the manufacturer. Systems’ Administration (VINNOVA, http://www.vinnova.se). The manual writing is probably the biggest source of Jakob is an industrial PhD student at IAR Systems errors. The manual writers have to interpret the chip (http://www.iar.com) and Uppsala university, sharing his time design, and this interpretation can be different from between research and development work. Presented at the IEEE Real-Time Embedded System Work- that of the hardware implementers. Simple typos can shop, Dec. 3, 2001. introduce more errors. sible to shortcut the process by using the VHDL code Chip design in some manner. Unfortunately, VHDL simulators are orders of magnitude slower than a regular cycle-correct Hardware Manual simulators, and automatic abstraction from VHDL to implementation Writing a cycle-level simulator is not feasible. VHDL Model Users Simulator 2.1. Experience Report 1 manual Design Compilation & Black and Shen [4] report their experience in validat- Fabrication Simulator ing a model of a PowerPC 604 processor. The method Implementation employed was to execute many test cases (small pro- grams) on both their simulator and a real CPU. The Chip Correspondence? Simulator performance counters of the PowerPC were used to check the correctness of the model. For such a com- Figure 1. Workflow of Hardware Modeling plex chip, this is a reasonable approach. As a sanity Often, many of the details needed to implement a check, they also executed a number of larger programs simulator (or an optimizing compiler) are abstracted and compared the cycle counts on the simulator and away or glossed over. Many manuals do not describe the hardware. the detailed function of a CPU pipeline, but instead The results are interesting, since they never man- give simple approximate cycle counts for instructions age to get a perfect correspondence. Fixing an error (which is a grave oversimplification for a pipelined pro- in the model sometimes revealed other errors that had cessor) [1, 3, 10]. Thus, the manuals typically have a been masked by the first, and the total error could thus rather tenuous relation to the chips they are supposed increase for some fixes. However, over time, the accu- to document, which is a major problem for hardware racy of the model increased, both for the performance modeling. counter agreements and the cycle counts for the tested Even though hardware engineering is in much bet- larger programs. For their final model, about 20 per- ter shape than software engineering, bugs can be in- cent of the individual small tests failed to be within one troduced in the hardware implementation. A famous clock cycle of the hardware timing, while the large test example is the Pentium FDIV bug [20]. The presence programs showed an error between 2 and 10 percent. of extensive errata lists for hardware further indicate The errors were both positive and negative, indicat- that hardware does contain bugs which are not found ing overestimates and underestimates of the execution until after products are shipping. It should be noted time. that bugs regarding the timing behavior of chips are Their conclusion is that systematic validation quite common while functional bugs are comparatively against hardware is necessary to build a performance rare, since instruction timing is usually not validated model that users can have confidence in using, and that as extensively as functional correctness [12, 17]. achieving a reliable and precise model requires a large The hardware compilation and fabrication do not development effort. The complexity of current high- usually generate user-visible bugs. end microprocessors makes the development of reliable The simulator implementation also has some bug hardware models a “great challenge”. sources. In the simulator design step, it is possible to introduce errors by misinterpreting the manuals and 2.2. Experience Report 2 ignoring important features in the model. During sim- Gibson et al. investigated the quality of the models ulator implementation, errors are introduced as the de- used in the research and development of the Stanford signed simulation model is converted into actual pro- FLASH multiprocessor [8]. The FLASH project em- gram code. ployed several different simulators during the develop- In summary, the “timing correct” hardware models ment of the system, and collected a large amount of we use in real-time development and research are sev- data on how well the simulators and the hardware cor- eral bug-inducing steps away from the actual hardware, related. Their testing was initially based on running which makes the use of such models quite questionable. large multi-processor numerical applications and com- It is necessary to find a way to validate the hardware paring the resulting execution times. Smaller bench- models used when building real-time systems. To in- marks were introduced to help pinpoint specific per- vestigate this, we look at some work performed in val- formance mismatches later in the process. idating CPU simulators. The CPU models used were all based on generic sim- Looking at Figure 1, it seems that it would be pos- ulation packages like Mipsy and MXS, which were given parameters to closely emulate the MIPS R10000 CPUs Manual Writing used. However, these models were not able to capture The multiply instruction sometimes writes two registers, which causes a delay of one cycle (probably the register bank all relevant details of the CPU, giving execution time has only one write port). This was not documented. results very different from the hardware for key parts Some forms of jump instructions were documented as being of their code like TLB miss handlers. This is claimed one cycle faster than they actually were. to be a general problem with generic CPU simulators: Simulator Design The V850E has a main pipeline and a secondary pipeline. It they are not sufficiently configurable to model all the was possible for instructions to continue issuing to the sec- quirky cases of the real hardware. ondary pipeline even if the main pipeline was busy, which is The conclusions for simulator construction is that not possible in the hardware. simulation technology is barely able to keep up with the One instruction had been forgotten in the simulator imple- mentation. increased complexity of modern computer systems, and Simulator Implementation that hardware to compare with is necessary in order to Signed and unsigned division has a one clock-cycle difference build a good model. in execution time, which was implemented the wrong way around. 2.3. Experience Report 3 Some bit-manipulation instructions did not keep certain re- sources locked for their entire execution, letting other in- Mont´an [16], working within our project, validated structions slip by, eventually leading to internally inconsistent a trace-driven simulator for the NEC V850E [19], used states and thus a crash of the simulator.