Andres Takach
email: andres_takach@mentor.com

Bryan Bowyer
email: bryan_bowyer@mentor.com

Thomas Bollaert
email: thomas_bollaert@mentor.com

C Based Hardware Design for Wireless Applications

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

The growth in wireless communication has been fueled by the application of modern DSP algorithms that enable the adaptation to varying communication channel characteristics and efficient usage of channel bandwidth. Wireless communication are present in consumer applications such as cell phones and local area networks and span a wide range of data rate and channel requirements.

The computational nature of DSP algorithms used in wireless applications are well suited to such a design methodology. Figure 1 shows how the proposed methodology fits into existing flows. The main difference compared to a traditional design flow is the replacement of the manual transformation of the C into RTL with an automated synthesis flow, where the designer guides synthesis to generate the micro architecture to meet the desired performance/area goals. The C synthesis product used in this paper is Catapult C. Synthesis generates the RTL with detailed knowledge of the delay of each component to eliminate the guess work that is otherwise unavoidable when the micro architecture and RTL are generated manually. The advantages of an automated Cbased synthesis flow are reflected both in significantly reduced design times as well as higher quality of designs, because a variety of micro architecture can be rapidly explored.

Figure 1: C-Based Design Flow

The typical design flow for implementing DSP algorithms starts with writing the algorithm at a functional level using languages such as MATLAB, C or a combination of the two languages (C here is used to refer to both C and C++). Due to its faster execution speed, C is typically preferred over MATLAB for modules being implemented in hardware. These modules are often the most computationally intensive, making them the most demanding to simulate.

In many cases, algorithms are initially written using floating point arithmetic and are then numerically refined to use finite-precision arithmetic. The refined algorithms are bit-accurate specifications.

In general, the effort of moving from a bit-accurate algorithmic functional description to a synthesizable algorithmic C implementation model is relatively low. No complexities of timing or concurrency or target technology are encoded in these models. To verify the refined C models are simulated against the original MATLAB/C models.

For each C algorithmic model the designer explores different architectures by directing how data will move in an out of the block (interface synthesis), mapping arrays to memories, and deciding how much parallelism is required to meet the throughput/latency goals. In traditional flows, defining the architecture and generating the RTL from the C model is done manually, a process that may required several months to complete. In a C based synthesis flow, the architecture definition and the generation of RTL is often accomplished in a matter of days to weeks. Simulation is used for individual blocks or to debug designs, but in general is too slow to perform functional verification of the system. The generated RTL can be used to obtain an FPGA prototype of the RTL that is then used for functional verification.

If the FPGA prototype of the RTL is not sufficiently fast enough to allow "at-speed" emulation of the ASIC block, a new FPGA design can be rapidly generated that does match the speed of the ASIC design. Using such a strategy, the designer can perform functional field testing to validate the algorithm(s) used or validate the RTL for other blocks of the design or other components of the system.

The paper is organized as follows. Section 2 presents an overview of algorithmic C synthesis and the transformations that are essential in that process. Section 3 provides an introduction to important issues that need to be taken into account when coding the C algorithm for synthesis. Section 4 outlines the example DSP algorithm and provides much of the C behavior for the design including a templatized class for complex numbers based on fixed-point arithmetic. Section takes the algorithm through architectural exploration to generate RTL with certain performance goals and presents the result for a number of architectures. The paper closes with conclusions that can be drawn from our work.

Algorithmic C synthesis

The synthesis flow starts with a purely algorithmic C specification. The absence of explicit timing or concurrency makes algorithmic specifications far more compact and implementation independent than traditional RTL or "behavioral" specifications written in languages such as VHDL, Verilog or SystemC.

The hardware architecture is obtained by applying architectural directives during synthesis. Architectural directives provide a mechanism to specify high level decisions on how the design communicates with the outside world, how data is stored and how parallelism is exploited to obtain the desired performance. For example, in the algorithmic C, the input data is passed when the function is called, and the "outputs" of the function are available to the caller when the function returns. During synthesis, the designer specifies through interface synthesis directives how the data is transferred from and to the design.

The main architectural transformations that are used to generate a hardware architecture from an algorithmic C specification include: • interface synthesis • variable/array mapping • loop pipelining • loop unrolling • scheduling.

The transformations are described in more detail in the following sections.

Interface synthesis

Interface synthesis converts the way the C function communicates with the outside world. There are a number of architectural transformations that take place that allow writing the C specification in such a way that does not require embedding features of the desired architecture in the source. The transformations include: • An optional start/done handshake protocol is added to the design • The individual C function arguments are mapped to a variety of resources such as memories, buses, FIFOs, handshaked registers etc. • The data transfer bitwidth for any of the arguments is specified • Arrays accesses over an index may be converted into accesses over time. For example, an array "uint10

x[1024]" may generate a port of width 10 bits that is read over time throughout the execution of the algorithm to access the different x[i]. The environment then streams in the data in the required order, most commonly in increasing or decreasing index order.

Variable/array mapping

Interface or local variables or arrays may be mapped to memories or may be split into registers. Smaller arrays are typically mapped to registers while larger arrays are typically mapped to memories. The required read and write bandwidth of the memory depends on the algorithm and the performance requirements on the design.

Loop pipelining

Loop pipelining provides a way to increase the throughput of a loop (or decreasing its overall latency) by initiating the (i+1) th iteration of the loop before the i th iteration has completed. Overlapping the execution of subsequent iterations of a loop exploits parallelism across loop iterations. The number of cycles between iterations of the loop is called the initiation interval.

In many cases loop pipelining may improve the resource utilization, thus increasing the performance/area metric of the design.

Loop unrolling

Partial or full unrolling of a loop exposes parallelism that exist across subsequent iterations of the loop. In some cases, partial unrolling may also be used in a coordinated way with memory mapping and interface synthesis to increase the effective bandwidth for data transfer. For example, unrolling may expose the possibility of accessing of even and odd elements of an array as one word when it is mapped to memory.

Scheduling

Scheduling is the focal point of architectural exploration. It transforms the sequential specification into a architecture with a well defined cycle-by-cycle behavior. It takes into account required synthesis directives such as the clock period and the target technologies. In addition, it takes into account cycle and resource constraints that are either explicitly provided by the user or implied by interface synthesis directives, variable/array mapping directives and loop pipelining/unrolling directives. Scheduling selects among combinational, sequential and pipelined components that implement the operations in the algorithm.

Coding C for synthesis

In general, it is best to start from simpler and more compact code. It is also important to understand the hardware implications of different C/C++ constructs. For instance, memory allocation/deallocation (malloc, free, new, delete) is not supported. In this Section we highlight some general guidelines for coding C for synthesis.

The function for the design is designated as the toplevel design using a pragma. Arguments of the function are used by interface synthesis to generate the appropriate ports. Arguments such as "int *x", or "int x[10]" or "int &x" are treated as in, out, or inout depending on whether the object pointed at is only read, only written or, both read and written. Non pointer arguments such as "int x" are treated as input ports and read at the start of the execution of the algorithm.

Bit-accurate datatypes

Coding bitwidths

Specifying the actual bitwidth is mostly required for interface variables. It is often possible to take an algorithm written with C built-in integral types and only constrain the bitwidths of some variables at selected places: • at the interface: if a 17 bit signed integer is required, we need to use int17 (part of mc_int) or sc_int<17> or sc_bigint<17> (SystemC datatypes). • force a certain precision where synthesis is not able to reduce the bitwidth thorough its dataflow analysis. For example: the casting to int17 in the expression "a = (int17) (a + b*c)" would allow the reduction of variable "a" from a 32 bit integer (assume "a" was declared int) to a 17 bit integer. Automatic bit reduction minimizes the changes required to generate optimized RTL from an existing C algorithm. It also makes writing of parameterized designs easier and less error prone. A typical example is a loop with a constant bound that depends on template parameters or constants that come from a "#define" statement in the source. The example C code is shown in Figure 2 where the minimum bitwidth required for loop variable i depends on the template parameter N. It is important to roughly know what bitwidths are expected as synthesis may not always be able to perform the level of analysis of an experienced designer. Such situations are normally found by examining the bill-ofmaterials report, the critical-path report, or by careful examination of the schedule (Gantt chart) as operations with long delays stand out. Cross probing from the reports or the Gantt chart to the source provides a quick mechanism to find out which expression or variable was not reduced in bitwidth.

Integer are often used to implement fixed-point arithmetic by using explicit calls to functions that perform rounding and saturation. Using integer to model fixedpoint requires careful attention to the position of the implicit fixed-point.

SystemC provides signed and unsigned fixed-point datatypes that provide all the arithmetic operators and rounding/saturation functionality. For example, and sc_fixed<8,3,SC_RND,SC_SAT> is a fixed point number of the form bbb.bbbbb (8 bits of width, 3 bits integer) and with quantization mode set to SC_RND and overflow mode set to SC_SAT. The default modes (as when the sc_fixed is declared as sc_fixed<8,3>) is SC_TRN (simple truncation) and SC_WRAP (no saturation).

Case study: 64-QAM decoder

Multilevel quadrature amplitude modulation (M-QAM) [START_REF] Ifeachor | Digital Signal Processing -A Practical Approach[END_REF][2] is used in many digital communication applications such as modems to efficiently and reliably use the communication channel. The digital signal is coded in levels, both in-phase and quadrature components leading to a two-dimensional constellation. The number of constellation points represent the number of values that may be coded in a symbol. For our design, we have an 8x8 constellation resulting in 64 codes or six bits of information per symbol.

In most communication applications the channel properties are not known in advance and in fact vary with time. Adaptive filtering is used to equalize the channel properties and to correct for inter symbol interference (ISI). The typical arrangement is shown in Figure 3. The feed-forward equalizer (FFE) performs channel equalization, while the decision feedback equalizer (DFE) corrects for the ISI from the N previously received symbols. The error signal is used to update the coefficients of the adaptive filters. We used the sign-LMS (least mean squared) adaptive algorithm for our example.

The input signal is complex, representing the in-phase and quadrature components of the received signal. All filters operate with complex data and have complex coefficients.

Figure 3: Block diagram for Equalized QAM decoder

For simplicity, we have not implemented details of how the training sequence is generated or blind adaptation is performed. Also we have not considered timing recovery within our design.

The FFE is T/2 spaced (taking two new inputs every symbol period) and has eight taps. The DFE is T spaced and has 16 taps. The filter coefficients are complex and have 10 bits of precision.

Coding of the algorithm

The algorithm is written based on the block diagram shown in Figure 3. The first version of such an algorithm is typically written using floating point arithmetic. Once the algorithm is validated, the algorithm can be refined to use fixed-point datatypes. The coding of the algorithm using fixed-point datatypes is shown in Figure 4. The algorithm is written so that the various bitwidths can easily be set by changing the definition of a few constants. Written the algorithm in a parametrized manner simplifies precision exploration and facilitates future reuse of the algorithm.

The process of minimizing the precision of the arithmetic requires knowledge of communication theory and DSP hardware design [START_REF] Roberts | Finite Length Register Effects in Fixed Point Digital Filters[END_REF] as well as empirical (simulation based) analysis and validation. For the QAMdecoder, quantization of each computation is a source of noise that contributes to the overall mean-squared error at the input of the QAM slicer. The maximum mean-squared error that can be tolerated depends on the required bit-

+ + - + + - e(n) y(n) x(n) e(n) e(n)
error rate. In addition to quantization noise, errors due to overflow need to be taken into account. The focus here, however, is in the hardware generation from a numerically refined algorithm.

The algorithm was written using a datatype that encapsulates complex arithmetic. The use of such a datatype helps to make the algorithm specification more compact and easier to understand but otherwise does not affect the synthesis process presented here.

The complex datatype is named sc_complex as it uses the sc_fixed datatype to represent the real and imaginary components. The sc_complex class was written by the authors (not part of the SystemC datatypes) and is not shown here due to space constraints. It is templatized much the same way as the sc_fixed datatype is.

Every call to the function qam_decoder takes two new inputs and computes a new 6-bit output. The arrays that store the tap values and the coefficients are declared static so that the values are preserved between calls to the function.

The various loop were given labels (part of C/C++) to facilitate the discussion on what loops will be transformed when doing architectural exploration. The design has a total of six loops (two for filter computation, two for adaptation, two for shifting the tap values). The "#define"s for the constants FFE_W, DFE_W, FFE_C_W, DFE_C_W are not shown but are all set to 10.

The loop nfe (dfe is similar) is a simple loop that implements an FIR filter. The coefficients of the nfe filter are updated in the loop ffe_adapt using the current error "e" and the last nffe "x" samples (inputs to the nfe filter). The ffe_shift loop shifts the "x" samples two places to make room for the two new input samples that are provided in the next invocation of qam_decoder.

Results

The target design is a 5 MBaud (30 Mbps) design using a 100MHz clock using an specific ASIC technology. In addition, we want to explore other designs to show how C synthesis may be used to rapidly generate various architectures.

The QAM_decoder function generates one output (symbol) for every invocation of the function. In order to meet the throughput requirements, the algorithm should take 20 or fewer cycles to compute a new output. An inspection of the algorithm reveals that a sequential execution of the six loops alone would take 8+16+8+16+3+15 = 66 cycles, roughly three times slower than our goal.

In order to get a quick overview of the design, we run synthesis with the default architectural constraints (loop merging enabled, no loop unrolling/pipelining). The result is a design with a latency of 35 cycles. It turns out that Each loop takes 16 cycles to complete resulting in a latency of 3+16+16 cycles (three cycles for behavior between loops). With loop merging disabled, the design would take a latency of 3+8+16+8+16+3+15 = 69 cycles.

; k-=2) { x[k+3] = x[k+1]; x[k+2] = x[k]; } dfe_shift: for(int k=ndfe-2; k >= 0; k--) SV[k+1] = SV[k]; }
The latency of the design is improved by exposing additional parallelism. We found that loops of 8 and 16 iterations that were merged could be reduced in latency by partially unrolling the loops with 16 iterations (dfe, dfe_adapt, dfe_shift) to take eight iterations each (UNROLL=2). The resulting latency is 3+8+8 = 19 cycles, meets the performance design goals.

It is easy to exploit additional parallelism to further improve the latency of the design. For instance, setting unroll=2 for dfe and unroll=4 for dfe_adapt and dfe_shift reduces the latency to 3+8+4 = 15 (6.67 MBaud or 40 Mbps). Table 1 summarizes exploration results for our design. The area number is normalized with respect to the second design. The first six columns show the loops in the algorithm and the architectural options that were selected where "M" denotes that loop merging is enabled and "U" denotes the loop unrolling number.

The architectural exploration above was performed in a matter of minutes without changing the source description. We have also successfully targeted FPGA technologies. It is often possible to prototype the design at-speed with an FPGA. Such a prototype can be used to validate the algorithm itself (including the quantization decisions) as well as facilitate the hardware emulation of the whole system.

An architectural choice not shown in the above exploration is loop pipelining. Although it is possible to perform loop pipelining with this approach, for this algorithm and the given performance goals, loop pipelining does not provide as much benefit as loop unrolling. The main reason is that the loop body is simple enough that each iteration of the loop can be executed in a single cycle. Loop unrolling and loop pipelining can often be used in conjunction to effectively exploit parallelism in an algorithm.

Conclusions

A C-based design methodology was presented and used to generate RTL for a DSP algorithm commonly used in wireless designs. We showed the feasibility of the design methodology and provided a general overview of architectural C synthesis capabilities, C coding for synthesis and architectural exploration based on the Catapult C synthesis tool. A single C source was used to rapidly generate a set of ASIC designs with a wide range of data rate numbers. In addition, the C-based design methodology enables FPGA prototyping flows to facilitate verification of the generated RTL as well as real-time functional verification of the algorithm.

Figure 2 :

 2 Figure 2: Example where minimum bitwidth of i depends on template constant

Figure 4 :

 4 Figure 4: C++ code for QAM decoder algorithm

  Hardware designers are accustomed to bit-accurate datatypes in hardware design languages such as VHDL and Verilog. The C language defines a number of integral types and floating-point types. While floating-point types are useful for simulating DSP algorithms, they are impractical for most hardware implementations. Catapult C supports the native C integer types as well as bitaccurate integer and fixed-point types. Native C integer types provide signed and unsigned datatypes of bitwidths 1 (bool), 8 (char), 16 (short), 32 (int), 64 (long long). Bit masking, shifting or C bitfields may be used to model and synthesize bitwidths from 1 to 64 with the native C integer types.

	Catapult C supports several C++ templatized classes
	that encapsulate bit-accurate behavior for integer and
	fixed-point types:
	• Limited precision integer types: SystemC's sc_int/
	sc_uint [4] and Catapult C's mc_bitvector. They are
	limited to 64-bits and are relatively fast to simulate.
	• Arbitrary-length integer types: it supports arbitrary
	bitwidths making the semantics far cleaner as operations
	return full (integer) precision:
	• SystemC's sc_bigint/sc_biguint: much slower
	simulation than limited-precision integer types.
	• Catapult C's mc_int [3]: 3x to 100x faster simulation
	than SystemC integer types. It also has cleaner synthesis
	semantics than SystemC's integer types.
	• Arbitrary-length fixed-point type: sc_fixed/sc_ufixed.
	They model fixed point datatypes with a variety of
	quantization and overflow modes. Slower than
	sc_bigint/sc_biguint.

Table 1 :

 1 Comparison of architectures generated from C synthesis

	ffe	dfe	Architectural Loop Constraints ffe_adapt dfe_adapt	ffe_shift	dfe_shift	Latency (ns)	Data Rate (Mbps)	Area
	M	M	M	M	M	M	350	17.1	1.17
	none	none	none	none	none	none	690	8.6	1.00
	M	M, U=2	M	M, U=2	M	M, U=2	190	31.5	1.61
	M	M, U=2	M, U=2	M, U=4	M	M, U=4	150	40	1.88

Proceedings of the Design, Automation and Test in Europe Conference and Exhibition (DATE'05) 1530-1591/05 $ 20.00 IEEE

Acknowledgements

Authors would like to acknowledge and thank the work of the Catapult-C high-level synthesis team at Mentor Graphics without which this paper would not have been possible.


Hannu Heusala

Jussi Liedes

Modeling of a Reconfigurable OFDM IP Block Family For an RF System Simulator

The idea of design domain specific Mother Model of IP block family as a base of modeling of system integration is presented here. A common reconfigurable Mother Model for ten different standardized digital OFDM transmitters has been developed. By means of a set of parameters, the mother model can be reconfigured to any of the ten selected standards. So far the applicability of the proposed reconfiguration and analog-digital co-modeling methods have been proved by modeling the function of the digital parts of three, 802.11a, ADSL and DRM, transmitters in an RF system simulator. The model is intended to be used as signal source template in RF system simulations. The concept is not restricted to signal sources, it can be applied to any IP block development.

The idea of the Mother Model will be applied in other design domains to prove that in certain application areas, OFDM transceivers in this case, the design process can progress simultaneously in different design domainsmixed signal, system and RTL-architectural -without the need of high-level synthesis. Only the Mother Models of three design domains are needed to be formally proved to function as specified.

Introduction

The ever-growing complexity of digital communication systems has brought new difficulties for analog RF design, too. As the performance of System-on-Chip is highly dependent on digital baseband processing as well, the digital parts have to be included in RF system simulations to ensure the functionality of the system as a whole. The modeling of these complex digital parts in an RF system simulator has become burdensome.

The digital parts that need to be co-modeled in the RF system simulator are the parts that interface with the analog RF environment and parts that have any significant effect on the performance of the system. In the case of a typical digital transceiver, functionality of the whole physical layer of the transmitter and the receiver need to be modeled. Models of the digital parts can be found from current IP block markets, but the abstraction level of such IP blocks is not high enough for co-modeling purposes.

The IP blocks on the market are typically described at RTlevel which causes an impractical increase to the simulation times. In RF system simulations only the behavioral functionality of the block is needed, not the exact structural architecture.

As a solution to these issues we propose a behavioral level reconfigurable OFDM IP block family described in a high-level language. Such modeling makes the digitalanalog co-modeling possible and reasonable as explained in this paper. Here, the term Standard Family means the group of following ten standard specifications: 802.11a, 802.11g, ADSL, DRM, VDSL DAB, DVB, 802.16a, HomePlug 1.0, ADSL++.

Principle of the analog-digital co-modeling

The proposed design flow has four abstraction levels which are called here the System Level, Architecture Level, Logic Level and the Circuit Level. These A common description language and a simulation environment specify a design domain in this paper. For example, in the System Domain, a system level description language e.g. SystemC is used to describe the structure and the function of the system. A system simulator could be used to verify the behavior of the system blocks and the communication channels between them.

The digital-analog co-modeling takes place in the Mixed-Signal Domain where the functions of the system level blocks can be modeled. The performance-critical digital blocks from the System Domain are transferred to the Mixed-Signal Domain. The transferred blocks need to be translated into a high-level language suitable for the RF simulator. This is not supposed to be a difficult task since the source and destination languages are both highlevel languages. The translation can however be burdensome because it has to be done manually and current systems tend to be complicated. This is why the idea of reconfigurable IP blocks is meaningful. The idea of having reconfigurable IP blocks, Mother Models, for certain standard families would save design time. TX and RX logic blocks in the System Domain and in the Mixed-Signal Domain could be instances of the same Mother Models, reconfigured into a certain standard to be designed for the SoC. With one flexible Mother Model, the Co-Modeling of several communication standards could be encompassed. The burdensome translation of the Mother Model has to be done only once.

The behavioral level models of the digital parts in the Mixed-Signal Domain form an executable specification for the RF designer. With these executable baseband blocks the RF designer can assure the functionality of the design at RF system level. With this approach it is possible to start the design flow of the analog RF parts as soon as the necessary high-level system blocks are embedded into the RF system simulator. The most important benefit is that the operation of the digital transceiver can be verified with proper modeling of the RF parts and the transmission channel in one simulator.

RF design flow continues traditionally from the RF system simulation. The digital design flow initiates from the behavioral level models at system level, but parameters or definitions can be derived or affirmed also from the RF system simulations at the Mixed-Signal Domain.

The modeling of signal sources in an RF simulator from the developed Mother Model

As an example, we have developed a high-level model of a reconfigurable OFDM transmitter that can be embedded into APLAC® System Simulator [START_REF] Liedes | OFDM Signal Generation in the APLAC® System Simulator[END_REF]2]. The model is an executable bundle of code that performs the digital baseband processing of the OFDM modulation in an OFDM transmitter and it can be considered as an instance of the Mother Model in the Mixed-Signal Domain. The model was written in APLAC® Language, and it works as a digital signal source for the RF designer. The model was wrapped into an APLAC® Submodel, and in the RF system simulation it appears as a signal source block that can be used in traditional RF system simulations.

To prove the model, it was reconfigured to fulfill the OFDM modulation of three different standardized OFDM transmitters: IEEE 802.11a WLAN, multi-carrier ADSL modem and Digital Radio Mondiale (DRM). The reconfiguration of the model was achieved through a set of parameters, i.e. the changeover from a standard to another is achieved simply by changing the parameters of one Mother Model. Since the digital block was modeled at behavioral level, it was fast to simulate i.e. it had only negligible influence to the total simulation time of the whole transmitter [START_REF] Liedes | OFDM Signal Generation in the APLAC® System Simulator[END_REF].

The OFDM standard family was selected for this example of reconfigurable co-modeling because there is a suitable amount of digital signal processing in OFDM modulation and there are other interests on this multicarrier technique, too [START_REF] Mannion | Merged GSM/Wi-Fi scheme proposed[END_REF][START_REF] Batra | Multiband OFDM: Why it Wins for UWB[END_REF]. In addition, the OFDM standards have such common features that demarcate clear boundaries of the standard family suitable for the concept of the reconfigurable IP block.

To extend the design domain specific models of the OFDM standard family, Mother Models in SystemC and in VHDL have been programmed and are in testing phase at the moment. The parameterized formal descriptions of the Mother Models are under development

Conclusion

The concept of co-modeling digital reconfigurable IP blocks in an RF system simulator was presented in this paper. An example of such reconfigurable Mother Model was developed and tested in APLAC® System Simulator environment [START_REF] Liedes | OFDM Signal Generation in the APLAC® System Simulator[END_REF]. The reconfigurability concept saves design time in the case of multiple designs of closely related systems. Although the design time of the reconfigurable Mother Model is longer than the design time of individual standard specific model, the individual standards can be derived more quickly from the Mother Model than if designed separately from the start. In the case of two or more different standards this approach is time saving. The reconfigurable Mother Model should be considered as a template for certain selected systems.

The concept of reconfigurability is most applicable for systems related closely to each other. This means that the systems covered by the Mother Model need to have enough features in common. OFDM modulation was proven as such.

  abstraction levels are covered by design domains as follows. The System Level is covered by the System Domain, Mixed-Signal Domain and the Co-Design Domain. The Architectural level is covered by the Mixed-Signal Domain and the HDL Domain. The Logic Level and the Circuit Level are covered by the Gate/Transistor Domain and the Implementation Domain.

Proceedings of the Design, Automation and Test in Europe Conference and Exhibition (DATE'05) 1530-1591/05 $ 20.00 IEEE


Young-Taek Kim

Taehun Kim

Youngduk Kim

Chulho Shin

Eui-Young Chung

Kyu-Myung Choi

Jeong-Taek Kong

Soo-Kwan Eo

Fast and Accurate Transaction Level Modeling of an Extended AMBA2.0 Bus Architecture

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Platform based design has become a common methodology as the complexity of SoC design increases. The major advantage of this method is to maximally exploit the reusability of IP components, hence reduce the time-to-market pressure.

But, the one of main challenges in the platform based design is how to exploit the optional architecture, which requires highly abstracted simulation models to maximize simulation with reasonable accuracy.

Transaction level modeling (TLM) has been increasingly favored to address this issue. [START_REF] Cai | Transaction level modeling : an overview[END_REF] This method requires more effort than in pure functional modeling, but generates more realistic traffics to communication architecture.

Communication architecture models also need to satisfy the same requirements for IP component models. Moreover, these models have to consider other requirements. First, the model should be flexible enough to consider various topology configurations. Second, it should be easy to model and evaluate several arbitration schemes. Third, interface should be clearly and easily modeled to integrate IP component models efficiently. Fourth, a good analysis environment should be tied with the model to assess the simulation results. For example, bus contention, utilization and throughput are very important metrics to be assessed in communication architecture.

AHB+ Bus System Architecture

AMBA2.0 protocol is widely being used, but the serious problem is that it cannot guarantee master's QoS (Quality of Service). AHB+ is designed to address this issue. [START_REF] Lim | Samsung DVDP Bus & Memory Architecture[END_REF] Also, it aims at improving the overall throughput as well. AHB+ maximizes bus utilization and guarantees master's QoS using several arbitration algorithms with request pipelining scheme.

AHB+ bus architecture consists of AHB+ main bus, DDR Controller (DDRC), and a Bus Interface (BI). BI is designed for transferring special information between arbiter and memory controller such as the next transaction information, idle bank, access permission and so on.

In order to guarantee QoS of IPs, AHB+ has special internal registers. These registers store QoS objective value and the type of real-time/Non-real time master. To maximize bus throughput, AHB+ hides the latencies incurred between the requests of masters by pipelining the master requests. In AHB+ bus architecture, the arbiter gives the next transaction information to DDRC in advance, then, DDRC can pre-charge the next accessed memory bank, thus it is possible to suppress the latency between transactions. As a result, the next data can be served immediately right after the previous data is processed. This is the concept of bank interleaving which maximizes bus utilization.

Transaction Level Modeling of AHB+ Bus System

We describe our transaction-level modeling steps of AHB+ and its memory controller as follows.

Re-definition of Protocol in Transaction-level

First of all, the AHB+ protocol needs to be redefined as transaction-level ports of TLM. Unfortunately, in many cases, bus protocol in a design specification is described at signal level. Therefore, it is necessary to map signals into TLM transaction-level ports. (typically, they are implemented as variables or functions.)

Behavior Description at Transaction Port

The next step is to model the behavior of each transaction-level port. For example, in RTL, a master can immediately get 'HGRANT (bus grant signal)' from the bus Young-Taek Kim, Taehun Kim, Youngduk Kim, Chulho Shin, Eui-Young Chung, Kyu-Myung Choi, Jeong-Taek Kong, Soo-Kwan Eo CAE Center, SOC R&D, System LSI, Samsung Electronics Co., Ltd.

Giheung-Eup, Yongin-City, Gyeonggi-Do, Korea 449-711 ytkimn@samsung.com

Fast and Accurate Transaction Level Modeling of an Extended AMBA2.0 Bus Architecture

after sending 'HBUSREQ (bus request signal)'. This step is represented as the transaction port of a master calls CheckGrant() and receives 'true' as a return value. After then, the master sends 'HADDR (address)' and 'HRDATA (read data)' and receives 'HREADY'. This behavior is also modeled as the transaction port of the master calls 'Read(addr, *data, *ctrl)' function and receives 'OK' as a return value.

Function Description in Bus Internals / Memory Controller

Internal functions of the arbiter were implemented. In the design of AHB+, seven arbitration filters are implemented and they are always activated without the consideration of master / slave combinations. In addition, we modeled the write buffer of AHB+ for the purpose of processing write transactions more speedy and efficiently. The write buffer stores the information of write transactions when a master cannot get a bus grant at the right time. The write buffer behaves as another master when it is occupied by waiting transactions.

We also modeled the DDR controller as a TLM in order to increase the accuracy of overall communication architecture. This is very important that the overall latency of data access from memory critically depends on it. To maximize memory bandwidth, each bank has a state machine separately, and column, row, and pre-charge accesses have different priorities by scheduling scheme. To increase the cycle accuracy, we modeled the FSM as accurate as register transfer level. Instead, the data path is highly abstracted to increase simulation speed.

Design of Special Interfaces and Platform Integration

AHB+ and DDRC are interfaced with a special protocol called BI (Bus Interface). This interface is designed to support the bank interleaving feature for throughput enhancement.

To consider the cycle accuracy of communications through the bus architecture, we defined the timings of each transaction function. After defining the interface signals, AHB+ bus main and DDR controller were connected each other. Then whole system was completed together master and memory.

Assertion for Error Handling

We have inserted two types of assertion statements into the transaction-level models. The first feature is for the functional debugging of the model itself. The other feature is related to the property checking and this is very helpful especially when the bus model is integrated with master models and simulated for performance analysis.

Proceedings of the Design, Automation and Test in Europe Conference and Exhibition (DATE'05) 1530-1591/05 $ 20.00 IEEE

Insertion of Profiling Features

We also provide convenient profiling features by integrating the model with the commercial EDA tool. In AHB+ TLM, we implemented bus and master port profiling features in transaction-level ports and some internal functions such as arbiter, write buffer and so on.

Flexibility and Reusability

For the flexibility and reusability, AHB+ TLM has several parameters, such as bus width, write buffer depth, arbitration algorithm on/off, and etc. Other parameters are selection of real-time/non-real time type of a master, write buffer on/off, and QoS value.

Model Accuracy and Simulation speed

The transaction-level AHB+ model are validated by comparing it with the RTL model. To increase simulation speed, we used method-based modeling method rather than thread-based method. Also, we used 2-step cycle-based simulation tool to further speed up the simulation.

We modeled and simulated a target system by changing the traffic patterns of the maters as shown in Table 1. From Table 1, the average accuracy difference is below 3%. From this fact, our AHB+ model is accurate enough to be used for performance analysis.

The simulation speeds were measured at both TL and RTL. At RTL, it is 0.47 Kcycles/sec, and at TL, 166 Kcycles/sec. When we used only one master as an input for evaluating the pure performance of our bus architecture, the simulation speed went up to 456 Kcycles/sec.

The implemented bus TLM boosts simulation speed with sufficient accuracy and provides bus profiling features for performance evaluation. From the experimentation results, the implemented model is 353 times faster than RTL model while maintaining 97% of accuracy on average.


Alisée Nguyen

Pedro González De Alaiza Martínez

Illia Thiele

Stefan Skupin

Luc Bergé

Broadband THz radiation from two-color mid-and far-infrared laser filaments in air

We study THz emission by two-color femtosecond filaments in air using pump wavelengths λ0 from 0.8 to 10.6 µm. Comprehensive three-dimensional numerical simulations show that tens-ofcentimeter long filaments created by a 10.6-µm pump pulse can produce mJ energy yields and GV/m field strengths, while the laser-to-THz conversion efficiency exceeds the percent level. Changing temperature and humidity conditions reveals a surprisingly high stability of the THz spectra against different weather conditions. We also examine the role of many-body Coulomb effects on ionization. This additional plasma source promotes longer filaments that act as efficient THz emitters.

Terahertz (THz) science is attracting a broad interest because of its ability to detect many molecular fingerprints through non-invasive spectroscopy methods [1]. Efficient laser-based THz sources rely on the nonlinear polarization in χ (2) crystals [2] or photocurrents in gasplasma [3]. A well-known technique is to focus a twocolor (2C) femtosecond light pulse, composed of a fundamental pulse (FH) and its second harmonic (SH), into air. From the resulting plasma, THz radiation develops high field strengths and broad spectra, even remotely [4] with no limitation due to laser damage. Recent studies [5,6] showed that increasing the pump wavelength can enhance the THz conversion efficiency (CE), which is at most limited to ∼ 10 -4 for a 0.8 µm 2C pump pulse. Whereas optical rectification in large-size organic crystals allows to achieve CEs up to the percent level [2], the THz fluence remains below the mJ/cm 2 range. To exceed the mJ limit from small interaction surfaces, increasing the value of the laser wavelength may supply an efficient alternative. Longer laser wavelengths, e.g., 3.9 µm delivered by optical parametric chirped pulse amplification, are nowadays accessible in the femtosecond regime [7]. Ultrafast (100 fs) CO 2 lasers operating at 10.6 µm with energies close to the Joule level are also awaited in the coming years [8,9]. Therefore, long-range numerical simulations using energetic, sub-ps pulses have been performed in these wavelength domains [10,11]. They revealed the possibility to enhance the nonlinear propagation path by copropagating higher harmonics created through carrier wave shock formation [12].

In this paper, we focus on intense, broadband THz fields created by long-wavelength pulses. By means of a three-dimensional (3D) unidirectional solver [13], we investigate THz generation in air by 2C femtosecond pulses. The pump wavelength λ 0 is varied from 0.8 to 10.6 µm. Our numerical results display evidence of unprecedented THz energy yields and CEs achieved over long distances, in agreement with Local Current (LC) estimations [14]. For CO 2 lasers, we also show that the weather conditions have a surprisingly little im-pact on the THz spectra. Besides the standard photoinduced field ionization, we finally account for manybody Coulomb ionization in argon, expected to become significant at 10-µm pump wavelength [15,16]. This additional plasma source efficiently contributes to THz generation earlier in the pulse history.

To start with, we use the LC model [14] to evaluate the performances of long-wavelength optical pulses as potential drivers for THz emission. Here, the THz field E THz is extracted from filtering the secondary field E J ∝ ∂ t J emitted from the free electron current density J [START_REF] Jefimenko | Electricity and Magnetism: An Introduction to the Theory of Electric and Magnetic Fields[END_REF]. The filtering frequency is chosen as ν f = 10 THz, in order to limit the influence of the pump broadening into the THz spectrum. At moderate laser intensities < 10 15 W/cm 2 , the current density is given by a plasma fluid model [3], ∂ t J + ν c J = e 2 N e E/m e , where e and m e are the electron charge and mass, respectively; ν c ≈ 2.86 ps -1 is the electron-neutral collision rate [START_REF] Andreeva | [END_REF]. N e is the density of free electrons governed by

∂ t N e = i W i (E)(N a,i -N e,i ), (1)
where N a,i and N e,i are the initial gas density of species i = O 2 , N 2 , and their extracted electron density, respectively, so that N e = i N e,i . W i (E) is the field-dependent version of the cycle-averaged Perelomov, Popov and Terent'ev (PPT) ionization rate [19] applied for air to 80% of nitrogen and 20% of oxygen with ionization potentials U i (N 2 ) = 15.6 eV and U i (O 2 ) = 12.1 eV. For Ar we will use U i (Ar) = 15.76 eV.

We apply the LC model to the local input laser field

E(t) = E 0 n=1,2
a n e -(2n ln 2 t τ )

2 cos (nω 0 t + φ n ), (2)
where the amplitude E 0 = 2I 0 /c 0 depends on the pump intensity I 0 , τ = ν -1 f = 100 fs is the full-width-athalf-maximum (FWHM) pulse duration, ω 0 = 2πc/λ 0 is the FH frequency (n = 1), a n and φ n are the amplitude coefficient and phase of the nth harmonic, respectively. We consider 2C pulses with amplitude coefficients a 1 = √ 0.9, a 2 = √ 0.1 and laser fluences U L = 5 -10 J/cm 2 , corresponding to I 0 = 100 -200 TW/cm 2 mean intensities. The relative phase between the two colors is set to its optimum value of π/2 for THz generation by photocurrents [3,6]. We show in Figs. 1(a,b) the evolution of the THz yield

η THz = +ν f -ν f | ∂ t J| 2 dν/[(e 2 N a /m e ) 2 U L ]
with the pump wavelength [20], for which we compute the electron density through Eq. ( 1) for O 2 . With a 10.6-µm pump wavelength, a gain of about two orders of magnitude can be expected in the THz energy yield compared with a near-IR pump. A tentative scaling in λ α supports an exponent α close to 2 [6]. The energy density should thus be readily increased by four orders of magnitude when multiplying the FH wavelength by a factor 10, first through photocurrents [Fig. 1], second by preserving in the optical beam the same amount of critical powers for self-focusing P cr ∝ λ 2 0 . This possibility thus invites us to operate in the filamentation regime [21], for which the larger critical power at long wavelengths renders the self-guiding of high pump energies in a single filament possible, without beam breakup.

To test the previous evaluation, we use the 3D Unidirectional Pulse Propagation Equation (UPPE) [13]:

∂ z E = i k 2 (ω) -k 2 x -k 2 y E + i µ 0 ω 2 2k(ω) F NL , (3)
where k(ω) = n(ω)ω/c is the wave number with air refraction index n(ω), z is the propagation variable and E(k x , k y , z, ω) is the Fourier transform of the electric field. The first term on the right-hand side of Eq. ( 3) describes linear dispersion and diffraction of the pulse.

The second term F NL contains the third-order nonlinear polarization P NL , the electron current J and a loss term due to ionization [21]. Air dispersion is taken from [22], completed with HITRAN data [START_REF]Hitran on the Web[END_REF][START_REF] Rothman | [END_REF] accounting for water vapor and carbon dioxide. The main absorption lines are located at 2. creasing the pump wavelength, longer filaments form (see also [27]). Due to the smaller Rayleigh range, the 10.6µm pump pulse starts its self-focusing sequence earlier. Figure 1(e) illustrates the THz energy inside part of the numerical box versus the propagation axis. This energy remains below the µJ level for λ 0 = 0.8 µm, but it increases to the 0.1 mJ level for mid-IR pumps and even to 3.1 mJ for far-IR lasers, confirming the 4 orders of magnitude increase expected from the LC model above. The THz CE obtained at 10.6 µm is 3% against 1% at 3.9 µm. Let us notice that the yield curves of Fig. 1(e) decrease instead of saturating to a plateau value, which is mainly due to THz components leaving our finite time window.

To go one step further, Figs. 2(a,b,c) detail the THz spectra computed at the distance of maximum THz production, for which the slope of the THz energy in Fig. 1(e) is the strongest. Because diffraction of THz pulses is very fast, this distance corresponds in most of cases to the location of the maximum on-axis THz intensity. Apart from the impressive increase in the THz spectrum, Fig. 2(c) also evidences for the 10.6 µm pump pulse that augmenting humidity and temperature makes water absorption lines stronger around 3 and 6 THz. However, these absorption zones are spectrally narrow and they do not visibly reduce the total THz yield, as confirmed by Fig. 1(e). Besides, an important debate has been the role of Kerr-induced four-wave mixing compared to that of photocurrents in laser-driven THz pulse generation [START_REF] Andreeva | [END_REF]. To clear up this point, Figs. 2(a,b,c) compare THz spectra computed until the indicated distances without the plasma terms. The presence of plasma clearly enlarges the spectra by about 3 orders of magnitude and shifts the peak frequencies down to ν THz < 1 THz. Hence, plasma generation and related photocurrents -even involving rather low electron densities ∼ 10 15-17 cm -3remain the key players in THz pulse generation. Fig- ures 2(d,e,h) evidence the broader laser-plasma interaction surfaces engaged at longer FH wavelengths. This is due to the λ 0 -dependent increase in the filament waist [27,28] and so, in the plasma transverse cross-section, which amplifies in turn the THz yield. Also, the conical emission angle of the radiated THz pulses decreases with the FH wavelength: THz waves indeed diffract with angles of 6.2 • and 2.3 • for λ 0 = 0.8 and 3.9 µm, respectively. With a 10.6-µm pump pulse, in contrast, THz waves are emitted nearly on-axis within a 1.2 • angle. Hence, they can propagate over a longer distance in the numerical box and offer a better directivity.

Figure 3 displays the entire optical spectrum developed for the three FH wavelengths along the propagation axis, together with optical and THz field patterns at the distance of maximum THz generation. For a near-IR pump, this distance coincides with that of maximum plasma generation, close to focus. When increasing the pump wavelength, high-order harmonics are amplified over a longer coherence length [29] and they form a broader supercontinuum through the plasma nonlinearity, self-and cross-phase modulation [Figs. 3(a,d,g)]. Ionization arises in the rear pulse, but intense pump components remain in the undepleted front pulse [see Figs. 3(b,e,h)]. The THz field is peaked where the pump field is maximum and it increases with λ 0 [Figs. 3(c,f,i)].

Another phenomenon appears at 10.6 µm. As shown by Figs. 1(d,e), THz fields are maximum well before maximum plasma generation sets in. At focus, high harmonics mainly go on feeding ionization. However, they do not produce THz waves by photocurrents because their temporal profiles cannot form an efficient, asymmetric field triggering low-frequency radiation. Figure 4 confirms this point: at focus the rear part of the electric field composed of the highest harmonics is intense enough to contribute alone to plasma generation. Ionization steps are created on-axis by high harmonics that can propagate into the plasma, unlike the ω 0 and 2ω 0 optical components. However, THz generation still proceeds from the residual two colors surviving in the front pulse and forming early density steps. Because the broadest plasma surface extends at z = 19.5 cm [Fig. 2(f)], maximum THz generation takes place at this distance. Much less THz energy is produced at z = 30 cm, as the plasma diameter is de- creased by a factor ∼ 3.5.

Finally, it is compulsory to examine the many-body Coulomb ionization (MBI) effect on THz generation proposed by Schuh et al. [15,16]. Under strong laser field irradiation, excited-state electrons from neighboring atoms are able to collide and thus increase the ionization rate. This effect is all the more relevant as the pump wavelength is large. It manifests at low laser intensities where multi-photon or tunnel ionizations vanish. Therefore, it should be taken into account for far-infrared optical fields. To model it, we use the fit proposed in [16] for a 10-µm pump wavelength interacting with argon atoms:

W MBI (E) = CE 4 E 2 + s E 2 , (4)
where C = 1.1095 × 10 4 m 4 /GV 4 and s = 4.6 GV 2 /m 2 . So, we now turn to an argon gas at ambient pressure and, using Table I's parameters, simulate 100-fs focused pump pulses operating at critical power with a 1/e 2 radius of 3.5 mm. The MBI rate is added to the PPT rate of Eq. ( 1), yielding the ionization curve plotted in Fig. 5(a). Compared with the PPT rate alone, the MBI rate ∝ E 4 is important in the intensity region < 20 TW/cm 2 and allows a more efficient ionization at earlier propagation [see Fig. 5(b)]. Figure 5(c) details the plasma response in time, which is mainly governed by Eq. ( 4) in the range z ≤ 10 cm. This exhibits a steplike increase, which can promote efficient photocurrents although the MBI steps are less sharp than the ones occurring in the tunnel regime [14] at, e.g., z = 20 cm. With such plasma contribution, we finally report in Fig. 5(d) that THz emission starts at the very beginning of the propagation range, but it saturates due to accumulated plasma defocusing actions. Without MBI, a THz energy yield of 7-mJ is reached, corresponding to 4% conversion efficiency. With MBI, comparable, although quantitatively smaller values are reached (1.5 mJ THz energy and 0.9% CE).

In summary, we demonstrated by means of numerical simulations that two-color CO 2 laser filaments can provide THz conversion efficiencies above the percent level at moderate laser intensities. Far-infrared filaments are able to self-channel over longer distances and supply energy yields of several mJ. We outlined the effects of weather conditions as well as the influence of many-body ionization. Even if the latter effects may mitigate the conversion efficiency to some extent, they still enable to produce mJ-energetic THz fields over long propagation ranges.

FIG. 1 .

 1 FIG. 1. (a,b) Laser-to-THz CE evaluated in the frequency window ν < 10 THz from Eq. (1) using the two input fluences (a) 5 J/cm 2 and (b) 10 J/cm 2 (φ1 = 0, φ2 = π/2) and producing electron densities that barely vary with the FH wavelength (see top values). Dotted gray curves are fits in λ α . (c,d,e) Results from 3D UPPE simulations of 2C near-to far-infrared filaments. (c) Maximum intensity along z using winter HITRAN dispersion for FH pump wavelengths of 0.8 (magenta), 3.9 (green) and 10.6 µm (blue curves). Associated (d) peak electron densities and (e) THz energies [integral over (x, y, t)], computed along z for winter (blue) and summer (red curve) in the case of the 10.6-µm FH. Vertical dotted lines show the distances of maximum THz generation (see text).

  FIG. 2. (a,b,c) Transversally-averaged THz spectra at distances of maximum THz generation (a) z = 30 cm, (b) z = 27 cm and (c) z = 19.5 cm using the same color plotstyle as in Figs. 1(c-e). Dash-dotted curves show the same quantities without plasma generation. (d-f) THz pulse fluence in the (x, z) plane for FH pump wavelengths of (d) 0.8, (e) 3.9 and (f) 10.6 µm. White lines serve as eye guides for the conical emission angles, fitting the curve zmax(x) such that UTHz(x, zmax) = maxz UTHz(x, z). Plasma transverse isocontours at 10 16 cm -3 are indicated by gray lines.

FIG. 3 .

 3 FIG. 3. (a,d,g) Intensity spectra (left colored patterns) along propagation for λ0 = (a) 0.8 µm, (d) 3.9 µm and (g) 10.6 µm. The vertical dotted lines indicate the distance of maximum THz production. (b,e,h) Corresponding on-axis propagating field (blue curve, left axis) and electron density (green curve, right axis) at maximum THz production. (c,f,i) On-axis THz field obtained by filtering the total electric field E with a 20th-order Butterworth filter in the frequency window ν < 10 THz.

FIG. 5 .

 5 FIG. 5. (a) Ionization rate vs laser intensity with (black lines) or without (gray lines) MBI evaluated from Eq. (2) as input in a 1-bar argon gas. (b) Peak electron density reached along propagation (UPPE simulations with collisional ionization) including (black) or not (gray lines) MBI. (c) Plasma density profiles in time at z = 0.1 m and z = 0.2 m. (d) Associated THz energy yield.

TABLE I .

 I Pump wavelengths, Kerr indices, Raman-delayed ratios and input laser energies for air and argon.

	λ0 [µm]/gas	0.8/air	3.9/air	10.6/air 10/argon
	n2 [10 -19 cm 2 /W] 3.8	3.6	3.3	1.0
	xK	0.8	0.8	0.8	0.0
	UL [mJ]	0.494	12.4	100	169.4

This work was supported by the ANR/ASTRID Project "ALTESSE" # ANR-15-ASTR-0009 and performed using HPC resources from GENCI (Grant # A0020507594). S.S. acknowledges support by the Qatar National Research Fund through the National Priorities Research Program (Grant # NPRP 8-246-1-060). * alisee.nguyen@cea.fr


ARM Wayne Lyons

Meeting the Embedded Design Needs of Automotive Applications

The importance of embedded systems in driving innovation in automotive applications continues to grow. Understanding the specific needs of developers targeting this market is also helping to drive innovation in RISC core design. This paper describes how a RISC instruction set architecture has evolved to better meet those needs, and the key implementation features in two very different RISC cores are used to demonstrate the challenges of designing for real-time automotive systems.

Introduction

The dominant trend in RISC core design has been to follow a path towards higher CPU clock frequencies and more complex feature sets. This 'up-and-to-the-right' industry roadmap is certain to continue, with many embedded applications requiring support for ever higher levels of performance and richer functionality. Automotive embedded functions, however, are characterized by a mixture of high-performance systems as well as far simpler, low-performance but extremely cost-sensitive applications. Clearly, it is not possible to satisfy these opposite ends of the performance spectrum with the same physical device.

Currently, a typical automotive system consists of a physically distributed network of 8/16-bit and 32-bit processors that are dedicated to specific tasks within the car. These tasks range from relatively simple and straightforward functions such as monitoring an oil pressure sensor or controlling the movement of electric windows, to much more complex and demanding engine management, in car entertainment or navigation systems. The simpler tasks are typically addressed by the use of 8 and 16-bit microcontrollers.

The automotive industry's vision for the future is that these discrete and distributed compute resources could be collectively harnessed to enable application processing requirements to be distributed on what is effectively a powerful virtual multi-core processing system. To enable this vision, one of the key requirements will be the harmonization of the instruction set architecture (ISA) throughout the entire automotive system. Apart from the ability to distribute tasks, designing to a common ISA will also deliver benefits to the manufacturers in terms of the ability to reuse code, and broader development economies of scale.

A precondition for any automotive manufacturer to be able standardize on a particular ISA is the availability of processor implementations that will satisfy efficiently both ends of the performance spectrum. This demands an architecture that has sufficient flexibility to enable the design of very small and efficient 32-bit processors that rival 8-bit controllers in cost-effectiveness, as well as high-frequency, high-performance processor cores.

ISA Foundation

The ARM architecture has been extremely successful in addressing a broad spectrum of embedded design requirements, and has evolved over a number of years to provide a foundation for a portfolio of core implementations offered by many different manufacturers. ARM is now the most widely used architecture for new embedded designs.

One of the key features that has driven the popularity of the architecture has been the compressed instruction set extension known as 'Thumb ® '. The Thumb instruction set features a subset of the most commonly used 32-bit ARM instructions, which have been compressed into 16-bit wide opcodes. On execution, these 16-bit instructions are decompressed transparently to full 32-bit ARM instructions in real time without performance loss. In analysing the needs of automotive developers, it became clear that historically Thumb has been, and continues to be used extensively to achieve the best possible code density. Achieving good code density implies minimum memory footprint, which is critical in reducing system cost.

It became apparent that an evolution of Thumbknown as Thumb-2 technology -could enhance the performance and code density even further to the benefit of all embedded applications. The new Thumb-2 ISA extension has provided the capability for several other feature improvements introduced in the latest ARM core implementations.

Thumb-2 Technology Development

Memory dominates the bill of materials cost in virtually all embedded automotive applications. As well as improving performance over the original Thumb specification, Thumb-2 technology seeks to maximize usage of cache, as well as tightly coupled and embedded flash memory, and so helps to reduce the overall memory footprint.

Thumb-2 technology is a blend of 16 and 32-bit instructions. In developing Thumb-2 technology, the initial objectives were to achieve the performance of 32bit ARM instructions yet match the code density of the original Thumb instruction set. Preliminary EEMBC benchmarking data substantiates the original performance objective. To improve performance over the original Thumb implementation, Thumb-2 technology has incorporated some of the most popular ARM instructions for data processing, DSP and media functionality, as well as the load and store multiple instructions that are used for context switching in and out of subroutines. Conditional branch is supported to enable longer branching instructions and support a bigger target address rangeeffectively allowing a branch anywhere within the target memory address range without having to go through an indirection.

Thumb-2 technology also supports the ability to add a co-processor, if required. The Vector Floating Point (VFP) co-processor is becoming relevant to automotive applications since it allows designers to work directly with floating point output from popular code generation tools, enabling a smooth migration to autocode generation. Floating point capability also enables the developer to work in the native units of measurement without the need for scaling operations. Often, this route is followed for convenience and to benefit from a more efficient process in translating the output from automatic code generation tools, rather than conferring any performance benefit within the application.

For developers who wish to scale values read from sensors, the hardware divide instruction enables data to be scaled very efficiently.

Thumb-2 technology also incorporates completely new functionality, specifically aimed at supporting deeply embedded control applications. Deeply embedded applications are characterised by the need to process large volumes of general-purpose input-output (I/O) data. Often, the core requirement is to extract bit-level data from specific pins or sensors, which may have been brought in to the device as an 8-or 16-bit word. In order to utilize that information, the required bits must be extracted. In many legacy 8-bit development environments, bit-manipulation instructions are provided but implemented in micro-code they typically take several cycles to execute a simple bit set or bit clear function.

With Thumb-2 technology, support for bit manipulation through bit field insert and clear, as well as bit reversal instructions, allow comprehensive bit manipulation to be performed very efficiently. In previous RISC architectures, typically the whole word would be read in and then rotated over several cycles to get the required bit into the correct location to perform the logical manipulation. The new Thumb-2 instructions achieve this operation by representing the information to the processor as bits within the whole port, enabling the bit-level information to be extracted and manipulated much more efficiently with direct instructions.

Supporting Flash Memory

Embedded flash is an important and popular technology in many embedded applications, providing flexibility and continuity in data storage. However, embedded flash memory is slow, typically operating at only 30-40MHz. As processor cores and digital logic has benefited from increased performance through architectural and technology enhancements, embedded memory performance has not moved forward significantly. For example, the expected performance of flash memory in 0.25-micron process would typically have been around 40MHz. In moving to a 0.18-micron process this might only increase to around 41MHz. Consequently, there has been a growing gap between the CPU speed and the memory speed.

To accommodate this performance gap, in designing the flash memory interface designers typically fetch more than one 16-bit value at a time -effectively streaming data from the memory to keep the processor busy.

In moving data, if the data cannot be moved immediately with the instruction, a literal pool fetch is typically used. This pool of immediate data is held quite close to where the program counter is currently located. Consequently, literal pools become spread throughout the memory map. This means that the fetch sequence from the flash memory can be disrupted by a non-sequential fetch of data from the literal pool, before returning back to the sequential fetch. The stream of information is therefore broken from the embedded flash, and consequently, performance is degraded. Benchmarks show a performance degradation of 15 percent is possible because of this effect. This non-sequential fetch of data which occurs when the instruction stream breaks the sequential access, imposes significant performance degradation. A cached architecture will typically outperform a Harvard machine by a similar margin under these conditions.

The 16-bit immediate instructions MOVW and MOVH help to address this performance degradation. The literal pool is loaded immediately within the instruction, by effectively sequentially loading the data with the instruction with no break to go off and fetch from the literal pool. This mechanism restores the sequential nature of instruction accesses being made to the flash.

Targeting C

The use of C as a high-level language is almost universal for deeply embedded application environments, so ensuring that the instruction set is as efficient as possible as a C target is very important. Adding two new instructions that compile very efficiently from C, help to improve both performance and memory footprint.

The conditional 'IF-THEN', or IT, instruction carries with it a set of conditional codes that predicate the execution of the instructions that follow. In a Thumb environment, conditional branching is addressed by having multiple branches. In Thumb-2, having a conditional IT instruction means that it is possible to step straight through the conditional code and the instructions are executed (or not executed -represented by a 'NOP') instead of having to branch too indiscriminately. Again, this instruction encourages sequencing of opcodes rather than branching, which helps to maintain processor performance.

The

Thumb-2 Implementations

The flexibility of Thumb-2 technology in supporting the needs of the automotive market is demonstrated in two distinct core implementations. The ARM1156T2F-S™ processor is a high-performance design intended for high-end applications, which includes, among many other new features, a fault-tolerant memory interface and finegrained memory protection unit (MPU). The new ARM Cortex-M3 processor is a silicon-efficient 32-bit processor that is cost-competitive with 8-and 16-bit devices.

ARM1156T2F-S Processor

The features incorporated into the design of the ARM1156T2F-S processor core have been specified after extensive consultation with automotive companies and industry bodies. Particular attention has been paid to the requirements of OSEK (Version 2.1.1) compliant realtime operating systems (RTOS). OSEK is a European automotive industry standards effort to produce open systems interfaces for vehicle electronics.

Fine-grain Memory Protection Unit

A key part of OSEK's strategic vision is to enable re-usability of software modules in order to deliver economies of scale and time-to-market benefits to the industry. Automotive component suppliers want to be able to select software from partners to most effectively address the needs of specific functions. For example, in the engine domain, a manufacturer may benefit from being able to re-use a third-party software model to characterise engine wear and tear. In order to enable software re-use from several different sources, it is vital that there is a mechanism to allow each module to be isolated so that the risk of interference is minimised. The requirement is to be able to isolate or 'lock down' many of these routines.

Current Memory Protection Units (MPUs) typically offer 4KByte code boundaries for isolating functions. This is typically too large for systems which have limited memory resource. Large code boundaries mean that it is impossible to efficiently segregate many small software routines -often several tasks will have to be included within the same protection scheme.

To enable good segregation of individual tasks executed within an OS kernel, the new ARM MPU has been completely re-engineered to provide a finer granularity of memory region for each task. This enables more effective use of the available memory resource for supporting multiple tasks. This MPU architecture will be carried forward to future ARM cores.

Enhancing Predictability

Predictability is important in many deeply embedded applications. For example, in automotive, implementing the 'tooth-to-spark' function requires regular and timely action from the processor if it is to be serviced predictably and reliably. The ARM1156T2(F)-S core is intended for higher end applications and will typically be clocked in excess of 200MHz, and will include cache memory. A number of enhancements made improve the predictability of the core, even under these operating conditions.

Adding new instructions to enable exception entry and exit gives a higher-level of predictability to cachebased architectures and enables interrupts to be serviced much sooner following the interrupt request.

The use of cache memory in the system architecture can create issues with system predictability, especially when the required data is absent from the cache memory.

Performing a multiple load of say ten 32-bit words from a cache line that is typically eight words long, could require up to three lines of cache to be accessed. In the worst case, if the data for those three cache lines is not available, this could result in three cache line misses. The cache contents would then have to be re-loaded from external memory, causing a considerable delay to the processor before it can proceed to the next instruction or enter into the interrupt service routine.

The availability of a low latency interruptible, restartable load/store multiple instruction helps to overcome this problem. With the interruptible, restartable load store instruction, an interrupt can be serviced even if the processor is busy dealing with cache line misses.

This facility makes the use of cache-based architecture much more acceptable for real-time systems, assuming that the cost overhead associated with cache memory is also acceptable. This will still be a factor in safety critical systems where often two or more cores are required to facilitate a redundancy check.

A further enhancement to predictability is derived from the Non-Maskable Interrupt (NMI) added to the Fast Interrupt Request (FIQ). This allows the fast interrupt source to be made non-maskable, which is particularly important when a watchdog is used in the system that needs to be serviced at a particular time.

Managing Soft Errors

Soft errors occur as a result of cosmic radiation altering the state of the circuit. Unlike hard errors, soft errors are temporary phenomena and can be corrected. Soft errors pose an increasing risk as geometries shrink, and leading-edge processes at 0.13-micron to 90nm and below, are more vulnerable. Because of the density of transistors, cache memory is especially susceptible to soft errors.

The ARM1156T2(F)-S processor supports faulttolerant RAM for the cache. The cache instruction line is invalidated if it detects an error, forcing the code to be reloaded. Any error detected in the TAG RAM generates a cache miss. An error in the cache RAM generates a prefetch abort. The core generates precise exceptions for data cache. With data errors there is uncertainty whether the error is within the data or whether it is due to the location address generation.

Data cache errors cause a data abort and the software can then fully recover the data cache contents. The processor also supports fault-tolerant RAM for tightlycoupled memory (TCM). The normal mode of operation for a TCM is that it is kept running to feed the processor -the fault-tolerant support allows a stall to occur. The processor is effectively suspended while the error correction process is invoked. This 'hold and repair' scheme is implemented without the need for an interrupt, i.e. it is supported directly from the core. From a performance perspective, many automotive applications do not require the high levels of performance that are achievable from a 32-bit processor. However, many companies would like to standardise on a processor architecture across the automotive platform, to enable reuse of software modules and for the broader economies of scale benefits. Modern vehicles are being developed with an increasing number of processor nodes to facilitate monitoring of sensors for body control, such as electric windows, seat control, oil pressure and temperature monitoring. The capability to network these processors and use them as a multi-core compute machine, distributing and scheduling tasks to processors that have spare capacity, can by realised earlier by standardising on a software architecture. The ARM Cortex-M3 processor, based on Thumb-2 technology, is highly applicable to current 8/16-bit applications that are to be migrated to the ARM architecture.

ARM Cortex-M3 Processor Features

The ARM Cortex-M3 processor includes specific features to provide highly-efficient support for the less demanding deeply embedded automotive functions.

Simplified Interrupt Scheme

Most control systems are heavily loaded with interrupts. A high-end system will typically include many intelligent peripherals that will service some of the lowend interrupt functions, by grouping and bufferingwithout bothering the processor. With this more intelligent (and expensive) interrupt control process, peripherals can run autonomously for a while. In a lower end system this will not be the case as it adds too much cost to the peripherals. In this case the processor itself will spend a lot of time servicing the interrupts, putting a heavy load on the processing unit. In this situation it is important to have an efficient interrupt response and handling scheme.

In addition, the preamble sequence, which typically saves the system context, and postamble (which restores the system context) to service an interrupt is performed directly in hardware. This means that software developers can write the interrupt service routine in a high-level language and just compile it. On a RISC machine, typically a stub of assembly code would be required at the beginning and end of the interrupt to facilitate the pre and postamble. Because the pre-and post-ambles are implemented in hardware, parallelism is enabled. It is possible to fetch vectors from the instruction side flash memory while simultaneously writing important system variables. This reduces the number of cycles required to perform an interrupt compared with a scheme managed by software.

The main benefit of this approach is that by aggregating the post and preamble stages, back-to-back handling of interrupts is possible. The processor checks to see if another interrupt is pending at the end of the first interrupt service routine, without restoring the context, in order to get them both serviced in the minimum amount of time.

Bit Banding

In all embedded systems, cost dictates that on-chip RAM is a scarce commodity. Consequently, the RAM that is available must be utilised as efficiently as possible. This means that even simple semaphores (i.e. single bit of data) must be packed into the relevant bits within a memory byte -typically eight semaphores per byte. Given this storage constraint for semaphores, there is a well-established method for atomic bit manipulation within traditional RISC systems.

To manipulate a particular semaphore within a byte, and to do it atomically (i.e. without disruption from another task which might change the semaphore) it is necessary to disable interrupts to raise the priority of that task, then mask and modify the semaphore and write back to the byte location, before re-allowing interrupts again at the correct priority level. With the ARM Cortex-M3 processor, up to 1MByte of the memory address region can be mapped, or aliased, to 8MBytes of bit-specific locations elsewhere in the memory map. In this scheme a byte is addressing a particular bit. Because the memory is aliased, it is possible to read and write particular bytes to the RAM normally. If a read/write to the bit addressing alias within the 8Mbyte region is made, it automatically performs a bit-set or bit clear at the aliased address. This enables atomic manipulation by operating on the aliased address. In this scheme, what was a multiple operation task becomes a simple, single write saving many cycles. Now the semaphore can be set or cleared by a single write operation to the aliased byte. No interrupt disabling or bit masking is required. Bit banding reduces the code required to write the bit to memory, and the core progresses to the next instruction faster. With this scheme any one operation only affects one bit in the byte, so there is now no need to disable other interrupts.

Single Wire Debug

Often, low-cost microprocessor solutions are characterized by simple, low pin count packagestypically consisting of just 16 or 32 pins. JTAG, the standard test interface port, is a 5-pin interface. When implemented on a low-pin count device this may represent an unacceptable overhead.

The ARM Cortex-M3 processor includes a singlewire viewer and debug access port -effectively emulating the JTAG standard over a single wire. Support for an on-the-fly flash memory patch process means that up to eight words can be configured as RAM, providing an equivalent of eight breakpoints in the system. The ability to perform a dynamic download makes access to embedded flash easy, enabling use during the calibration phase, and for writing system and scaling parameters for sensor measurement. The eight discrete breakpoints can be located anywhere, or grouped together as a data sequence.

Conclusions

To address the technical needs of the automotive industry for embedded software platforms requires a balance of very high performance function with lowcost and extremely efficient implementation. ARM's approach has been to develop two cores on a common instruction set architecture -Thumb-2, which provides the basis for both high performance and code densities.

At the performance end of the spectrum, the ARM1156T2(F)-S processor has been designed to meet the needs of OSEK 2.1.1 RTOS, support fault-tolerant memory interfaces and provide more predictable use of cache memory.

In contrast, the ARM Cortex-M3 processor is intended to support low pin count, low cost devices that are simple to use and easy to design with. By providing efficient support for fast interrupts and atomic bit manipulation, the design of the memory system can be kept clean and very cost-effective. By enabling the use of a common programming model, the benefits of designing within a unified architecture, such as code reuse and hardware standardisation, become a reality. The tangible benefits to the manufacturer include lower unit cost production, ontime delivery, and improved quality. The vision for the future is to enable the distributed network of processors that is becoming the standard automotive platform to be harnessed as a single compute resource.

Figure 1 :

 1 Figure 1: Thumb-2 Performance and Code Size

Figure 2 .

 2 Figure 2. ARMv6 Architecture MPU

Figure 3 :

 3 Figure 3: ARM Cortex-M3 Block Diagram

Figure 4 :

 4 Figure 4: ARM Cortex-M3 Fast Interrupt Response

Figure 5 :

 5 Figure 5: Bit Banding using Aliased Memory

  Table branch instruction is useful for implementing switch case statements where the conditional test is made at the beginning and a sequence of code is executed conditionally.

			Table 1 provides preliminary benchmark data for a
			Thumb-2 implementation. Note that scaling is the
			Geometric Mean of the 6 available AutoIndy benchmarks
			for these cores. Preliminary the ARM Cortex™-M3
			processor figures developed on AutoIndy benchmarks.
			Since these are preliminary benchmark figures, further
			improvements can be expected for final data.
	Processor Core	Scaled GM/MHz
	ARM7™ (ARM)	28453.8	(100%)
	ARM7 (Thumb)	22527.8	(79%)
	Cortex-M3™ (Thumb-2) 38899.2	(137%)
	Processor Core	Code Size
	ARM7 (ARM)	21168	(100%)
	Thumb (Thumb)	12106	(57%)
	Cortex-M3 (Thumb-2) 12106	(57%)
	Table 1: Comparing Thumb-2 performance and
	code density with Thumb and ARM

Proceedings of the Design, Automation and Test in Europe Conference and Exhibition (DATE'05) 1530-1591/05 $ 20.00 IEEE