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
Monteiro Fellipe
Space Codesign Systems Inc.
450 rue St-Pierre, Suite 1010
Montreal, QC, Canada H2Y 2M9
Fellipe.monteiro@spacecodesign.com
Gaudron Mathieu, Bois Guy
Computer and Software Eng. Department
Polytechnique Montreal
Montreal (Quebec),
Mathieu.gaudron@polymtl.ca, Guy.bois@polymtl.ca

Agenda
 Problem
 Our approach
 Proposed ESL flow based on AADL
 Case study and QoR Constraints
 Experimental Results
 Conclusion and Future Work
IRT Workshop Hardware/Software co-development 2015 2

Problem
 Systems on chip (SoCs) development faces a
number of tough requirements
 Demand to shrink time-to-market and keep
costs under control
 Errors are introduced early but detected (too)
lately and at higher cost
3IRT Workshop Hardware/Software co-development 2015

Our approach
 Shift-left
 Perform hardware/software validation earlier in the design flow
 Integration of different methodologies and technologies
1. Model-Based Engineering (MBE) with AADL
2. ESL Virtual Platform (VP)
3. Mapping from AADL to VP components
4. ESL Flow and Architectural Exploration
 In this work we will focus on the performance verification
process

Model-Based System/Software Engineering
5
Link to code/model
Non-functional properties
Architectural patterns
Architecture helps you focusing on the actual system

Space Codesign
6
SpaceStudio graphical interface representing the Virtual Prototype
Software
Hardware
IRT Workshop Hardware/Software co-development 2015

 Perform design space exploration
in an automatic way
 Leverage AADL description +
constraints to guide exploration
instead of manual selection of
candidates
 Bring SpaceStudio capabilities
to AADL design evaluation
 Two-step contribution
1. Bridge AADL and SystemC
2. Generate candidates
Goals & contribution

 AADL entities communicate
through ports
 Uniform API from comp.
PoV: send/receive calls
 Ocarina generates API based
on AADL model information:
 Process, Task and port id
 From component PoV, only
local ports are visible
 Other elements are used
internally to route message
AADL component model & communication
8
__po_hi_gqueue_store_out (self, port, &request);
Instance handle Port variable Data sent

 Mapping of regular SpaceStudio entities back to AADL
 Combined with property sets to be discussed for
configuration
 Solution#1: minimal example being developed,
 Iterations required to enrich property sets
 Discussions to build library of reusable designs
Step #1: Capturing SystemC designs in AADL

 Aim is to facilitate binding of C algorithms directly to
SystemC wrappers, generated from component
architecture
 Design of a SystemC skeleton backend that
 Maps component scheduling policy (sporadic, periodic) to
corresponding SystemC template
 Maps component ports to interaction with port variables
Step#2: Generation of skeletons
10
system_adder_adder::system_adder_adder(sc_module_name zName, …)
: SpaceBaseModule(zName, …) {
SC_THREAD(thread);
}
void system_adder_adder::Thread(void){
while(1){
DeviceWrite(Timer1_ID, offset, &initValue);
//Execution of functional algorithm
DeviceRead(Timer1_ID, offset, &timerValue);
}

 SpaceStudio API has similarities with AADL one:
 API to send/receive data/events, FIFO-based message passing, Shared-
memory communication, Register-based communication
 But API lists destination block, not local port
 E.g.
 This limits component reuse in case of change in
architecture
 Solution #3: add intermediate routing table
 Like in regular AADL code generation: a module interacts with
local ports, a routing table acts as a proxy to remote ports
 Implemented in Ocarina by M. Gaudron, in AADL-to-SpaceStudio
back-end
Step#3: Revisiting SpaceStudio API
11
ModuleRead(EXTR_ID, SPACE_NON_BLOCKING, &inmsg);

ESL Flow Based on AADL
12
AADL
Configuration and code
generation with
OCARINA
C/C++ Source
Code
(.h and .cpp)
Python
Script
Performance
verification and
Architectural
Exploration
Project Generation
for EDA tool (e.g.
Xilinx, Altera,
Synopsys)
Space
Library
Implementation
SpaceStudio – ESL Virtual Platform
Requirements
Met?
No  Feedback to the user
Yes
Requirements

13
ESL Virtual Platform (VP)
 ESL design and verification
 Emerging electronic design methodology
 Focuses on the higher abstraction level concerns.
 In this work we use SpaceStudioTM 8
 Functional/non-functional specification (C/C++/SystemC)
 Scriptable tool
 System performance prediction
 HW/SW co-design
 Architectural exploration
 Non-intrusive monitoring
 Fast FPGA prototyping

6
ESL Flow and Architectural Exploration
SpaceStudio
 3 levels of abstraction:
High Level
Low Level
Elix - Functional validation
 Application and Algorithm
Optimisation
Simtek - Architectural
validation
 Exploration loop
 Architecture parameters
evaluation:
 Clocks frequency
 FIFO sizes
 Bus latency
 Cache configuration
 Etc.
GenX - Implementation
 RTL project generation
 Xilinx
 Altera
 Etc.

SpaceStudio Elix – Functional validation
15
Elix - Functional validation
Requirements
AADL
Module C Module D
Module A Module B
Configuration and code
generation with
OCARINA
Python
Script
C/C++
Source code
(.h .and cpp)

SpaceStudio Simtek – Architectural validation
16
Database (DB)
HW
Resource
Estimation
Potential
Architectures
{A1, A2, …, An}
HW/SW Co-
Synthesis
Embedded
Software
TLM Virtual
Platform
Power
Metrics
Performance
Metrics
HW/SW Co-
Simulation
• QEMU
• ARM Fast Models
• Simics
• OVP
• Linux
• uC
• RTEMS
• Bare Metal
• VxWorks
• Xpower (Xilinx)
• Docea Power
• Vivado (Xilinx)
• Vivado HLS
• Quartus (Altera)
OS / RTOS
ISS
PowerAnalysis
• Calypto Catapult
ASIC
FPGA Switching
Activities
• SpaceLib
IP Library
Simtek - Architectural validation
• Supported
• Not supported yet
Third Party ESL Products

 Hardware
resource usage
estimation
 Processor load
 Task switching
 Deadlock
 Starvation
 Latency
 Execution time
 Deadline
 Communication
bottlenecks
 Bus bandwidth
 FIFO bandwidth
 Memory accesses
 CPU Time
 Power
Consumption
Simtek Profiling and Monitoring Database
17
Resource
consumption
Performance
Resource
estimation
Software
Events

SpaceStudio GenX - Implementation
18
RTL
Hardware
Platform
Selected
Architecture
IP Mapping /
Reuse
Embedded
Software
TLM Virtual
Platform
Software
Firmware
Software
Application
Firmware and
Drivers
Generation
• Linux
• uC
• RTEMS
• Bare Metal
• VxWorks
• Vivado (Xilinx)
• Quartus (Altera)
OS / RTOS
• Calypto Catapult
• Vivado HLS
HLS
IP Libraries
GenX - Implementation
High Level
Synthesis
• Supported
• Not supported yet
Third Party ESL Products
• Zynq SoC
• Virtex FPGA Family
• Spartan FPGA Family
• Cyclone V Soc
Target

Case Study : Motion-JPEG
 System: Remote video monitoring to assure proper behavior using
thumbnails
 The MJPEG (as a subsystem) is part of the complete video processing system on
FPGA
 Objective: Performance verification of a M-JPEG video decoder
application for video thumbnails
19
Input
Interface
Video
Processing
(FPGA)
Output
Interface
Memory
Processor/
Controller
Stream In Stream Out
Remote
System
Ethernet
The M-JPEG subsystemA complete video processing system

QoR Constraints
 The target is a Xilinx Zynq-7000 with three types of
processing:
 ARM Cortex-A9 dual-core processor running Linux
 MicroBlaze soft-core processors running µCOS/II RTOS
 FPGA fabric as coprocessors
 As the subsystem is part of a larger system, we must:
 Minimize the FPGA resources
 Not exceed 10% of ARM processor maximum load
 A minimum of 4 frames per second (FPS) as sufficient

Experimental Results (1)
 Five Hardware/Software architectures verified
 DEMUX, IDCT and IQZZ in SW and the rest in HW
21
Architecture
Mapping on SW
ARM MicroBlaze
Mapping on HW
Arch #1 IDCT / IQZZ / VLD DEMUX LIBU
Arch #2 IDCT DEMUX IQZZ / VLD / LIBU
Arch #3 IQZZ DEMUX IDCT/VLD/LIBU
Arch #4 VLD DEMUX IDCT / IQZZ / LIBU
Arch #5 IDCT DEMUX / LIBU IQZZ / VLD

 Mapping of the DEMUX thread (AADL to Python)
22
AADL
Python

 Mapping of the DEMUX thread
 AADL to SpaceStudio through python scripting
23
Python
SpaceStudio

 Performance
24
Arch. FPS
Maximum load
on the ARM
processor (%)
Arch #1 2,5 66
Arch #2 17,54 48
Arch #3 17,4 49
Arch #4 4,7 50
Arch #5 4,2 10
 Hardware resources
Arch.
LUT
(%)
FF
(%)
RAM
(%)
DSP
(%)
Arch #1 31 27 37 21
Arch #2 45 34 47 22
Arch #3 46 33 47 27
Arch #4 34 30 43 47
Arch #5 22 13 45 8
 Architectures 1
 Doesn’t meet the performance requirements of 4 FPS
 Architectures 2, 3 and 4
 Too much load (over 10%)
 Too much hardware resources.
 Architecture 5 Meet all requirements

Conclusion and Future Work
 AADL high-level model mapped on a virtual platform
 AADL allowing early analysis and to avoid late re-
engineering efforts
 Performance verification of different architectures
achieved in hours
 In RTL at least few days
 Next?
 Supporting additional properties
 Cache size
 Communication buffer size
 Power constraints
 Verify scheduling properties of the system model

Performance Verification for ESL Design Methodology from AADL Models

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Performance Verification for ESL Design Methodology from AADL Models (20)

Recently uploaded (20)

Performance Verification for ESL Design Methodology from AADL Models