New technological opportunities coming along with SystemC/SystemC AMS for AMS IP Handling and Simulation

Transcription

1 New technological opportunities coming along with SystemC/SystemC AMS for AMS IP Handling and Simulation Karsten Einwich, Thilo Vörtler, Thomas Arndt Fraunhofer IIS/EAS

2 Outline n Introduction n SystemC / SystemC-AMS for IP protected model exchange n HiL simulation wit SystemC / SystemC-AMS n System level verification and validation with SystemC/SystemC-AMS n Summary 2

3 Purpose of this Talk n Demonstrate SystemC / SystemC-AMS specific advantages n Give Examples for innovative use cases for virtual platforms n Inspire to think about other use cases 3

4 SystemC / SystemC AMS Ø C++ based Hardware description language for higher abstraction levels Ø Hosted and standardized by the Accellera Systems Initiatiative Ø SystemC focuses on the description digital hard- and software on higher abstraction levels Ø SystemC-AMS extends SystemC for abstract modeling of analog/mixed-signal 4

5 SystemC / SystemC-AMS Advantages n Based on standard C++ n The layered architecture provides a Lego modeling and simulation system n Extendibility n High flexibility n Exploration of new methods and technologies easily possible n Model of Computation concept permits fast system level simulations n License-free simulation and model export to nearly all platforms possible n Easy integration into other tools 5

6 Simulation performance due SystemC/SystemC-AMS abstraction possibilities F= simulation time simulated time Complete window lifter model Electronics and mechanics SystemC-AMS Software on algorithmic level n Factor F SystemC-AMS cycle accurate MCU model n Factor F VHDL-AMS / VHDL n Factor F FastMOS (Ultrasim) n Factor F (start-up only possible) Spice-like (Spectre) n Not simulatable! Source: Monica Rafaila, Georg Pelz Infineon Technologies 6

7 Challenges for the design of automotive electronic components n Combination and tight interaction of different domains electronics, hard- and software as well as mechanics, hydraulics, n Engineers of different disciplines, different companies and different cultures have to work together the terminology Babylon n Increasing safety requirements and regulations n Increasing number of feature and their interaction n Software and especially hardware dependent software 7

8 Automotive Value Chain TIER-2 (e.g. Infineon) TIER-1 (e.g. Continental) OEM (e.g. Daimler) Stim. Stim. Microcontroller Testbench 1 Hall- Sensor Eval. Eval. Multi-Domain Stimuli Door- Mechanics (OEM requirements) Hall- Sensor ECU Microcontroller Evaluation Hall- Sensor ECU Microcontroller Testbench 2 provide customer models ensure IP protection fulfil TIER-1 req. ECU Testbench ensure robust system behaviour handle complex simulations fulfil OEM requirements Automotive Value-Chain (AVC) (Wolfgang Scherr Infineon AIM) prepare test software define requirements for TIER-1 fulfil John Doe s req. 8

9 What s needed? n Cross-domain / cross company communication platform n Inexpensive (virtual) prototyping platform with short iteration cycle n Test of real-life use cases fast executable specification, a platform were you can play with n Inexpensive and fast failure injection including artificial /corner cases 9

10 Easy Tool Coupling via C-Interfaces Tool Couplings for model exchange and implementation level verification Easy Tool Coupling to special Simulator with C-Interface Customer Model Design (IP-Protection ensured) Model Exchange Simulator coupling to: Saber ModelSim/Questa NCSim Matlab CANoe, etc. Hardware in the Loop Simulation with dspace HiL/RCP Hardware source: dspace 10

11 Principle SystemC / SystemC AMS Model Exchange 11

12 Automotive Sensor Applications TIER2 TIER1 OEM pressure pulse V DD Bias Supply EEPROM Interface enable A D D A OUT uc V DD Temp. Sense A D ROM firmware OBD GND Source: Wolfgang Scherr Infineon AIM 12

13 SystemC AMS Modelexchange via Simulink Integration SystemC-AMS Model model.dll or model.so Simulink 13 13

14 Integration of a SystemC-AMS Model into different Customer Environments Matlab/ Simulink Cadence/ ncsim 14

15 SystemC AMS CANoe Integration SystemC AMS virtual Door Module 15

16 Principle dspace Model Export 16

17 Direct SystemC-AMS HiL Simulation SystemC- AMS Model ds1006.x86 17

18 SystemC / SystemC-AMS Model re-use Virtual Testbench Stimuli DUT (SC/SCA) Monitor HiL-Environment DUT (SC/SCA) dspace HiL/RCP Hardware 18

19 SystemC/SystemC AMS dspace HiL Use Cases Test of Component Specification (e.g. for IC s) Motor SystemC (AMS) executable Spec Real Hardware ECU Test of Hardware Components in a not yet existing environment Real Hardware SystemC (AMS) Environment Model 19

20 Hierarchical Error Injection 20

21 Example: Basic error class loose_wire : public error_injection_base { public: void activate(); void deactivate(); loose_wire(const std::string& port); private: void build_connect(); std::string port; sc_core::sc_signal<double> err_sig; }; void loose_wire::build_connect() { sca_eln::sca_terminal* eport=get_object<sca_eln::sca_terminal>(port.c_str()); sca_eln::sca_node* broken_wire=new sca_eln::sca_node("broken_wire"); sca_eln::sca_terminal* old_port=null; sca_eln::sca_node* old_node=null; SC_RECONNECT_PORT(*eport,*broken_wire,old_port,old_wire); sca_eln::sca_de_r* rerror=new sca_eln::sca_de_r("loose_r"); rerror->n(*broken_wire); if(old_port!=null) rerror->p(*old_port); else rerror->p(*old_node); rerror->inp(err_sig); err_sig.write(0.0); //initial short cut } void loose_wire::activate() { err_sig.write(1e8); //open wire } void loose_wire::deactivate() { err_sig.write(0.0); //short cut } 21 21

22 Example: Single Error class loose_contact: public error_injection_base { public: void activate(); void deactivate(); void sequence(); loose_contact(const std::string& port); private: loose_wire lwire; sc_core::sc_event next_activation_event; bool activated; }; void loose_contact::sequence() { while(true) { wait(next_activation_event); if(activated) lwire.activate(); else lwire.deactivate(); next_activation_event.notify(30.0,sc_ms); activated=!activated; } } ////////////////////// void loose_contact::activate() { next_activation_event.notify(); } ///////////////////// void loose_contact::deactivate() { lwire.deactivate(); activated=false; next_activation_event.cancel(); } 22

23 Example: Scenario class error_scenario : public error_injection_base { public: void sequence(); error_scenario(); private: loose_contact loose_r; loose_contact loose_s; loose_wire loose_t; }; error_scenario::error_scenario(): loose_r("*i_engine_sl1.r"), loose_s("*i_engine_sl1.s"), loose_t("*i_engine_sl1.t"){} void error_scenario::sequence() { wait(1.0,sc_core::sc_ms); } loose_r.activate(); wait(5.0,sc_core::sc_ms); loose_s.activate(); wait(10.0,sc_core::sc_ms); loose_s.deactivate(); loose_t.activate(); wait(33.3,sc_core::sc_ms); loose_t.deactivate(); wait(23.0,sc_core::sc_ms); loose_r.deactivate(); wait(12.5,sc_core::sc_ms); 23

24 Implementation Level Verification n SystemC / SystemC-AMS models are golden references n Stimuli generator for blocklevel verification n Challenges: n Timing inaccuracies / synchronization n Scenario length 24

25 initiator_cpu target_cpu target_cpu TLM RTL Implementation Level Verification TLM-Modell (SystemC) FSQM target_cpu target_pld PBM target_cpu PSM target_cpu target_pld TLM- Ergebnis target_plu target_ppu target_psm initiator _pbm target_plu target_ppu target_ppd target_ppd GTC (GPON Framer/TC) initiator_ppu initiator_ppd target_cpu initiator_ppd initiator_sce initiator_ppu PPU target_gtc SDMAG initiator _sdma PPD SDMA target _sdma target_gtc initiator_ssb initiator_llt Master PPD = Processing Pon Downstream PPU = Processing Pon Upstream PLD = Processing Lan Downstream PLU = Processing Lan Upstream Slave initiator_llt target_cpu FDMAG SDMAL initiator _plu initiator _fdma FDMA target_fdm a initiator_ssb CPU SCE (incl. Policer ) target_ppd target_plu target_llt target_ssb LLT SSB initiator _sdma SDMA target _sdma initiator_sce initiator_ssb PLU target_eim initiator_llt FDMAL initiator_fdma FDMA target _fdma initiator_ssb initiator_pld PLD initiator_llt target_cpu initiator_eim initiator_plu target_pld EIM (LAN Interfaces) Bitgenaue Ansteuerung Transaction- Checker VHDL- Ergebnis 1 a1 b1 5 ModelSim-Simulation 2 a2 3 a3 RTL-Modell (VHDL) 6 b2 7 b3 4 a4 b4 8 25

26 System Level Verification n High level sequences should be traceable in the system spec and test the integration of system level components. n The high level sequences should be reusable for lab equipment and as a reference for UVM virtual sequences n In UVM the correctness of a high level test is assumed when all monitors/ scoreboards of a building block do not detect an error. The expected system behavior is therefore spread into several points of the design n A coverage mechanism is needed to check, whether all specified test cases and input sequences are checked n An mechanism is therefore needed to specify: n Test sequence specification n Expected Results there is no golden reference or simple rule 26

27 UVM for SystemC / SystemC-AMS n UVM defines a reusable test bench architecture for Assertion Based Verification to randomize data n The main focus of UVM is the exhaustive verification of digital blocks 27

28 Testbench Architecture Transactions needed between Driver and Sequence Library Core Sequence Library Core Driver DUT SPI Driver SPI Sequence Library Core Monitor Assertion/Evaluation - function Library SPI Monitor Sensor Library Method calls Configures used functions Method calls Test Sequence/ Expected Result description n Driver communicate with DUT, Monitors sample DUT values n Library of drivers/monitors and assertions required n Assertions/Evaluation functions are test case specific and can be bound into monitor 28

29 Why UVM for Mixed Signal System Level n Industry standard in digital verification n Facilitates the development of reusable verification components n Implementation only available in SystemVerilog à Currently being ported to SystemC Challenges for AMS implementation n Randomization & coverage of analog signals n Assertions supporting analog events n Description of system level test cases 29

30 UVM Limitations for System Level Verification n Generation of expected behavior n No golden reference available n Usually no simple rule between stimulation and expectation n Synchronization of drivers and monitors n Control of driver timing n Assertions are practically applicable for simple low level checks only n They are usually located in the monitor n Coverage for AMS / System level 30

31 Challenges in AMS System Level Test n System level tests are derived from the requirements and/or specification n Tests are the foundation for both simulation and lab validation n Especially in AMS, test often contain timing uncertainties n e.g. between 0 ms and 5 ms, the output should be set to 1 n Sequences will be run on UVM (virtual) sequencers Test_main scv_smart_ptr< int> data; data- >keep_only(0,7); system_init(); t_wait(10us,10ms); spi_channel_cfg(); t_wait(1us,10us); sensor_channel_en(data); Init_sync_en() System_init() Initial condition(); ramp_up_voltage(0,12.5,0.5,10us); wait(16420us); releasecorereset(); wait(100us); releaseµcontrollerreset(); Spi_channel_cfg synchronization mode() set_sensor_data_length() set_transmission_rate() Sensor_channel_en(data) If (data = 0) Send_spi_data( b). If (data = 8) Send_spi_data( b) Wrapper for transmission of data to a sensor channel, calls spi sequences Init_sync_en sensor_com_init(init_sync_mode) 31

32 Example: SPI stimulus SPI Library Test_main Sensor Library Core Library scv_smart_ptr< int> data; data- >keep_only(0,7); system_init(); t_wait(10us,10ms); spi_channel_cfg(); t_wait(1us,10us); sensor_channel_en(data); Init_sync_en() System_init() Initial condition(); ramp_up_voltage(0,12.5,0.5,10us); wait(16420us); releasecorereset(); wait(100us); releaseµcontrollerreset(); Spi_channel_cfg synchronization mode() set_sensor_data_length() set_transmission_rate() Sensor_channel_en(data) If (data = 0) Send_spi_data( b). If (data = 8) Send_spi_data( b) Wrapper for Transmission of data to a sensor channel, calls function of spi library Possible execution traces Trace1: system_init(); wait(11us); spi_channel_cfg(); wait(7us); sensor_channel_en(3); Init_sync_en(); Trace2: system_init(); wait(5ms); spi_channel_cfg(); wait(3us); sensor_channel_en(0); Init_sync_en(); Init_sync_en sensor_com_init(init_sync_mode) 32

33 VERDI Technical Approach Standardized technologies as SystemC/AMS, UVM, TLM, IP-XACT are being extended to allow system level verification and automatic test setup System level test scenarios shall be reused without modification between verification and validation 33

34 SystemC/SystemC AMS Testbench reuse Virtual Testbench Stimuli DUT (SC/SCA) Monitor dspace HiL/RCP Hardware 34

35 Summary n SystemC/SystemC-AMS based modeling methods enable novel use cases for virtual models n Executable specifications become reality and an IP protected model exchange between different companies and worlds is feasible n The abstraction possibilities of SystemC/SystemC-AMS are the enabler for real time HiL simulation of executable specifications n Novel system level verification and validation concept can be explored and developed 35