TLM Technology for Off-Chip Interfaces on the Automotive domain

Size: px

Start display at page:

Download "TLM Technology for Off-Chip Interfaces on the Automotive domain"

Anastasia Allison
5 years ago
Views:

1 TLM Technology for Off-Chip Interfaces on the Automotive domain European SystemC User s Group Workshop Victor Reyes Synopsys Synopsys

2 More than SoC only simulations SoC Board System IP communication chip-to-chip communication device-to-device communication Domain Mobile, Consumer, Automotive, Networking Synopsys

3 The Challenge When moving to full system (device) simulations the interactions between Different chips on a device The device and the environment become more important A strategy to model and use the required (off-chip) interfaces that Enable the different players on the supply-chain to exchange models Take into account the requirements for systems beyond the SoC is required The scope of OSCI TLM-2.0 is limited to within the SoC (memorymapped on-chip bus communication) Can the TLM-2.0 standard (or part of it) be reused to model bigger systems? Synopsys

4 Agenda Automotive Overview TLM Serial Interface Synopsys Solutions for Automotive Summary Synopsys

5 Automotive Overview Synopsys

Automotive E/E systems A car is a highly distributed computer system High-end cars today can contain up to 100 ECUs More than 2000 individual SW functions in a car and

Automotive applications are distributed across multiple ECUs that communicate and interact with each other Dramatic increase in interdependencies and connection e.g.

6 Automotive E/E systems A car is a highly distributed computer system High-end cars today can contain up to 100 ECUs More than 2000 individual SW functions in a car and increasing Automotive applications are distributed across multiple ECUs that communicate and interact with each other Dramatic increase in interdependencies and connection e.g. going in reverse gear involves 10 ECUs one connector problem at Gateway ECU 38 error messages in 5 ECUs transmission CAN bus gateway head unit Development and tests of such systems is very complex and costly driver door pass. door parking aid rear light CAN bus roof module rearview trailer int. light driver int. light pass. int. light back Synopsys

Subsystem Level ECU Level Engine Control ECU (2005) 500-700 functions 5000+

7 From Vehicle to SW Vehicle Level Vehicle SW 1 Billion lines of code by 2010 > 2000 functions Distributed on 75 ECUs (average) Growing inter-dependencies Subsystem Level ECU Level Engine Control ECU (2005) functions pages of spec 200,000 lines of code 10-20,000 parameters MCU Level SW Level Synopsys

Elements in a Subsystem (terminology) The

ECU network Spark plugs Fuel injectors Throttle

8 Elements in a Subsystem (terminology) The Controlled system (e.g. engine, transmission, brakes, suspension, etc) Accelerator pedal position Transmission stage ECU network Spark plugs Fuel injectors Throttle control Throttle valve Air mass Lambda oxygen sensor Crankshaft speed Synopsys

load >60%) Ethernet mainly used for diagnostics (but high potential in other areas) MOST is designed for multimedia using

9 In-Vehicle Networking LIN is a low cost bus for body applications (19.2 Kbauds, UART interface) CAN is the most spread network in the car, but has limitations (1 Mbps, non-deterministic under high load >60%) Ethernet mainly used for diagnostics (but high potential in other areas) MOST is designed for multimedia using optical fiber (up to 150 Mb/s) FlexRay is a high performance (10 Mbps), deterministic, and secure network (mainly used in X-by-wire, ADAS, and high performance applications) Synopsys

components include: Secondary MCU (8-bit) acting as external safety watchdog, etc EEPROM

10 Electronic Control Units (ECU) e.g. Powertrain Subsystem The core of a ECU is the main MCU (run the controller binary SW) Other components include: Secondary MCU (8-bit) acting as external safety watchdog, etc EEPROM Mixed-signal input and output conditioning blocks Dedicated ASIC (e.g. security) ECU components communicate with each other mainly using serial communication (SPI, I2C, ) Synopsys

11 Microcontroller Unit (MCU) e.g. Freescale MPC5643L New generation MCUs are multi-core architectures Memory-mapped based on-chip interconnect (suitable for TLM-2.0) PMU SWT MCM STM INTC edma Power Architecture FPU VLE MMU CACHE Cross Bar Switch Memory Protection Unit Debug FlexRay RC Power Architecture FPU VLE MMU CACHE PMU SWT MCM STM INTC edma Cross Bar Switch Memory Protection Unit Peripherals grouped by: Tightly coupled (INTC, Timers, DMA, ) Inter-ECU communication controllers (CAN, LIN, FlexRay, ) Intra-ECU communication (SPI, I2C, ) Sensoring/Actuation (ADC, PWM, GPIO, ) BAM MC I/O Bridge SSCM XOSC FLPLL SIU FMPLL WAKE IRCOSC ADC ADC RC FLASH (ECC) CMU CMU CTU FlexPWM RC RC SRAM (ECC) etimer etimer etimer TSENS TSENS FlexCAN FlexCAN CRC LFLEX LFLEX I/O Bridge PIT DSPI DSPI DSPI FCCU Synopsys

12 TLM Serial Interface Synopsys

13 Objective Define a generic infrastructure that can be used to model different off-chip interfaces Focus on serial interfaces (i.e. SPI, CAN, etc) Based on TLM technology That can serve as a basis for future standardization Synopsys

14 Where to start? Understand off-chip serial interface communication Types, concepts, characteristics, Find common parts Understand how the SW interacts with off-chip interfaces What can be abstracted, what has to be modeled Understand how the HW interacts with the off-chip interfaces Pin-multiplexing, SW controlled configuration,.. What the best implementation would be according to Simulation speed, use-of-use, scalability, etc Synopsys

15 Approach Analyze characteristic Define the key Create an of serial requirements implementation interfaces Synopsys

16 Indentify relevant interfaces Sensoring/actuation PWM, ADC, GPIO Plant model Plant model ECU ECU Intra-ECU communication I2C, SPI MCU MCU Inter-ECU communication CAN, FlexRay, LIN Synopsys

17 Serial interface (common) concepts Connectivity Different topologies: point-to-point, bus, daisy chain, Serial peripherals can have both the role of master (transmitter) and/or slave (receiver) dynamically over the same interface Communication Synchronous (separated clock line) / asynchronous (local clock) communication Bidirectional full-duplex (simultaneous data send and receive) Bidirectional half-duplex (data send or receive but not simultaneously) Unidirectional Multi-master is a bus with more than one master (arbitration required) Multi-drop is an interface where there is one transmitter and several receivers (multicast) Multi-point is an multi-drop interface that allows bidirectional communication over the same set of wires Addressing (routing) Communication can be unicast (single receiver), multicast (multiple receivers), broadcast (all connected nodes are receivers) Dedicated lines can be used for the selection Addressing can be decided based on (partly) message decoding and filtering Arbitration Bit-wise arbitration, dominant bit wins Acknowledge Interleave response bit(s) from receiver on specific slots of transmitter message Synopsys

18 SPI (serial peripheral interface) Intra-ECU communication Connectivity 4-wire (clock, slave select, data out, data in) Bus topology for data and clock Point-to-point for slave select Communication Single-master Full duplex Synchronous Unicast Addressing Dedicated slave select signal (master to slave) Arbitration none Acknowledge none Speed Max. 70 MHz Other Clock polarity (CPOL) and phase configuration (CPHA) are relevant parameters (SW configured) Daisy chain bus configuration Not specific payload structure (or size) Synopsys

19 CAN (controller area network) Inter-ECU communication Connectivity Differential-wires Bus topology Communication Multi-master Broadcast Half-duplex Asynchronous Addressing Filtering happens based on message ID Arbitration Lower ID wins Acknowledge Last bits of message Speed Max. 1 Mbps Other Different types of frames: Data frames (max. 108 bits) Remote frames (43 bits) Extended frames (128 bits) Synopsys

20 Requirements Serial peripherals and busses are protocol specific (it should not be possible to connect e.g. CAN to SPI) A generic infrastructure that can be specialized to different protocols will be defined instead The generic infrastructure will include objects and rules to be used on the serial peripheral and bus models Keep the interface simple, handle protocol dependent details in the peripheral models and not in the interface (or bus) Focus on a single coding style (abstraction level) Timed-accurate at the transaction boundary To be used on a LT or AT (with arbitration) platform The generic serial interface framework should support Different types of routing: broadcast, multicast and unicast, over the same implementation Synchronous and asynchronous communication Optional arbitration Enough timing information for the coding style Protocol specific information Synopsys

21 Implementation Overview PROTOCOL Serial Peripheral Serial Bus Serial Peripheral thread P_socket B_socket b_send(...) B_socket P_socket nb_receive( ) P_socket->b_send(payload) B_socket->nb_receive(payload) Modules Serial peripheral Serial bus Sockets Bus socket (used only on the serial bus) Peripheral socket (used only on the serial peripherals) Bidirectional interfaces Blocking send (to be used by the serial peripherals, implemented only on the serial bus) Non blocking receive (implemented only on the serial peripherals, used by the serial bus) Generic payload Generic attributes used mainly by the serial bus (addressing, arbitration and timing info) Extension mechanism Sockets, interfaces and payload are templatized with a protocol specific data structure Synopsys

22 Generic Serial Payload Attribute Data type Default value Description routing_mask unsigned int 0 Value 0 Broadcasting Value 0xffffffff Unicast(use select_id) Any other value Multicast (in combination with select_id) This attribute is used by the serial bus. select_id unsigned int 0 Indicates the destination port on the serial bus. Not relevant when broadcasting. This attribute is used by the serial bus. arbitration_id unsigned int 0 Indicates the value to be used during arbitration. This attribute is used by the serial bus. prot_data_ptr T* 0 Pointer to the protocol specific data. This attribute is used by the serial peripherals. bit_length unsigned int 0 Length in bits of the data transmitted. Only used for timing calculation purposes. This attribute is used by the serial peripherals. clock sc_time 0 Indicates the serial clock used during the transmission (synchronous protocols). It can also used for error checking in asynchronous protocols. This attribute is used by the serial peripherals. status tlm_serial_response *see table below Indicates the status of the transmission. More information in the table below. This attribute is used by the serial bus and peripherals. (select & mask) == (conn & mask) tlm_serial_response TLM_SERIAL_OK TLM_SERIAL_ERROR TLM_SERIAL_INCOMPLETE TLM_SERIAL_ARBITRATION_FAILED Description Set by the receiver(s) to indicate successful reception of the transfer Set by the receiver(s) to indicate a problem during the reception of the transfer Set by the transmitter. This is the default value. If the same value is return indicates that no receiver has got the transfer Set by the serial bus only. Indicates that arbitration failed and the transmission did not take place completely. struct tlm_serial_default_protocol { unsigned int byte_lenght; unsigned char* data_ptr; }; Synopsys

23 Bidirectional Serial Interfaces class tlm_fw_serial_if : public virtual sc_core::sc_interface { public: virtual void b_send(tlm_serial_payload & payload) = 0; }; The forward interface (b_send) is blocking. The rationale to make this interface blocking is to enable its used within SC_THREAD (simplicity) and to enable optional arbitration on the serial bus (serial bus may call sc_core::wait within the implementation). class tlm_bw_serial_if : public virtual sc_core::sc_interface { public: virtual void nb_receive(tlm_serial_payload & payload) = 0; }; The backward interface (nb_receive) is non-blocking. That means that the serial peripherals can NOT call sc_core::wait within the implementation. The rationale behind this decision is to assure the correct timing on the communication when broadcasting or multicasting is used. Synopsys

24 Serial Peripheral Socket template < typename PROTOCOL = tlm_serial_default_protocol > class tlm_serial_socket : public tlm_base_serial_socket <PROTOCOL, tlm_fw_serial_if, tlm_bw_serial_if >{ public: tlm_serial_socket() : tlm_base_serial_socket<protocol, tlm_fw_serial_if, tlm_bw_serial_if >() { } explicit tlm_serial_socket(const char* name) : tlm_base_serial_socket<protocol, tlm_fw_serial_if, tlm_bw_serial_if >(name) { } }; The tlm_serial_socket is used in the serial peripherals ONLY This socket type enables bidirectional communication by using a sc_port and sc_export on the base class as standard TLM2 initiator sockets The socket uses the serial forward and backward interfaces described before The socket has also a template parameter named PROTOCOL. This parameter is used to enable the connection only between serial peripherals and busses that implement the same protocol Synopsys

25 Serial Bus Socket template < typename PROTOCOL = tlm_serial_default_protocol > class tlm_serial_bus_socket : public tlm_base_serial_bus_socket<protocol, tlm_fw_serial_if, tlm_bw_serial_if > { public: tlm_serial_bus_socket() : tlm_base_serial_bus_socket<protocol, tlm_fw_serial_if, tlm_bw_serial_if >() { } }; explicit tlm_serial_bus_socket(const char* name) : tlm_base_serial_bus_socket<protocol, tlm_fw_serial_if, tlm_bw_serial_if >(name) { } The tlm_serial_bus_socket is used in the serial bus ONLY This socket type enables bidirectional communication by using a sc_export and sc_port on the base class as standard TLM2 target sockets The socket uses the serial backward and forward interfaces described before The socket has also a template parameter named PROTOCOL. This parameter is used to enable the connection only between serial peripherals and busses that implement the same protocol Synopsys

26 Serial Bus (without arbitration) template< typename PROTOCOL = tlm_serial_default_protocol, int NoCONN = 2 > class tlm_serial_bus : public sc_core::sc_module, public tlm_fw_serial_if { public: tlm_serial_bus_socket< PROTOCOL > *conn[noconn]; tlm_serial_bus(sc_module_name name): sc_core::sc_module(name) { } void b_send(tlm_serial_payload & payload) { tlm_serial_response default_rsp = TLM_SERIAL_INCOMPLETE; unsigned int mask = payload.get_routing_mask(); unsigned int select = payload.get_select_id(); }; } for(int c=0;c<noconn;c++) { if( (select & mask) == (c & mask) ) { (*conn[c])->nb_receive(payload); if(payload.get_status() == TLM_SERIAL_ERROR) { default_rsp = TLM_SERIAL_ERROR; } } } payload.set_status(default_rsp); Serial bus implements b_send and invokes nb_receive (twisted communication) Bus supports broadcast, multicast and unicast routing based on mask and select attributes Acknowledges are collected and returned to sender Synopsys

27 Serial Peripheral struct my_protocol { unsigned int id; unsigned int data[2]; }; class tlm_serial_peripheral : public sc_core::sc_module, public tlm_bw_serial_if { public: tlm_serial_socket< my_protocol > serial_port; public: SC_HAS_PROCESS(tlm_serial_peripheral); tlm_serial_peripheral( sc_core::sc_module_name nm ) : sc_core::sc_module(nm), serial_port("serial_port") { serial_port(*this); // TX THREAD SC_THREAD(tx_thread); sensitivity << activate_tx; // RX METHOD SC_METHOD(rx_method); sensitivity << activate_rx; } private: my_protocol mserialprotocol; Reference implementation for a serial peripheral Serial peripherals will be protocol dependent Protocol specific information is described on the structure my_protocol TX thread can be activated by an internal event triggered by SW through the register interface Since nb_receive is not blocking, for correct timing a separate SC_METHOD that handle the actions at the end of the message (e.g. set interrupts) triggered by an internal event can be used tlm_serial_payload sc_core::sc_time unsigned int tx_message; mserialclk; storage[2]; Synopsys

28 Serial Peripheral (cont.) void tx_thread(){ while(true){ // Wait until there is a message Tx request sc_core::wait(activate_tx); } } // default is broadcasting tx_message.set_prot_ptr(&mserialprotocol); tx_message.set_bit_length(100); tx_message.set_clock(mserialclk); do { serial_port->b_send(tx_message); sc_core::wait(100*mserialclk); } while(tx_message.get_status()!= TLM_SERIAL_OK); Sender side bit_lenght and serial_clock attributes are assigned for timing calculation purpose on the receiver side With a response different than TLM_SERIAL_OK then the peripheral will try to re-transmit the message void nb_receive(tlm_serial_payload & payload){ mserialclk = sc_core::sc_time(baudrate_in_us, SC_US); // Asynchonous receiver if(mserialclk!= payload.get_clock()) { // error handling payload.set_status(tlm_serial_error); return; } } my_protocol * mtemp = payload.get_data_ptr(); // Accept messages only with the same RX_ID if(mtemp->id == RX_ID){ Tmp_storage[0] = mtemp->data[0]; Tmp_storage[1] = mtemp->data[1]; int n_bits = payload.get_bit_length(); activate_rx.notify(n_bits*mserialclk); } payload.set_status(tlm_serial_ok); void rx_method() { // update status flag and interrupt interrupt.write(true); } Receiver side In case the peripheral is asynchronous the first to do it is to check that the sender clock matches the receiver clock, otherwise an error should be flag The receiver will filter messages based on its configuration RX_ID) and the protocol specific information (my_protocol->id) Synopsys

29 Synopsys Solutions for Automotive Synopsys

30 Virtual Prototyping Flow Virtual Prototyping Development Flow Software Tool Interfaces Model Libraries Block Creation Flows Component Modeling Assembly Debugging Virtualizer: VP Creation HW/SW Debug & Analysis Tools Virtual Prototype VDKs Design Tasks: SW-driven verification Virtual Prototype Use SoC HW/SW integration SW development System validation & test Supply chain enablement Co-Simulation & External Connectivity Synopsys

Assembly Debugging INTC Virtualizer: VP Creation HW/SW Debug & Analysis Tools Virtual

integration SW development System validation & test Supply chain enablement SWT XBAR FLASH

31 Virtual Prototyping Flow Virtual Prototyping Development Flow Software Tool Interfaces Model Libraries Block Creation Flows e200z6 CLOCKS & RESET e200z0 PIT Component Modeling Assembly Debugging INTC Virtualizer: VP Creation HW/SW Debug & Analysis Tools Virtual Prototype VDKs Design Tasks: SW-driven verification Virtual Prototype Use SoC HW/SW integration SW development System validation & test Supply chain enablement SWT XBAR FLASH edma STM SRAM1 SRAM2 Co-Simulation & External Connectivity (ECC) (ECC) (ECC) ADC FlexCAN Synopsys

32 Ecosystem MCU Vendors Renesas Freescale Infineon HLL Debuggers Lauterbach GreenHills PLS Physical Simulation Simulink Saber Restbus CANoe Synopsys

33 Debug and Analysis 3 rd party source code debugger Extra visibility and control with VPA Break-/Watch-point Visible assembly code Visible Register Visible Signal Task, event tracing Function, instruction tracing Internal pin and register tracing Virtual HW model Memory Memory Core #1 Core #2 Memory Timer INTC SPI CAN DMA RTC ADC I/O I/O signal tracing Host PC Synopsys

34 Connectivity Simulink Virtual Prototype Saber Custom tools Vector Synopsys

35 Agenda Automotive Overview TLM Serial Interface Synopsys Solutions for Automotive Summary Synopsys

36 Summary Virtual prototyping is moving above the SoC level to full system simulation There is a need to model (and standardize) off-chip interfaces TLM-2 cannot be applied as is, but it can serve as the technology foundation Synopsys has prototyped a TLM serial interface framework To be used on automotive applications and according to automotive requirements To be discussed with customers throughout the year Synopsys

37 Demos Synopsys

38 Synopsys Thank You

Freescale, the Freescale logo, AltiVec, C-5, CodeTEST, CodeWarrior, ColdFire, C-Ware, t he Energy Efficient Solutions logo, mobilegt, PowerQUICC,

Freescale, the Freescale logo, AltiVec, C-5, CodeTEST, CodeWarrior, ColdFire, C-Ware, t he Energy Efficient Solutions logo, mobilegt, PowerQUICC, QorIQ, StarCore and Symphony are trademarks of Freescale