Min Li

Xiaobo Wu

Richard Yao

Xiaolang Yan

Q-DPM: An Efficient Model-Free Dynamic Power Management Technique

When applying Dynamic Management (DPM) technique to pervasively deployed embedded systems, the technique needs to be very efficient so that it is feasible to implement the technique on low end processor and tightbudget memory. Furthermore, it should have the capability to track time varying behavior rapidly because the time varying is an inherent characteristic of real world system. Existing methods, which are usually model-based, may not satisfy the aforementioned requirements. In this paper, we propose a model-free DPM technique based on Q-Learning. Q-DPM is much more efficient because it removes the overhead of parameter estimator and modeswitch controller. Furthermore, its policy optimization is performed via consecutive online trialing, which also leads to very rapid response to time varying behavior.

Introduction

Dynamic Power Management (DPM) is a very general and important power reduction technique targeting on controlling performance and power levels of electronic systems. In DPM system, a Power Manager (PM) monitors the overall system states, and controls the power state of system components. In the coming deep submicron era, DPM will gain more and more importance, because DPM is the one of the most effective techniques to combat with leakage current.

Actually DPM has attracted a lot of interests in the past a few years [START_REF] Benini | A survey of design techniques for system-level dynamic power management, Very Large Scale Integration (VLSI) Systems[END_REF]. Most of them apply stochastic modeling and optimization. The existing methods usually assume that DPM is controlling a stochastic system with explicit model completely known. Recently, some papers have studied how to handle the uncertainty and nonstationary characteristics of the real world. However, these techniques are still based on model.

In the near future, a lot of research challenges will be imposed on DPM. Above all, DPM is demanded by deeply embedded and pervasively employed smart nodes around us, e.g., biosensor node. They have only low end processor and tight budget memory. Hence, the DPM policy optimization needs to be extremely efficient. Actually the same requirement exists in large system and System on Chip as well. Moreover, as discussed in some previous papers, in most real world systems parameters are undertaking continuous varying, and the varying behavior needs to be rapidly tracked, so that the maximum potential of power reduction can be delivered.

Existing techniques have a number of shortcomings that prevent them from surviving the research challenges. First of all, the existing model-based techniques are impractical for low-end deeply embedded systems because of the complexity of policy optimization and time penalty for dealing with time varying. In experiments we observe that, even on Pentium III 800MHz PC, the widely applied linear programming policy optimization runs extremely slow. Besides policy optimization, the parameter estimation also consumes a lot of time to maintain a reasonable accuracy. In addition, the modelswitch controller, which detects parameter variation and determines when to perform policy optimization, is fairly time consuming as well. Hence, when parameters vary continuously, existing model-based approaches may not track the varying rapidly.

In this paper, we present a Reinforcement Learning (RL) based DPM technique namely Q-DPM. The proposed technique is model free, i.e., it does not require explicit model of the system. On the contrary, it learns the optimal policy by trialing continuously. The complexity of the technique is much lower than the model-based counterpart, so that it is feasible to implement on almost any low end systems. Furthermore, since Q-DPM performs consecutive adaptation in every time interval and it removes the overhead of parameter estimator as well as mode-switch controller, its response to varying behavior is very rapid.

Q-DPM

RL is the problem faced by an agent that must learn behavior though trial and error interactions with a dynamic environment. In the standard RL mode, an agent is connected to its environment via perception and action. On each step of interaction the agent receives input as some indication of the state of the environment. The agent then chooses an action, which changes the state of the environment. The value of this state transition is communicated to the agent through a reinforcement signal. The agent's behavior should choose actions that tend to increase the long-run sum of values of the reinforcement signal. It can learn to do this over time by systematic trial and error.

From above description we can see that the RL is one way to derive the policy for Discrete Time Markov Decision Process (DTMDP). RL methods solve DTMDP by learning good approximations to the optimal value function, * J , given by the solution to the Bellman optimality equation [START_REF] Sutton | Reinforcement learning is direct adaptive optimal control[END_REF] is the effective immediate payoff (in the context of DPM. The payoff is energy reduction or certain function of energy reduction), and s E is the expectation over possible next states s , and is the discount factor. Also, RL can be interpreted as direct adaptive control [START_REF] Sutton | Reinforcement Learning[END_REF].

We adopt Q-Learning [5] for our model free DPM. Q-Learning is almost the most practical RL algorithm because it is quite easy to implement. When applying the Watkin's Q-Learning, Bellman's equation can be rewritten in Q-factor as ) , ( max

) ( * ) ( * a s Q s J s A a , ( 2
)
where ) , ( * a s Q can be interpreted as the expected discounted reinforcement (actually a function of energy reduction) of taking action a in state s . Intuitively, on each step we can greedily take the action with maximum ) , ( a s Q . On a transition from state s to s with action a , the ) , ( a s Q is updated as following:

)) , (

( b s Q s a s c a s Q a s Q s A b , max ) , , ( ( ) , ( ) 1 ( ) , ( )
where is the learning rate. In order to make Q-Learning perform well, all potentially important state-action pairs ) , ( a s must be explored. At each state, with probability a random action needs to be taken instead of the action recommended by the ) , ( a s Q . Apparently the run time complexity of Q-DPM is very low. On each step, the DPM daemon only needs to select the maximum ) , ( a s Q , and update the ) , ( a s Q using Eqn.

3. Q values can be encoded in a | | | | a s
table that requires a little bit memory space. Hence, it is feasible to implement Q-DPM on almost any embedded nodes. Actually, Q-DPM has a number of additional advantages, and the most attractive one is that it is tolerant to small scale variations, which is very likely to happen in real world system.

Simulation and Conclusion

The simulation is to preliminarily investigate the performance of Q-DPM. In order to study Q-DPM under various conditions, synthetic input is used to drive the simulation. First we study whether Q-DPM can deliver the maximum potential of DPM in stationary environment. In Fig. 1 we compare Q-DPM to the optimal policy derived by analytical techniques which assume model is completely known in prior. After studying many cases, we conclude that Q-DPM can approximate the theoretically optimal policy at reasonable speed despite it requires much less resources. Moreover, we put Q-DPM in a nonstationary environment by feeding temporarily stationary synthetic input. One typical case is shown in Fig. 2, where switching points are marked by vertical lines. We can read that the energy reduction may be heavily affected by parameter variation (e.g., around the first changing point), and the proposed Q-DPM responds to the variations almost instantly. In contrast to Q-DPM that directly learns optimal state-action mapping, existing methods need to detect parameter change, perform parameters, and then perform time consuming policy optimization. The significant time overhead is removed in Q-DPM.

Fig. 1 Convergence on Optimal Policy

Fig. 2 Rapid Response

There is still a lot of rewarding research remaining to perform, such as QoS guaranteed Q-DPM and Fuzzy Q-DPM in noisy environment. More importantly, the proposed approach is to be verified in experiments.

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

Acknowledgement

This work is supported by the National Natural Science Foundation of China under grant No. 90207001.


Joel Coburn
email: fjcoburn@nec-labs.com

Srivaths Ravi
email: sravi@nec-labs.com

Anand Raghunathan
email: anandg@nec-labs.com

Hardware Accelerated Power Estimation

In this paper, we present power emulation, a novel design paradigm that utilizes hardware acceleration for the purpose of fast power estimation. Power emulation is based on the observation that the functions necessary for power estimation (power model evaluation, aggregation, etc.) can be implemented as hardware circuits. Therefore, we can enhance any given design with "power estimation hardware", map it to a prototyping platform, and exercise it with any given test stimuli to obtain power consumption estimates. Our empirical studies with industrial designs reveal that power emulation can achieve significant speedups (10X to 500X) over state-of-the-art commercial register-transfer level (RTL) power estimation tools.

INTRODUCTION

Power estimation is an important part of the design process for most integrated circuits. The problem of power estimation has been researched at varying levels of abstraction, and many of the resulting techniques have been incorporated into commercial power estimation tools. However, efficient power estimation for large designs remains a challenge due to increases in design and testbench complexity. For example, RTL power estimation for a 1.25 million transistor MPEG4 decoder circuit (for an input stimulus containing 4 frames of a video stream) required 43 minutes and 55 minutes to run on two different state-of-the-art commercial tools [START_REF]Sequence Design Power Tools[END_REF][START_REF] Ravi | Efficient RTL power estimation for large designs[END_REF]. Power estimation tools that operate at the transistor and gate levels are known to be much (10X to 100X) slower.

To achieve efficient power estimation, we harness the speedup of hardware acceleration that comes from using an emulation platform. Typically, power estimation is dominated by the evaluation of component power models based on circuit inputs during simulation. The key observation of this work is that power model functionality can be implemented as hardware circuits. In practice, we can augment any design with power estimation hardware and map it to a hardware emulation platform such as an FPGA. To the best of our knowledge, this is the first effort to leverage hardware acceleration for the purpose of power estimation. We apply the concept of power emulation to power estimation at the register-transfer level, and present a design flow incorporating this idea. We demonstrate the benefits of power emulation by reporting the speedups in power estimation time for several large designs. The results indicate that power emulation can significantly enhance the scope of current RTL and gate-level power estimation methods by making them applicable to large designs with little or no tradeoff in accuracy. Much like functional emulation, we believe that power emulation will provide designers with the ability to study the power consumption of a design under realistic environments and operating conditions.

Related Work

Power estimation techniques have been explored extensively at the transistor, gate, and register-transfer levels of design abstraction [START_REF] Chandrakasan | Low Power Digital CMOS Design[END_REF][START_REF]Low Power Design Methodologies[END_REF][START_REF] Macii | High-level power modeling, estimation, and optimization[END_REF][START_REF] Raghunathan | High-level Power Analysis and Optimization[END_REF]. At the transistor level, power estimation is usually performed as a byproduct of circuit simulation. For gate-level power estimation, signal statistics for the signals in the circuit can be computed through simulation, probabilistic analysis, or simulation with statistical sampling [START_REF]Low Power Design Methodologies[END_REF][START_REF] Macii | High-level power modeling, estimation, and optimization[END_REF]. Of these, simulation with a comprehensive testbench is the most commonly used technique, due to its accuracy and the ability to produce detailed feedback on power consumption. At the registertransfer level, approaches to power estimation include analytical techniques [START_REF] Marculescu | Information theoretic measures for energy consumption at the register-transfer level[END_REF], characterization-based macromodels [START_REF] Benini | Regression models for behavioral power estimation[END_REF], and fast synthesis into gate-level descriptions [START_REF] Llopis | The Petrol approach to high-level power estimation[END_REF]. Behavioral descriptions of hardware lack circuit structural information, so hardware power estimation at the behavioral level has limited accuracy. At the system level, most research has focused on developing power models for different system components, including processors, memories, on-chip buses, etc.

With rising circuit complexities, current power estimation tools perform poorly for large designs and can often be applied to only small parts of a design. The proposed idea of leveraging emulation platforms for power estimation is complementary to most previous work on power estimation, and can be applied to any simulation-based power estimation technique in which the power models may be expressed as synthesizable functions.

POWER EMULATION

The basic concept of power emulation is applicable at multiple levels of abstraction. However, in this paper, we discuss power emulation in the context of register-transfer level (RTL) power estimation. We describe RTL power estimation for an example design, and explain how the power estimation functions can be expressed as hardware and mapped to an emulation platform. We then present a design flow for power emulation. Finally, we provide experimental results to show the speedups achievable through power emulation.

Power Estimation Hardware

Let us consider a characterization-based power estimation methodology [START_REF] Raghunathan | High-level Power Analysis and Optimization[END_REF]. Power estimation is based on a "power macromodel library" for a universal set of RTL components that is created by characterizing their gate-or transistor-level implementations. For each RTL component in the circuit under consideration, a power macromodel is used to compute the component's power consumption as a function of the values observed at its input/output signals during simulation. Power emulation is performed by enhancing a circuit with the appropriate power estimation hardware. This can be done by recognizing the functions pertinent to power estimation, expressing them as synthesizable circuit descriptions, and integrating them into the design. To illustrate this process, Fig. 1 shows an example RTL circuit used to perform binary search, which has been enhanced for power emulation. The circuit contains several new components for power estimation (shown shaded in Fig. 1), including (i) power models that are instantiated for every RTL component in order to track the component's input/output signals and compute a power value whenever triggered, (ii) a power strobe generator to trigger the evaluation of the power models, and (iii) a power aggregator to accumulate the power consumption of individual RTL components to compute the circuit's total power consumption.

Power strobe generation is done separately for each clock domain in the design. Power aggregation is simply implemented as a sequence of additions to accumulate the outputs of the power models. We focus our attention on power models, which form the most significant part of the power estimation hardware.

To explain the structure of hardware power models, we consider a cycle-accurate linear regression based macromodel [START_REF] Benini | Regression models for behavioral power estimation[END_REF], which expresses the power consumed in an RTL component with n input/output bits as

∑ n i=1 Coe f f i T (x i ),
where Coe f f i represent the power model coefficients, and T (x i ) is the transition count (0 or 1) at each input/output bit. The inputs to a power model include the input/output bits of the component being monitored, and a power strobe. The output of the power model is the component's power consumption. The power model performs the following computation

Power = tc(queue x 1 (0) queue x 1 (1)) Coe f f 1 + + tc(queue x N (0) queue x N (1)
) Coe f f N where, tc represents the transition count (XOR) function. The inputs to tc come from a set of internal queues that maintain the previous and current values of each component input/output. Since the transition count is a binary value, the multiplications in the power model equation are simply implemented using vector AND gates. The products of the coefficients and respective transition counts are added to obtain the power consumed by the component in the current strobe period.

A circuit description that has been enhanced with power estimation hardware lends itself to simulation using any HDL simulator [START_REF] Ravi | Efficient RTL power estimation for large designs[END_REF], or emulation using a hardware prototyping platform as suggested in this work.

Design Flow

Figure 2 illustrates the overall flow for power emulation. Given an input RTL design, step 1 maps the RTL components to power models and inserts the corresponding estimation code to create an enhanced RTL description. This description can be fed into any FPGA synthesis, place and route tool flow in step 2. Finally, the generated netlist can be downloaded to the FPGA emulation platform. As in functional emulation, the testbench can be executed within a simulator, or it can be mapped to the FPGA platform along with the design itself. The outputs of the power aggregator and power models can be observed during emulation to obtain the power consumption in the circuit or any part thereof.

EXPERIMENTAL RESULTS

We present the results of applying the proposed power emulation technique to several industrial designs. In our experimental setup, we begin with a C behavioral description of a design and run a commercial behavioral synthesis tool [START_REF] Wakabayashi | C-based high-level synthesis system, CYBER -Design experience[END_REF] to synthesize an RTL description. We perform RTL power estimation using (a) PowerTheater [START_REF]Sequence Design Power Tools[END_REF], and (b) an internal power estimation tool developed at NEC [START_REF] Ravi | Efficient RTL power estimation for large designs[END_REF]. RTL power estimates and power emulation results are obtained for NEC's CB130M [START_REF]CB130 Family 0.13um CMOS CBIC[END_REF] 0:13µ standard cell based technology. The RTL circuits were enhanced for power emulation as described in the previous section. Synthesis was performed with Synplify Pro [START_REF]Synplify Pro[END_REF], and physical design was performed using tools from Xilinx [START_REF]Virtex-II FPGA and tools[END_REF]. For each design, an estimate of power emulation time was computed by measuring the time required to simulate the testbench using the Modelsim HDL simulator and the time to run the design on a PC-based emulation platform using the Xilinx Virtex-II FPGA [START_REF]Virtex-II FPGA and tools[END_REF]. The graph of Figure 3 compares the execution times of RTL power estimation (using PowerTheater and NEC's RTL power estimator) with the time required to perform power emulation, for several benchmark designs. The largest design, MPEG4, is an MPEG4 decoder used in mobile handset applications. We also report results for the following sub-designs of MPEG4: IDCT (Inverse Discrete Cosine Transform), Ispq (inverse quantization block), and V ld (variable length decoder). Other designs include Bubble Sort (sorting circuit), HV PeakF (peaking image filter), and DCT (Discrete Cosine Transform). The three bars for each benchmark in the graph represent execution times for power estimation using NEC's RTL power estimator (NEC-RTpower), Pow-erTheater, and power emulation, respectively. The figure also plots the speedup for power emulation compared to the two RTL power estimation tools, with values ranging from 10X to over 500X. The above results clearly demonstrate that power emulation has a potential to enable efficient power estimation for large designs. We are presently investigating the challenges that arise in mapping power model enhanced circuits to FPGA prototyping platforms, primarily due to the capacity constraints of FPGA devices. For large designs, we believe that significant work remains to be done in addressing the area occupied by the power estimation hardware before this paradigm can be embodied in a practical methodology for power estimation.

Figure 1 :

 1 Figure 1: An example RTL circuit enhanced for power emulation

Figure 2 :

 2 Figure 2: Power emulation flow

Figure 3 :

 3 Figure 3: Execution time and speedup for power emulation over RTL power estimationThe above results clearly demonstrate that power emulation has a potential to enable efficient power estimation for large designs. We are presently investigating the challenges that arise in mapping power model enhanced circuits to FPGA prototyping platforms, primarily due to the capacity constraints of FPGA devices. For large designs, we believe that significant work remains to be done in addressing the area occupied by the power estimation hardware before this paradigm can be embodied in a practical methodology for power estimation.

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


Dr Horst Brinkmeyer
email: horst.brinkmeyer@ibb-kwh.de

Leibnizstr Ingenieurbüro Brinkmeyer

Kornwestheim

A New Approach to Component Testing

Carefully tested electric/electronic components are a requirement for effective hardware-in-the-loop tests and vehicle tests in automotive industry. A new method for definition and execution of component tests is described. The most important advantage of this method is independance from the test stand. It therefore offers the oppportunity to build up knowledge over a long period of time and the ability to share this knowledge with different partners.

Introduction

Complexity of electric/electronic systems in automotive environment has increased significantly in the last ten to fifteen years. The components are designed by engineers in supplier companies, but the layout of the entire electric/electronic system is done by the car manufacturers themselves. This job has become more difficult because of the increasing complexity, reduced development time and reduced budgets. So effectivity and reliability are very important topics in this field of engineering. According to the V-modell the task consists of layout and testing of the entire electric/electronic system. In this paper only testing will be observed.

For the OEM testing normally consists of two stages: hardware-in-the-loop tests (HIL) and tests within the vehicle itself.

Either of these test methods is extremly costly and the goal is to find out, weather there are difficulties in the interaction of the components that haven't been forseen during design and weather there are unexpected conditions in the entire system. Important for effective engineering in this field are components that behave according to their requirements. As the component tests normally are executed by the supplier, the OEM has to rely on this; but the task for the supplier often is difficult as well: The written requirements for the components are nomally incomplete and the knowledge of the supplier about possible difficulties may be incomplete as well, if the developpement of similar components has been carried out by other suppliers. In this situation OEM and supplier are in danger to repeat mistakes and therefore the components delivered for HIL tests and vehicle tests may not have the expected quality. As a result of this, time and money is lost or, even worse, the quality of the car affected.

To avoid this, a method is needed, to preserve the knowledge about requirements of components, including bugs, that have occured in the past. On one hand there is of course the specification of the component but the requirements also have to be tested. So there is a need for test cases that are specfied in a way, so that a high percentage of them can be reused in order to perserve the experience for future projects. First of all a method is mentioned that is used to apply the status. For example the status "Lo" or "Ho", defining high or low voltage at a pin, is carried out by the the method "get_u". This method mesasures the voltage at the specified signal pin and compares it to the limits. For example the status "Ho" is valid, if the measured voltage is between 0,7*Ubatt and 1,1*Ubatt, where Ubatt is the supply voltage of the DUT.

Requirements for component tests

The tests defined by this type of Excel sheets now have to be transformed to a form that can be interprted easily by a test stand. As file type we have chosen the xml-Format. Besides header, step numbers etc. the most important content of this file is given by many signal statements, each of them followed by a method statement. For example the following code represents checking of the "Ho"-status for the signal INT_ILL:

<signal name="int_ill"> <get_u u_max="(1.1*ubatt)" u_min="(0.7*ubatt)" /> </signal>

Execution of component tests

The generated xml-File (test script) can be used for test execution at test stands equipped with the affiliated interpreter. Besides the test script, the test stand needs information about its own ressources and in which way these ressources can be connected to the DUT. Ressources in this context are described by the methods that are supported by them and the valid range for all parameters.

In our example there are three resources, one DVM and two resistor decades, that can be connected to the DUT. The DVM supports the method "get_u", the resistor decades the method "put_r". For each method to be carried out, the test stand searches an approriate ressource, that can be connected to the signal pin. If this is not possible an error message is generated.

Status of the project

The described method for component testing was developed for DaimlerChrysler and successfully applied to two ECUs of the next S-class. At the moment different projects are carried out for suppliers.

The tool for test definition must be easy to use The test definitions must be easy to read A tool is needed for automatic generation of code, that can be interpreted by any test stand Interpreters for the generated code are needed for those test stands, that are going to be used for component tests 3. The tool chain for definition of component tests

  The tests themselves are defined in test definition sheets. In each test only a certain part of the specification is testet; according to this part of the specification, only those signals are mentioned in this sheet that describe the behaviour of the DUT under this point of view. For each test step status are assigned to one or more signals.

									Status
	assigned to signals describe either the stimulus to be
	applied to an input signal or an expected output or output
	range in the case of output signals. The following table
	shows a simple example:
	test step	t	IGN_ST	DS_FL	DS_FR	NIGHT	INT_ILL	remarks
	0 0,5 Off Closed Closed 0 Lo day: no interior
	1 0,5		Open		Lo illumination, if
	2 0,5		Closed Open	Lo doors are open
	3 0,5			Closed	Lo
	4 0,5		Open	1 Ho night: interior
	5 0,5		Closed		Lo illumination on,
	6 0,5			Open	Ho if doors are open
	7 280					Ho
	8 25					Lo illumination
	9 0,5			Closed	Lo off after 300s
	The behaviour of the signal INT_ILL (interiour
	illumination) is described as a function of the signals
	IGN_ST (ignition status), DS_FL (door switch front left),
	DS_FR (door switch front right) and the bit NIGHT,
	comming from a light sensor. If the bit NIGHT is active,
	the interior illumination is lit for a maximum duration of
	300s, if one of the doors is open, what is indicated by an
	"Open" status of the door switch.
	status method attribut var (x) nom min max D 1 D 2 D 3
	Off put_can data	0001B
	Open put_r	r		0		0,5	1	2
	Closed put_r	r		INF		INF 5000 5000
	0	put_can data		0B
	1	put_can data		1B
	Lo	get_u	u	UBATT	0	0	0,3
	Ho	get_u	u	UBATT	1	0,7 1,1

Component tests today normally are defined in a specific test environment i.e. for a determinated test hard-and software. In this case knowledge between the OEM and the supplier can only be transferred, if both of them define component tests in the same environment. In most cases the OEM doesn't define component tests at all and so knowledge about test cases is lost from one project to another. In order to change this situation, the following requirements for component tests are derived:

Component tests have to be independent from the test environment

This means, stimuli and expected outputs for the device unter test have to be defined only according to the requirements of the component itself and not according to the properties of the test stand. A lot different tools exist for definition of tests; usage of most of them normally is limited to especially qualified and trained personell. In order to allow usage of the tool chain to all involved engineers without specific training, we choose Excel as input tool for the test definition. Three different types of Excel sheets are used to describe the test sequence: Signal definition sheet Test definition sheet Status definition sheet In the signal definition sheet all input and output signals of the device under test (DUT) are definied as well as the status of these signals before starting the test itself.

The expressions Off, Open, Closed, 0, 1, Lo and Ho are status, which are defined in the so called status table. The status table for the example may look like this: Each status used in the signal table or test table is defined in the status table.

  The following tables show the representation of this test circuit for the test stand:

	Ress. Method Attribut Min	Max	Unit
	Ress1	get_u	u	-60	60	V
	Ress2	get_r	r	0	1,00E+06
	Ress3	get_r	r	0	2,00E+05
		INT_ILL_F INT_ILL_R DS_FL DS_FR DS_RL DS_RR
	Ress1	Sw1.1	Sw1.2
	Ress2			Mx1.2 Mx2.2 Mx3.2 Mx4.2
	Ress3			Mx1.1 Mx2.1 Mx3.1 Mx4.1

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


Joachim Langenwalter
email: jlangenwalter@mathworks.com

Embedded Automotive System Development Process Steer-By-Wire System

Model based design enables the automatic generation of final-build software from models for high-volume automotive embedded systems. This paper presents a framework of processes, methods and tools for the design of automotive embedded systems. A steer-bywire system serves as an example.

Process

Model-based design supports the needs of controls/DSP systems engineers and software developers by providing a common environment for graphical specification and analysis. In this process, models are made and used to specify system data, interfaces, feedback control logic, discrete/state logic, and real-time behavior.

A common way to view a software process is through use of the V diagram. The diagram corresponds to most engineering processes, however, the process is iterative with many repetitive steps throughout the development life cycle.

Behavioral Modeling

Models are used for specifying requirements and design for all aspects of every individual subsystem (e.g. steer-by-wire in Figure 1 and 2).

A typical system includes: Inputs (e.g., steering wheel sensors) Controller or DSP Model Plant Model (DC motor, rack and pinion, wheels ) Outputs (change of direction)

As shown, a system model can be created to represent the desired behavior using control system block diagrams for feedback control, state machines for discrete events and conditional logic, and DSP blocks for filters.

Simulation and Analysis

The model is executed and analyzed to ensure that the requirements are satisfied, using methods such as time-or event-based simulation and frequency domain analysis.

Rapid Prototyping

Due to inaccurate plant models and insufficient processing power rapid prototyping is highly useful because it replaces the plant model with the physical plant.

Detailed Software Design

With model-based design, the same model used for algorithm specification and validation is refined and constrained by the software engineers as part of the production code generation process.

Model Testing

It is more beneficial to test the model on a desktop rather than deploy it on hardware for build and integration. Source code-based testing has existed for many years, but recent methods now allow for model testing and structural coverage.

Integral Components

Most software standards require traceability of requirements, perhaps originating in other requirements tools, throughout development.

Conclusion

Major software evolutions occur when the full software engineering process activities are supported. Improving bits and pieces alone is insufficient.

[1] "Software considerations in airborne systems and equipment certification," RTCA/DO-178B, RTCA Inc., Dec. 1992

  Model-based design methods are employed during the software engineering process.

Figure

  Figure 1: Steer-By-Wire system

Figure 3 :

 3 Figure 3: Coverage for power management design in Fig. 3 Production Code Generation Now that the model has been verified and validated, it is time to generate code automatically from the model.Hardware-In-the-Loop TestingOnce the controller has been built, a series of open-and closed-loop tests can be performed with the real-time plant model in the loop.

  [2] Dr. Michael von der Beeck, ARTIST Industrial Seminar, Paris, 23.4.2002 [3] Paul Yih, Jihan Ryu, J. Christian Gerdes, Modification of Vehicle Handling Characteristics via Steer-by-Wire, Dept. of Mechanical Engineering, Stanford University

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


Ali Habibi
email: habibi@ece.concordia.ca

Sofiène Tahar
email: tahar@ece.concordia.ca

Design for Verification of SystemC Transaction Level Models

Transaction level modeling allows exploring several SoC design architectures leading to better performance and easier verification of the final product. In this paper, we present an approach to design and verify SystemC models at the transaction level. We integrate the verification as part of the design-flow. In the proposed approach, we first model both the design and the properties (written in PSL) in UML. Then, we translate them into an intermediate format modeled with Abstract State Machines (ASM). The ASM model is used to generate an FSM of the design including the properties. Checking the correctness of the properties is performed on-the-fly while generating the state machine. Finally, we translate the verified design to SystemC and map the properties to a set of assertions (as monitors in C#) that can be re-used to validate the design at lower levels through simulation. We illustrate our approach on two case studies including the PCI bus standard and a generic Master/Slave architecture from the Sys-temC library.

Introduction

SystemC [START_REF]Open SystemC Initiative[END_REF] is a relatively new system level language proposed to overcome the problem of the growth in complexity and size of systems combining different types of components. SystemC meets the need for a system level language that can fill the gap between hardware description languages (HDLs) and traditional software programming languages. For that reason, it is more important to focus on defining methodologies and techniques for SystemC transactional models a finite set of architecture components (memories, CPUs, etc) communicate among each other over shared resources (buses).

Until recently, modeling architectures required pin-level hardware descriptions, typically RTL level. Great effort is required to design and verify the models, and simulation at this level of detail is tediously slow. Transaction level modeling is eventually the best solution. In addition to the design's approach issue, the verification of a SystemC model is a serious bottleneck in the design cycle. Going further in complexity and considering hardware/software systems will be out of the range of nowadays used simulation based techniques.

In conventional HDL designs, defining the system's properties and specification is itself a problem. In order to provide an efficient language to write assertions and properties, the Accellera organization proposed the Property Specification Language (PSL) [START_REF] Tahar | Accellera Property Specification Language reference manual[END_REF], which addresses the lack of information about properties and design characteristics. Nevertheless, defining the language itself is not enough to improve both the design and verification flows.

In this paper, we first provide a methodology to design Sys-temC transactional models starting from the UML level where a more precise specification of the system and its properties are defined. We used a modified sequence diagram representation to capture more precise properties description. The UML model is then mapped to an Abstract State Machines (ASM), a formal specification method for software and hardware systems that has become successful for specifying and verifying complex systems. ASMs provide features to capture the behavioral semantics of programming and modeling languages where large systems are modeled on a high level of abstraction allowing easier validation and verification operations. We considered AsmL language [START_REF]AsmL for Microsoft .NET Framework[END_REF] which was developed at Microsoft because: (1) it effectively supports specification and rapid prototyping of different kinds of models;

(2) it includes a tester that can be used to generate finite state machines (FSMs) and test cases.

To enable the integration of both the model and the properties at the ASM level, we embedded the PSL semantics in ASM. At this level, it is possible to verify these properties using model checking. For instance, we encode the property's evaluation in every state which enables evaluating its correctness on-the-fly while executing the FSM generation algorithm (part of the AsmL tool). An incorrect property detection stops the reachability algorithms and outputs a sub-portion from the complete FSM which represents a complete scenario for a counter-example. Eventually, not all the properties can be verified due to the state explosion problem. For this reason, we complement our verification methodology by integrating the properties as assertion monitors in the final SystemC design. We compile the PSL property (in ASM) to a C# while the SystemC model (in ASM) is translated SystemC. Both codes are then combined to form a single model enabling the verification of the assertions by simulation.

The rest of this paper is organized as follows: Section II presents the proposed design methodology. Section III discusses the proposed verification approach. Section IV illustrates our approach on two bus structure case studies. Finally, Section V discusses the related work and concludes the paper.

Design Methodology

Our design methodology, as displayed in Figure 1, includes two parallel paths concerning the design and its properties. We model the design in the classical way a C++ design is modeled using UML (i.e., using use cases, class diagrams, etc.) Then, we translate the UML model to ASM in order to perform model checking of certain properties. These latter are extracted from the UML sequence diagram and encoded in the PSL syntax. The verification process ends to: (1) a completion either with a success or failure of the property; or (2) a state explosion. The UML update and UML to ASM translation tasks are repeated until all the properties passes with success either succeeds or do not complete. Then, we compile the PSL properties into a set of C# classes, using the AsmL tool to be used as assertion monitors. The design in ASM is, from the other side, translated to C++ (SystemC model) and co-integrated with the assertions for verification by simulation.

UML Level

Use

Modeling PSL Properties

PSL is an implementation independent language to define properties. PSL is a hierarchical language, where every layer is built on top of the layer below. This approach allows the expressing of complex properties from simple primitives.

UML Model

Using UML as a high level of abstraction for design showed a lot of success when applied to Software. Main proposals consider either to use UML as new system level design [START_REF] Damasevicius | Application of uml for hardware design based on design process model[END_REF] or as top layer in combination with existent languages (such as SystemC) [START_REF] Schulz-Key | Object-oriented modeling and synthesis of SystemC specifications[END_REF]. Nevertheless, these proposals neglected totally considering the properties of the system (PSL like properties in particular) while sequence diagrams for example includes very useful information to set transaction properties for TLM in particular.

Unfortunately, sequence diagrams do not allow a direct mapping to PSL due to two reasons: (1) the complexity of the PSL property which may include temporal operators; and (2) the need for instantiation in the PSL. In fact, PSL was defined for a real instances from the design formed from objects while the sequence diagram considers only classes. For these facts, UML will not present completely and precisely all PSL property. However, it can be used to provide a general skeleton of the property that could be refined and instantiated at the ASM level.

In order to make the UML sequence diagram more adequate for PSL representation, we introduced the following operators: Clocks: we use the operator to specify the clock that activates the current action (if there exist one). Number of cycles: every action can be include the information about after how many cycles the method is start executing (for e.g., Mtd [START_REF] Gordon | Introduction to HOL: A Theorem Proving Environment for Higher-Order Logic[END_REF]() says that the method Mtd is executed for exactly 5 consecutive cycles). Temporal operators: these includes operators specifying if the method will be always executed (A), eventually executed (E ), executed Until a condition is fulfilled (U ), etc. These, in fact, represent a mapping to the PSL temporal operators (second layer of PSL). Sequence operations: includes information about the order of executing certain sequences (for e.g., next, prev etc.) Text output: refers to a message that is displayed in case the method fails. This is included in PSL to track the progress of the assertion based verification. Method duration: certain methods are supposed to execute for a certain number of cycles (for e.g., reading for memory may take 4 cycles). So, we added an operator $ to specify such an information. Figure 2 gives an example of a sequence diagram describing a PSL property saying that if a bus sends a new request, then in the next cycle the arbiter will be notified and will make the arbitration. In the third cycle, the Master starts sending. The bus is released in the 4 cycle and a notification will be sent, eventually, by the slave to the bus who will forward it in the next cycle to the Master. When mapping to ASM the UML sequence diagram needs to be instantiated according to the design objects. For instance we need to specify, for example, that the notification must be to the original master and not to all the masters. [START_REF] Gurevich | Evolving Algebras 1993: Lipari Guide[END_REF] is a formal specification method for software and hardware systems that has become successful for specifying and verifying complex systems. There are many languages that have been developed for ASMs, the recent one is AsmL [START_REF]AsmL for Microsoft .NET Framework[END_REF] which was developed at Microsoft. The AsmL tester can also be used to generate finite state machines (FSMs) and test cases. We notice that AsmL is language that supports object-oriented modeling at higher level of abstraction in comparison to C++ and Java. So, it is not a graphical representation but a programming language that can be used to describe system models either as abstract state machines or programming models.

ASM Model Abstract State Machines (ASM)

There are two ways to embed PSL properties into the design, either into the design code itself or by adding them as external monitors. We adopted the first approach, where all the parameters of PSL properties are defined as objects. The objective of the embedding is to reuse PSL properties, as embedded in ASM, at lower design levels since the AsmL tool can automatically compile them into a C# or .NET code, which can be compiled and executed with the concrete SystemC level or as a stand-alone module.

PSL properties are defined in a hierarchical way inspired from the hardware design modular concept. For this reason we defined the embedding in a similar structure, where all the components are defined as objects and every PSL layer extends its lower layer using the inheritance feature of AsmL.

Boolean Layer:

This layer is the basic layer of PSL. Even though it is called Boolean layer, it includes types other than Boolean such as integers and bit vectors. We embedded this layer in ASM by defining classes for all types and expressions including their methods. Our embedding is based on the semi-formal semantics presented in the reference manual [START_REF] Tahar | Accellera Property Specification Language reference manual[END_REF], and the formal semantics definition in HOL [START_REF] Gordon | Validating the psl/sugar semantics using automated reasoning[END_REF].

The embedding of the PSL Boolean layer mainly includes: (2) PSL Expressions includes constructing properties using the implication and equivalence operators.

(3) PSL Built Functions include all the functions defined by PSL to operate at the Boolean layer. We distinguish here two methods: a method that provides the previous values of a variable (e.g., prev()) and a method that provides the future values of a variable (e.g., next()).

Temporal Layer:

The most important part of this layer is the SERE feature, which embedding mainly includes:

(1) Sequential Expressions, where a SERE is defined as an AsmL sequence of Boolean. It offers several operations to construct, manipulate and evaluate the SERE expression. (2) Properties including the operations necessary to create properties from sequential expressions. It also controls when and how the sequence is to be verified (i.e., the property "verify the sequence is true after n states" is defined as PSL Property.EvaluateNext(n)).

Figure 3 shows the example of the PSL SERE.Evaluate(), which checks if a sequence is true in a certain path. This method is activated according to an INIT signal that must be set by the property. Verification Layer: This layer is intended to tell the verification tool how to perform the verification process. It allows to construct assertions from properties and to specify relations between them. The embedding mainly includes:

(1) Verification Directives to specify how the property will be interpreted (assertion, requirement, restriction or assumption). This class extends the PSL Property class from the temporal layer.

(2) Verification Unit is a compact way to include several properties together. The embedded class includes several operations to add/remove and update the unit's list of properties.

Modeling Layer:

This layer is not used in our verification approach since it is intended for VHDL and Verilog flavors of PSL. So we did not consider it in our embedding.

Modeling SystemC

SystemC is built on standard C++. The core language consists of an event-driven simulator as the base. It works with events and processes. The other core language elements consist of modules and ports for representing structures. Interfaces and channels are used to describe communications. SystemC provides data-types for hardware modelling and certain types of software programming as well.

ASM Model

The design model at the ASM level is purely object-oriented where every class includes a set of parameters and methods. The particularity of this model resides in the fact that it will be used to generate an FSM using the reachability algorithm embedded AsmL tool. So, a specific style of programming is required in addition to a precise configuration of the algorithm. Before going further into the details of the ASM model, we will discuss the FSM generation algorithm which will give a better idea about the requirements of the ASM model.

The FSM generation algorithm requires as input: domains, methods, actions and variables (optional inputs are filters, action groups and properties). The transitions in the FSM are the method calls (including argument values) in the test sequences. The methods in the model program that appear in the transitions are called actions. The states in the FSM are determined by the values of selected variables in the model program, called state variables. The algorithm generates the FSM by executing the model program in a special execution environment, keeping track of the actions it performs and recording the states it visits. This process is called exploration. Usually a model program implies so many states and transitions that it is not feasible to include them all in the FSM, so it is a must to limit the number of states and transitions that the tool explores.

The final FSM will, according to the algorithm's configuarion options, represent only a portion -an under-approximation -of the huge FSM that would result if the model program could be explored completely. Critical information to ensure the correctness of certain properties concerning identifying the actions and state variables in the FSM. Domains, finite collections of values from which method arguments are taken, are defined in order enable better coverage on particular issues. Filters express stopping conditions that limit exploration (used to stop the FSM generation if a property fails, for e.g.).

For a model M including a set of classes, C = {c1, . . . , cn}, where n is the total number of classes in M . For every class ci in C, we denote its set of methods by c mth i and the set of members by c mem i . We defined a set of rules (called RFSM ) to guarantee the generation of an FSM representing a portion of the complete system's FSM; these include: Rule R 1 F SM : For every class ci in C, we have to define a list of instantiations of the class. This ensures that the algorithm will not through an exception. Rule R 2 F SM : The firstly executed method in the design must verify that all the objects from the class domains were correctly instantiated. This ensures that the algorithm will not misbehave. Rule R 3 F SM : For every class ci in C, every method in c mem i must include a list of pre-conditions to specify when the algorithm considers this method in the exploration process. This ensues that in every state we only explore the involved methods. Rule R 4 F SM : For every class ci in C, domains for all members in c mem i must be inherited from AsmL types and restricted to the possible values the system can accept (in particular for inputs). This will allow exploring known types and limits the risks of state explosion.

The optimal scenario is to explore all the methods and domains in the model; nevertheless, this is not possible all the time due to the state space explosion. For this reason, working carefully the domains and the set of actions is the very critical path in the FSM generation process. For illustration purpose, Figure 4 shows a generic ASM model with a method including a precondition (denoted by the require keyword) setting that the method needs the system to be initialized (SystemInit = true) and that it has both variables m gnt and m req set to false before it can be executed. Such a conditions define strictly at which state the system can execute a particular set actions.

Translation to C++

Once the ASM model verified using the properties describing its behaviour, we translate it to SystemC according to a set of rules to ensure that the final Sys-temC model preserves the original ASM code properties. The transformation is purely syntactical, it is performed to certain rules (that we call RC++) that could be summarized in the following: Rule R 1 C++ : "Basic types": ASM basic types are all mapped to their equivalent SystemC types (e.g. Integer to int, Byte to un- signed char, etc.). AsmL includes the same types as C++ which are used for SystemC also. Rule R 2 C++ : "Class Translation": this includes two separate rules for variables and methods: Rule R 2.1 C++ : "Class Members": are translated into SystemC signals having the same basic type. For e.g., var m val as Integer is translated to sc signal<int> m val. Rule R 2.2 C++ : "Class Methods": in ASM contain two parts first one defining the post-/pre-conditions for its execution and the method itself. The first part is integrated in the SystemC module's constructor. For instance, a method Send defined in ASM with the following pre-condition require clk=true is inserted in the SystemC module constructor area as "SC THREAD(Send); sensitive << clk;". The method itself is integrated as it is in the Sys-temC module (we just modify the basic types according to the Rule 1). Rule R 3 C++ : "Global Modules": are integrated in the SystemC's main procedure sc main. The naming mapping is used to link different modules together.

Verification Methodology

The verification process is decomposed into two parts: (1) by model checking at the ASM level; and (2) by assertion based verification at the C++/C# level.

Model Checking

PSL properties are embedded in ASM as assertions, the assertion here means the validity of the property. It provides a unique view of the property in every system's state. It also simulates the design with the property as a monitor. We build the assertion starting from basic Boolean components, sequences, and then verification units. We encapsulate sequences in the verification unit as an assertion which is embedded in the design. Given a set of Boolean items x1, x2, . . . , xn, and y1, y2, . . . , ym belonging to the Boolean layer, and the sequences, S1 and S2 belonging to the temporal layer, we can define: S1 = {x1, x2, . . . , xn}, and S2 = {y1, y2, . . . , ym} and then use assertions to check any PSL operation between S1 and S2 such as S1 OP S2, where OP is a PSL operator (e.g., implication (⇒), or equivalence (⇔)). The assertion is built as follows:

1. Add all the Boolean items to the sequences:

∀ i in 1 to n : S1.AddElement(xi) ∀ j in 1 to m : S2.AddElement(yi)
2. Create the property: P := S1 OP S2 3. Define the verification unit as an assertion, say A, that includes the above property: A.Add(P ) This property is embedded in every state in the FSM generated by the AsmL tool and is represented by two Boolean state variables P eval and P value (saying, respectively, if the property can be evaluated and the value of the property in the current state). A violated property is detected once P eval = true and P value = false. We set the previous condition as filter for the FSM generation algorithm. This way the generation stops when an error is detected. The generated portion of the state machine, at this point, can be used to identify the problem through a scenario of a counter-example. For multiple properties, the filter is set as conjunction of all the conditions for the separate properties. This technique minimizes radically the number of the state variables (the FSM size and its generation time). A correct verification process results on the generation of the system's FSM (according the configuration file constraints).

Assertion Based Verification

We target to add the assertion as an external monitor to the SystemC design. We consider three steps:

(1) Updating the SystemC design to interface to the assertion.

(2) Generating the assertion (in C#) from its ASM description.

(3) Integrating the assertion in the design.

The translation to C# of the PSL assertions embedded in ASM is a matter of compilation using the AsmL tool. Most of the effort is spent in updating the SystemC design to get it connected the assertion monitor. For instance, we validate the assertion syntactically by generating the list of its involved variables. Then, we perform a type check to make sure the variables are well instantiated in the SystemC design. For instance, the signals (variables) that are used in the assertion must be seen as external signals so that they can be input to the assertion monitor. So, modify the SystemC design to make the required variables visible to the monitor. This transformation does not affect the behavior of the code as it will only be accessed in a read-only mode.

Once the design is updated, we add the required instantiation of the assertion to bind it to the existing SystemC design modules. The assertion monitor, acting as part of the design, can do the following: (1) stop the simulation when the assertion is fired; (2) write a report about the assertion status and all its variables; and (3) send a warning signal to other modules (if required). We note that the internal code of the assertion is C# so the designer can update it or do any other functionalities that can be coded in C#.

Experimental Results

In order to illustrate the proposed design and verification methodology, we considered two models: (1) PCI (Peripheral Component Interconnect) [START_REF]PCI Special Interest Group[END_REF] Local Bus standard; and (2) an extension of the Master/Slave Bus structure provided by the Sys-temC distribution [START_REF]Open SystemC Initiative[END_REF]. Both models include ceratin properties, such as liveness, that cannot be verified using simulation which requires using formal verification techniques such as model checking. Moreover, we aim evaluating the performance of the overall approach according to the system's size, which can be per- formed by varying the number of masters and slaves. The experiments were conducted on a Pentium IV processor (2.4 GHz) with 512 MB of memory.

Models Description

PCI boasts a 32-bit data path, 33MHz clock speed and a maximum data transfer rate of 132MB/sec. Each PCI master has a pair of arbitration lines that connect it directly to the PCI bus arbiter. In the PCI environment, bus arbitration can take place while another master is still in control of the bus. Data is transferred between an initiator which is the bus master, and a target, which is the bus slave. PCI supports several masters and slaves and allows stopping transactions.

The SystemC Master/Slave bus represents a more generic bus structure including a set of Masters, a set of slaves an arbiter and a shared bus. The arbiter is responsible for choosing the appropriate master when there is more than one connected to the bus. There are two possible modes for the bus: (1) Blocking Mode, where data is moved through the bus in a burst-mode; and (2) Non-Blocking Mode, where the master reads or writes a single data word.

Model Checking

For model checking we considers, for both models, a set of properties describing all the possible scenarios of transactions over the bus (reading, writing, arbitration, etc.). The machine time (user time) needed for verifying the properties depends on the complexity of the original model as well as the property parameters. The time CPU required for the model checking of the properties of the PCI bus for different numbers of masters and slaves is given in Table 1. We note that the numbers of states and transitions increase exponentially as a function of the number of masters and slaves connected to the bus which explains the need for a sharp definition of the exploration domains and active actions. Similar results for the generic Master/Slave case study are given in Table 2, where, for Masters, "B" refers to Blocking and "NB" to Non-Blocking.

Assertion Based Verification

The last column in Table 1 shows a simulation evaluation of the PCI bus when implemented in SystemC including the assertions monitors. We display the average execution time per clock cycle (called δ and given in ns) as a function of the number of masters and slaves connected to the bus. This shows a very short time (few seconds) to simulate million of cycles which offers good coverage for the assertions. In this case also, we obtained similar results for the generic Master/Slave model as shown in the last column of the Table 2.

Conclusion and Related Work

In this paper, we presented a methodology to design and verify SystemC transactional models starting from a UML system specification and integrating an intermediate ASM layer. We proposed to upgrade the UML sequence diagram in order to capture transaction related system properties. Then both of the design at its properties are modeled in ASM to enable performing model checking. On the other hand, to cover for the state explosion problem that may result due to the system's complexity, we completed our approach by offering a methodology to apply assertion based verification re-using the already defined PSL properties. To do so, we defined a set of translation rules to transform the design's model in ASM to its implementation in SystemC. Experimental results showed good model checking results even for complex systems such as the PCI bus standard. The final Sys-temC models also were running a quite fast simulation enabling to offer better coverage for the whole system state space.

In [START_REF] Gordon | Validating the psl/sugar semantics using automated reasoning[END_REF], Gordon used the semi-formal semantics in the PSL/Sugar documentation to create a deep embedding of the whole language in the HOL theorem prover [START_REF] Gordon | Introduction to HOL: A Theorem Proving Environment for Higher-Order Logic[END_REF]. The author de-scribed how to 'execute' the formal semantics of PSL using HOL to see if it is feasible to implement useful tools that work directly from the formal semantics by mechanized proof. However, he did not provide any framework for the verification of PSL for any implementation language. Besides, they do not offer any approach to re-use the PSL properties as assertion (a very important feature in PSL).

Gawanmeh et. al. [START_REF] Gawanmeh | Enabling SystemC Verification using Abstract State Machines[END_REF] completed the work of Müller et. al. [START_REF] Müller | SystemC Methodologies and Applications[END_REF] to define the semantics of SystemC 2.0 using ASM. However, that semantics could not be used directly to generate the finite state of the system because it does not satisfy to the rules we defined in Section 2.2.1. Besides, embedding the complete SystemC simulator semantics is ASM represent a huge overhead to the FSM generation.

Several proposals for system level design, in particular [START_REF] Schulz-Key | Object-oriented modeling and synthesis of SystemC specifications[END_REF] and [START_REF] Sinha | Yaml: a tool for hardware design visualization and capture[END_REF], used a combination of UML and SystemC for SoC design in general (TLM in particular). We are not aware of any other work that considered ASM as an intermediate layer between UML and SystemC to enable model checking. Besides, we focused into extracting and defining the system properties at the early design stages (from the UML sequence diagram) which makes our work complementary to existent approaches by offering and in-design verification solution.

Figure 2 .

 2 Figure 2. Example of a Modified UML Sequence diagram.

( 1 )

 1 Expression type class includes the basic 5 types: Boolean, PSLBit, PSLBitVector, Numeric and String. Both Boolean and String types are directly inherited from the ASM's AsmL.Boolean and AsmL.String, respectively.

Figure 3 .

 3 Figure 3. Embedding PSL SERE in ASM.

Figure 4 .

 4 Figure 4. An Example of an ASM Model.

. Design and Verification Methodology.

			SystemC Design	PSL Properties
			Case	Updates Sequence
			Class Diagram	Diagram
	ASM Level	Properties fails	Sequence Diagram SystemC Model in ASM	PSL Properties modeled in ASM Mapping
			AsmL Tool
	C++/C# Level	Translation	Compilation
			SystemC modeled	PSL Properties modeled
			in C++	in C#
	Figure 1

Table 1 . PCI Bus: Model Checking and Simulation Re- sults.

 1

	Number	Model Checking	Simula-
	of		CPU	Number of FSM	-tion
	Mas. Sla.	Time (s) Nodes Trans.	δ (ns)
	1	1	2.31	20	25	24.31
	1	2	2.93	39	53	29.32
	3	1	26.01	236	341	29.76
	2	2	26.84	293	449	30.89
	2	3	101.37	658	1117	32.74
	3	2	574.18	1881	3153	34.03
	3	3	6836.01	6346	12097	36.82

Table 2 . Master/Slave Bus: Model Checking and Simula- tion Results.

 2

	Number of	Model Checking	Simula-
	Sla.	Mast.	CPU	Num. of FSM	-tion
		B NB	Time(s) Nod. Tran.	δ(ns)
	2	1	1	3.54	14	22	27.04
	2	3	3	142.32	146	531	31.44
	2	3	4	402.32	276	1174	33.02
	2	4	4	1192.57	530	2584	35.41
	3	1	1	4.32	15	27	28.01
	3	3	3	186.64	147	723	36.85
	3	3	4	518.73	278	1622	38.82
	3	4	4	1541.32	535	3606	40.08
	4	1	1	5.21	17	31	29.92
	4	3	3	214.46	148	915	39.41
	4	3	4	630.48	280	2070	41.11
	4	4	4	2002.54	538	4630	43.25

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

Proceedings of the Design, Automation and Test in Europe Conference and Exhibition (DATE'05)


Wolfgang Klingauf
email: klingauf@eis.cs.tu-bs.de

Systematic Transaction Level Modeling of Embedded Systems with SystemC

This paper gives an overview of a transaction level modeling (TLM) design flow for straightforward embedded system design with SystemC. The goal is to systematically develop both application-specific HW and SW components of an embedded system using the TLM approach, thus allowing for fast communication architecture exploration, rapid prototyping and early embedded SW development. To this end, we specify the lightweight transaction-based communication protocol SHIP and present a methodology for automatic mapping of the communication part of a system to a given architecture, including HW/SW interfaces.

Introduction

Recently, the transaction level modeling (TLM) paradigm has been widely propagated for System-on-Chip (SoC) design. By orthogonalizing system functionality and system communication, very high simulation speeds become feasible enabling fast communication architecture exploration [START_REF] Pasricha | Extending the Transaction Level Modeling Approach for Fast Communication Architecture Exploration[END_REF].

In contrast to SoC modeling, the design of embedded systems typically incorporates the assembly of standard HW and SW components with user-designed HW (reconfigurable logic or ASIC) and SW. As system complexity continuously rises, the proper connection of user HW and SW to the systems communication architecture becomes more and more a focus of design. As a result, the development of embedded software (eSW) that is closely related to the HW will have to wait for the RTL model to be completed.

To fill this gap, we present a TLM approach for embedded system design with SystemC that considerably relieves the designer of the task of implementing platform-specific communication protocols. Moreover, fast communication architecture exploration, early eSW development, and rapid prototype generation is supported.

The proposed design flow is displayed in figure 1. It specifies three TLM models, namely component-assembly model (defined in [START_REF] Cai | Transaction Level Modeling: An Overview[END_REF]), cycle count accurate at the boundaries model (CCATB, introduced in [START_REF] Pasricha | Extending the Transaction Level Modeling Approach for Fast Communication Architecture Exploration[END_REF]), and communication architecture model (adapted from cycle-accurate computation model in [START_REF] Cai | Transaction Level Modeling: An Overview[END_REF]).

Figure 1. Design flow

To encourage highly systematic development, each model is clearly associated with a predetermined communication protocol. For communication modeling in the upper two TLM models, we introduce the SystemC High-level Interface Protocol (SHIP). Below the CCATB model, the widely supported and openly-licensed Open Core Protocol (OCP) [START_REF]OCP-IP home page[END_REF] is used. By specifying a generic SHIP-based HW/SW interface, fully transaction-based HW/SW communication in the final system is rendered possible.

SHIP

SHIP is a lightweight communication protocol for transaction-based modeling of directed point-to-point connections between two communication entities such as processing elements (PE) or communication architecture accessors. SHIP was designed to allow for top-down communication modeling on a level of abstraction that is completely independent of the HW/SW partitioning.

The SHIP channel is a message passing channel which transfers any C++ object that implements the ship serializable if interface. This interface defines the serialize and the deserialize function. The channel calls these functions to transform communication objects into serial data streams and vice versa.

The SHIP channel offers four blocking interface method calls: send, recv, request, and reply. While PEs that exclusively use the send and request functions implicitly represent a communication master, recv and reply are slave methods. When consequently applied, this allows for automatic master/slave detection.

Communication architecture exploration and prototyping

In the following, we briefly describe our concept of fast communication architecture exploration and prototyping. It is based on communication architecture models (CAM) and accessors.

Communication architecture model. With this term, we denote a simulation model of a communication architecture such as a bus or a network. CAMs are CCATB models with a cycle-accurate notion of time when viewed at transaction boundaries. Internally, only timed method calls are used which reflect the simulated bus or network protocol. Given a library of CAMs (e.g. of the CoreConnect architecture), fast yet timing-accurate communication architecture exploration is feasible.

It should be noted that the CAMs can be utilized in all abstraction models below the component-assembly model. They are connected to the systems PEs using OCP TLM interfaces. By the use of wrappers, virtually any PE can be connected to the CAM, independent of its communication interface. In our approach, wrappers for high-level SHIP and pin-accurate OCP interfaces are provided.

Communication architecture accessors. They are intended for the automatic generation of a synthesizable prototype of the hardware part. Their use implies that the designer has refined all PEs to the RTL level and has implemented a pin-level OCP interface. Then, to connect a PE to a selected target communication architecture (e.g. Core-Connect), the appropriate accessor is attached to the PE. Since accessors are implemented as RTL, they are fully synthesizable.

SW synthesis and HW/SW communication

The ultimate goal of the proposed design methodology is to use SystemC as a unifying system specification language and, after HW/SW partitioning, to generate eSW automatically from the SystemC code. Moreover, HW/SW communication should be established without requiring any changes to the source code. To this end, we adopt the methodology presented in [START_REF] Herrera | Systematic Embedded Software Generation from SystemC[END_REF]. Embedded SW can be systematically generated from SystemC code by simply substituting some SystemC library elements for behaviourally equivalent procedures based on RTOS functions.

However, this methodology does not include HW/SW interface generation. Hence, we define two constraints: First, eSW generation takes place in a transaction-level model of the system, namely the component-assembly model. Second, the PEs that are to become eSW exclusively must use SHIP channels for communication with other PEs of the system. PEs that fulfill these requirements can immediately be synthesized to eSW entities.

To enable fully transaction-based HW/SW communication, we specify a generic HW/SW interface supporting SHIP-based communication. This interface virtually realizes a SHIP channel with one end in the HW partition and one end in the SW partition of the system. Its implementation splits up into a HW and a SW adapter.

The HW adapter essentially features a pin-level OCP interface that allows for connecting to the systems communication architecture. Data exchange with the SW adapter is implemented by shared memory and sideband signals.

The SW part of the HW/SW interface consists of a device driver and a small communication library. While handshaking and memory-mapping is accomplished by the device driver, the communication library implements the SHIP channel interface method calls.

Conclusion

Currently, the design flow is being implemented for the IBM CoreConnect architecture and embedded Linux OS. A first case example will be demonstrated at the interactive presentation for which this paper is a base. Future research will include practical and theoretical analysis of limits and application areas of the methodology.

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