Progetto MAIS - WP5 esplorazione di architetture alternative Resoconto delle attività svolte

1. Progetto MAIS - WP5esplorazione di architetture alternativeResoconto delle attività svolte Andrea Pagni STMicroelectronics, Advanced System Architectures Group Roma 24-25 Novembre 2005

2. WP5 presentation Overview MAIS, as outlined by the name, deals with Multichannel Adaptive Information Systems. Within WP5 we carry out a micro-architecture evaluation of components capable of supporting complex computing paradigm. With the above goal, the key issues in exploring architectural alternatives is the necessity to use a suitable simulator to “navigate” among different solutions obtaining accurate results..…. In a reasonable timeframe (i.e. before end of universe!) Within WP5.1, after a first general exploration phase the activities focused on the ST200 VLIW family and the implementation of a ISS (Instruction Set Simulator). During this year, this was subsequently integrated within the MaxSim Simulation Environment in order to allow the possibility of performing simulations at System level (both SoC and NoC). Today we’ll present some significant results of WP5.1 and it will be provided a short glimpse of the activities of WP5.2 dealing with Very Small Data base

3. Display Sub- System DACs Clocks SH4 Interface Sub- System EMI ST220 STbus LMI ST220 Video Encoder DVDecoder ST220 MPEG2 Blitter Comms WP 5 and ISO/OSI BUILDING Level 7: Application Layer (Top Layer) Level 6: Presentation Layer Level 5: Session Layer Level 4: Transport Layer Level 3: Network Layer Level 2: Data Link Layer Level 1: Physical Layer (Bottom Layer) Basament: WP 5 Layer

4. Topics • Part 1: VLIW-SIM Overview. • Part 2: Simulation Issues • Part 3: Power Issues • Part 4: Crypto Issues.

5. Part 1: VLIW-SIM Overview

6. VLIW-SIM Overview Overview ST210 • Windows OS (Visual C++): • text mode: project file in vliw_sim/vliw_sim • graphical mode: project file in vliw_sim/gui/gui • Windows OS (Cygwin, gcc): • text mode: makefile in vliw_sim/vliw_sim • graphical mode (with XWindows on Cygwin) • Linux OS (RedHat, gcc): • text mode: makefile in vliw_sim/vliw_sim • graphical mode: makefile in vliw_sim/gui/gui • Sun OS (Solaris, gcc) • text mode: makefile in vliw_sim/vliw_sim • graphical mode: makefile in vliw_sim/gui/gui • Simulation Technology based on a set of re-usable sub-blocks • Pipeline modeling • Instruction execution • Memory modeling • Register file management • I/O simulation • Efficient Host Resources Allocation • Target Architecture Description capability (IS, TAD) • Challenging compromise between Speed and Accuracy • Multi-cluster Architecture • 4-issue VLIW core • I/D-cache memories • 6-stages pipeline • RISC-like Instruction Set • 64 32-bit General registers, 8 1-bit special registers

7. Part 2: Simulation Issues

8. SIMULATION ISSUESMaxSim Environment • MaxSim is a Transaction and Cycle based SoC simulation Environment. • VLIW-SIM is usable both as a stand-alone simulator and as a dynamic library. • The major requirements for interfacing the simulator to a SOC Design environment are: • Externally driven by Control Functions (Configure, Init, Load, Reset, Step, Stall, Terminate). • Dynamically linkable to the SOC Design environment (.dll, .so). • Support for external device communication (memory, DMA, I/O). • Optional debug interface.

9. SIMULATION ISSUESMaxSim component creation • Creation of a MaxSim component • After the MaxSim installation on the Windows platform, the Visual C/C++ allows the creation of a MaxSim component workspace • User is demanded to interact with a component wizard, selecting library component features like: • component type (Clocked, Debug interfaced, Core/Memory/DSP/Bus/CACHE/Co-Proc/etc, description, application file extension), • component ports (port name, port type), • component parameters (parameter name, default value, type, run time modifiability).

10. SIMULATION ISSUESUser Interface • Component Wizard • Component C++ Class

11. SIMULATION ISSUESIntroduced Features • The multi-core simulation use multiple DLL copies. • A DLL duplication mechanism has been introduced in the run-time library loading. • The duplication (and removal) is automatic and transparent to the user having no constrains on the maximum number of cores included in a single MaxSim project. • VLIW-SIM core DLL duplication and removal happen during the initialisation and termination phases of the MaxSim simulation (and not in the system design process).

12. SIMULATION ISSUESArchitecture Interface Overview • Designer project Data and Program memory of the first ST210 VLIW-SIM component – ST210 Standard MaxSim multiport memory used as shared memory VLIW-SIM component – ST210 Data and Program memory of the second ST210

13. SIMULATION ISSUESAchievements • The component resulting from this integration task implements all the functionalities and facilities of a MaxSim core component. • Except from the debug support, the VLIW-ISS MaxSim component offers all the VLIW-ISS stand-alone functionalities. • A considerable part of the integration efforts have been focused on performance and flexibility issues even though these features does not directly influence the integration itself. • Simulation tests show that MaxSim introduce a negligible performance decrement compared with the component stand-alone simulation outside MaxSim.

14. Part 3: Power Issues

15. Power Issues • Power management can be singled out as the more important issue in modern microprocessor architecture for mobile applications. In order to gain efficiency, it is necessary to adopt a coherent strategy with regards to: • Software (instructions efficiency to perform task) • Hardware (power efficiency in performing instructions) • Within WP 5.1 main focus has been devoted in assessing a design methodology for VLIW/SoC architecture

16. Power Issues • Goal of the activity was the definition of a complete design methodology • with the following features: • Efficient mapping of an application on a target architecture • Optimally interconnect system components • Evolution of the SoC design: • FROM • Computation-centric system design • Optimizing Computation • Standard communication architecture • TO • Communication-centric system design • Standardized computing architecture • Optimizing Communication

17. MP SoC: a Simulation Platform in SystemC OCCN Lx Lx STBus Compliant Communication Architecture ARM STBus Target #1 STBus I/F STBus I/F STBus I/F STBus I/F STBus I/F STBus I/F STBus I/F STBus I/F STBus Target #N STBus Master #1 ARM STBus Master #N • Scalable and flexible to plug-and-play new Cores and Bus configurations

18. The 4way multiprocessor platform SystemC Wrapper SystemC Wrapper SystemC Wrapper SystemC Wrapper RTEMS OS RTEMS OS RTEMS OS RTEMS OS ST220 TDMI ISS ST220 TDMI ISS ST220 TDMI ISS ST220 TDMI ISS • SW Application: RTEMS Boot + Matrix Multiplication 8x8 shared bus – 32 bit – Type 3 Fix. Priority (Req) – Dyn. Priority (Resp) Shared Memory … Shared Memory

19. Co-simulation results • 1% Avg error • Less than 5% of RMSE Os boot

20. Discrete battery models (experimental) Vout*Iout=Vin*Iin* Conversion efficiency battery Dc/dc Converter STBus SystemC Simulation Vout, Iout Vin, Iin initial voltage intermediate voltage Cut-off voltage (*) quadratic model used, 3.7 mJ of initial charge state, 0.2 [A] of average load

21. Design Space: Size is the Issue • B, Psent, Prec depend on high level STBus network configuration B, Psent, Prec = f (master, target, width, type, topology, resources, arbitration, C load) • The characterization of the entire design space would require50CPU yearsonly for synthesis !! • Proposed solution: • Heuristic surface reconstruction methods

22. Part 4: Crypto Issues

23. CRYPTO IssuesThe threat • The increase in communication rate among devices leads to an intensification of malicious attacks to overcome the traditional crypto algorithms (i.e. AES, ECC,…) • Among the main methodologies exploited by attackers there are: • Simple Power Attack (SPA) • Differential Power Analysis (DPA) SPA DPA Based on the observation of a single execution of a crypto algorithm It is applied to algorithms whose operation’s sequence depends on the processed data It can be applied to whatever algorithm executed in a constant time with a chain of constant additions and subtractions Statistic analysis of many executions with different inputs

24. CRYPTO IssuesEnvironment Hypothesis on the attacked key bit: 1 Hardware Simulator 15 15 10 10 5 5 Differential power Differential power Hypothesis on the attacked key bit: 0 Oscilloscopio 0 0 -5 -5 20000 40000 60000 80000 100000 120000 140000 20000 40000 60000 80000 100000 120000 140000 0 0 Power samples Power samples Crypto System implementation Log file Power consumption simulation Power traces Static Analysis For DPA Differential traces

25. CRYPTO IssuesAchievements • The activities has focused on the analysis of some of the most commonly used crypto algorithms (AES; ECC) and their architectural implementation • This architectural simulation has allowed to identify some weaknesses that were very difficult to predict on a purely theoretical base. • In turs this has allowed the testing of the effectiveness of some contermeasures and comparisons • It has also been determined that countermeasusrtes against SPA helps out against DPA (by syncronizing the traces)