SPACE: SystemC Partitioning of Architectures for Co-design of real-time Embedded systems

Size: px

Start display at page:

Download "SPACE: SystemC Partitioning of Architectures for Co-design of real-time Embedded systems"

Angela Pearson
6 years ago
Views:

Maxime De Nanclas 1, Guy Bois 1 and Mostapha Aboulhamid 2 1.

1 September 29, 2004 SPACE: Partitioning of Architectures for Co-design of real-time Embedded systems Jérome Chevalier 1, Maxime De Nanclas 1, Guy Bois 1 and Mostapha Aboulhamid 2 1. École Polytechnique de Montréal 2. Université de Montréal MICRONET R&D 1

2 SPACE: Partitioning of Architectures for Co-design of real-time Embedded systems Agenda 1. Motivations 2. Objectives 3. Overview of SPACE 4. Levels of abstraction 5. Facilities of exploration through a API 6. Details of each level 7. SOCP as channel interface model 8. Results 9. Conclusion and future works Guy Bois, École Polytechnique de Montréal 2

3 1. Motivations The core language does not support thread priority assignment Its simulator does not offer all the necessary functionalities, such as preemption or scheduling by priority, generally present in any RTOS Then, soft real-time can be supported (i.e. missing a deadline does not cause serious damage) But hard real-time cannot be supported (i.e. missing a deadline may cause catastrophic consequences) Guy Bois, École Polytechnique de Montréal 3

4 2. Objectives To find Hw/Sw partitions that satisfies the specified real-time constraints, while minimizing hardware resources To offer at high level the main services of a realtime kernel of an RTOS To propose a Hw/Sw refinement methodology with specific verification issues at each level To be able to move user modules from hardware to software part (and vice versa) without the necessity of recoding from a Hw language to C/C++ (and vice versa) Guy Bois, École Polytechnique de Montréal 4

5 3. Overview of SPACE: 1 st step: functional validation SPACE stands for Partitioning of Architectures for Co-Design of Embedded systems Simulate the system in a purely functional form with a transactional model named U channel Check that the system s simulation respects the functional aspect of the specification Guy Bois, École Polytechnique de Montréal 5

6 3. Overview of SPACE: 2 nd step: partitioning stage s tested at functional level are taken without modifications They are placed in the software or hardware part of the architecture, based on the designer's best guess Simulated at transactional level Refinement through three levels of abstraction We iterate guided by the performance and cost metrics Guy Bois, École Polytechnique de Montréal 6

7 4. Levels of abstraction Functional validation Architectural exploration and H/S partitionning U L1 System design oriented U R T O S OS Sim U U L2 Partitioning oriented R T O S OS Sim L3 Under development R T O S ISS L4 Time oriented Sw R T O S ISS CA CA L5 Cycle Accurate SOFTWARE COMMUNI- CATION HARDWARE Guy Bois, École Polytechnique de Montréal 7

8 4. Levels of abstraction Functional validation Architectural exploration and H/S partitionning U R T O S R T O S R T O S OS Sim OS Sim ISS U U U At each level, we can easily move modules from Hw and Sw (and vice versa) and reevaluate our performance and cost metrics Sw R T O S ISS CA CA SOFTWARE COMMUNI- CATION HARDWARE Guy Bois, École Polytechnique de Montréal 8

9 5. Facilities of exploration through a API L1 Simulation L2 L3 L4 API API API RTOS RTOS RTOS Native Port and RTOS Simulation Port Simulation ISS Port Simulation with ISS Sw Levels API - Mapping between 2.0 and RTOS functions - Message queues for communication RTOS - Schedules modules - Priorities and preemptive scheduling Port - HAL - H/S communication : handler to catch messages from hardware - Provides RTOS task context switch and timer (connection or emulation) Guy Bois, École Polytechnique de Montréal 9

10 5. Facilities of exploration through a API API Initialisation Process SC_CTHREAD() OSTaskCreate () sc_start() OSStart () wait() OSTimeDly () sc_mutex.lock() OSMutexPend () sc_mutex.unlock() OSMutexPost() Commercial RTOS (µc-os/ii) HAL -ISR -context switch -stack init -timer tick -exception vectors -processor init Preemptive Scheduler E I Communication Manager S R Guy Bois, École Polytechnique de Montréal 10

11 6. Details of each level of abstraction L1 RAM L1 Devices represent memory modules Other device U Channel Functionality capture in 2.0 s represent user code Specification and verification of the general idea Untimed and very fast simulation Guy Bois, École Polytechnique de Montréal 11...

12 6. Details of each level of abstraction L2 Sw Simulator Hw Simulator HAL RAM API RTOS Socket adapter U Channel Other device RTOS Priority assignment with resource sharing Hw/Sw pre-partitioning Hardware selectionl2 and software simulation in two different processes Synchronization between hardware and software performed by message passing through a socket Untimed and fast simulation Guy Bois, École Polytechnique de Montréal 12

13 6. Details of each level of abstraction L3 Sw Adapter L3 Both hardware and software advance in a locked step cycle... API RTOS RAM Timing constraints A module emulates the RTOS HAL Hardware and software simulated in the same process Timed (and fast) simulation Under development Channel Wrapper Wrapper... Other device Hw simulator Guy Bois, École Polytechnique de Montréal 13

14 6. Details of each level of abstraction L4 Sw code L4 ISS with an RTOS for the software... API HAL RTOS CPU and bus selection. Use of CPU: interrupt latency, etc. Final HW/SW partitioning ISS ISS and hardware modules simulated by Co-debugging with two debuggers Cycle true simulation D e c o d e r Wrapper RAM Other device Channel Wrapper Wrapper Guy Bois, École Polytechnique de Montréal Hw simulator

15 7. SOCP as channel interface model Master putrsp() SocpChannelBase putreq() Slave putreq() SOCP from StepNP D&T Dec putrsp() Guy Bois, École Polytechnique de Montréal 15

16 7. SOCP as channel interface model putresp() socp_module_adapter m_socpmasterport SocpFuncChannel m_port m_port socp_module_adapter m_socpmasterport m_port s_port s_port read() write() nb_read() nb_write() mem_read() mem_write() m_socpslaveport putreq() s_port m_socpslaveport m_socpmasterport m_deviceport device socp_device_adapter putresp() mem_write_from_channel() mem_read_from_channel() Guy Bois, École Polytechnique de Montréal 16

17 7. Results: Audio Filter Wake up the controller when the buffer is full New destination address for incoming data 4 Data (32 bits) Data (32 bits) Producer 1 Filter 2 Mux 3 5 New filter coefficients 9 Data (32 bits) Ask for analysis Analyzes a memory region Controller 6 Analyzer 7 RAM Analysis Result 8 1. The Producer generates audio data with a rate of 44.1 khz. 2. Filtered data is sent to the Mux. 3. The Mux puts the data in a buffer in memory. 4. When the buffer is full, the Mux wakes up the Controller. 5. The Controller gives a new buffer address to the Mux. 6. The Controller requests new filtering coefficients. 7. The Analyzer computes new coefficients with the buffered data. 8. The Analyzer sends new coefficients. 9. The Filter receives new filtering coefficients. Guy Bois, École Polytechnique de Montréal 17

18 7. Results: Audio Filter H/S choice under Invader Guy Bois, École Polytechnique de Montréal 18

19 7. Results (on a Pentium IV GHz, 512 MB of RAMBus) Level Number of data generated (producer alway in Hw) Number of iterations for the controller Data analyzed per iteration Efficiency (generated vs analyzed) Simulation time Cycles L % 3 s 4.6 M L2 100% SW % 21 s 4.8 M L2 PART % 15 s 4.7 M L4 100% HW % 20 s 4.7 M L4 100% SW % 22 s 4.7 M L4 PART % 22 s 4.7 M Here, two metrics are considered: bandwith and efficiency Guy Bois, École Polytechnique de Montréal 19

7. Conclusion and future works We proposed a refinement methodology lets system designers validate their application functionality at each abstraction level and simulation provides more and more

20 7. Conclusion and future works We proposed a refinement methodology lets system designers validate their application functionality at each abstraction level and simulation provides more and more precise results through each level. Encapsulating RTOS functionalities into an API allows to be a common language Adapt a partitioning algorithm and add metrics Support SOCP protocol from OCP. Adapt a verification methodology Target an FPGA (Virtex-II Pro) AP107-6PCI from Amirix Guy Bois, École Polytechnique de Montréal 20

Performance Verification for ESL Design Methodology from AADL Models

Performance Verification for ESL Design Methodology from AADL Models Hugues Jérome Institut Supérieur de l'aéronautique et de l'espace (ISAE-SUPAERO) Université de Toulouse 31055 TOULOUSE Cedex 4 Jerome.huges@isae.fr