Simulating Auto Systems & E/E Architectures for Power and Performance using VisualSim
- 1. Automotive Webinar Simulating Auto Systems & E/E Architectures for Power and Performance
- 2. Webinar Logistics Ask a Question Audio and Video Turned off
- 3. Simulating Auto Systems & E/E Architectures for Power and Performance Using VisualSim Architect
- 4. System Exploration is Comprehensive • Network- TSN, CAN • Hardware- ECU, gateways • Software- Firmware, OS • Semiconductor- IP, Processors • Security- Cyber-Physical attacks and Failures • Applications • ADAS mapping on distributed ECUs • Cybersecurity • Infotainment • Safety and mission-critical • Auto Server How to Evaluate all of these in one single Environment?
- 5. Modeling of Automotive System for Architecture Trade-off Software sequences executed on hardware SW1 GW1 SW2 DRAM Display IO A M B A A X I B u s CPU GPU Display Ctrl P C I e Video Camera SRAM 2 1 3 4 Automotive Network NoC/ UCIe AI Engine Tiles Warp Scheduler PE PE PE PE Local Mem GPU HBM2 Chiplet ADC DDR5 Processor subsystem Core L1 B u s SLC Detailed ECU hardware Semiconductors And this forms a Complete Automotive Design Environment
- 6. VisualSim Statistics for Hardware, Network, Software and Power Stats Value L1_I Hit Ratio 99.2% L1_D Hit Ratio 95.8% L2 Hit Ratio 82.3% L1_I Mean Latency 14.62 nsec L1_D Mean Latency 20.1 nsec L2 Mean Latency 50.5 nsec Software Network Power Systems Semiconductors
- 7. System Architecture Exploration and Trade-Offs • Network Analysis • Application-driven network planning • Multi-protocol (CAN + TSN) and multi- agent traffic • External interfaces- vehicles, roads and data centers • ECU Hardware • Hardware Selection and Sizing • Hardware-Software Partitioning across multi-processor and multi-core • Application-support across multiple ECU on multiple network • Semiconductors • Integration of analog and digital • Designing complex SoC with CPU, GPU, NPU, Accelerators, Memory and Interfaces • Transitioning to chiplets • Power Systems • Generation, Storage (Battery), Distribution, Consumption, Management and Thermal • Security and Failure • Intrusion and signal-based • Errors, bottlenecks and loss of resources
- 8. Consider the Automotive Communication Network GW GW TSN SW TSN SW Camera LiDAR Brake ECU RADAR Camera LiDAR ADAS ECU Engine ECU CAN ABS ECU Transmissi on Control Unit Power Steering TSN SW TSN SW EPS ECU RADAR EMS ECU Camera Display Camera RADAR Body ECU CAN Adaptive Front Lamp Power Steering Climate Control Network Capacity, Planning and Topology Security Features Number of Gateways TSN & CAN Assignment Scheduler Selection Bandwidth Buffer Size ECU Assignment To TSN/CAN Processor Selection SoC Design Speed Number of Sensors/ECU Communication To Data Center Data Center Vehicles Road Services Effective Throughput Latency
- 9. Consider Automotive ECU and Semiconductor NoC/ UCIe AI Engine Tiles Warp Schedule r PE PE PE PE Local Mem GPU HBM Chiplet ADC DDR5 Processor subsystem Core L1 B u s SLC Select the right processor and the clock speeds Size the interconnects and mesh Minimize peak power and design power management algorithm Measure the latency, throughput and power for workloads Round-Trip Latency Which one is it? Neoverse/A720/RISC-V/Tensilica Lx8 Number and type of GPU and TPU Cores What is the AI Clock Speed? Optimal Mesh size Peak power Thermal heat and temp Management Number Port & Modules Interface Buffer Interconnect Speed Throughput Buffer Usage Consider this Hardware Architecture Workloads, Benchmarks, Traces and Software Googlenet/Alexnet/CNN Spec2017 Synthetic Workloads uBench Number Of Slices
- 10. Mirabilis Solution: Enabling System-Level Exploration Architecture Block Diagram Model using System-level IP and Workloads Parameters & constraints Regression Sweep Generate statistics and specification BLOCK METRICS CONSTRAI NT CONSTRAINT VALUE STATISTIC TYPE Processor Cache A_Hit_Ratio >= 0.7 All System Cache A_Miss_Ratio < 0.2 All NoC Input A_Number_Entere d >= 175 All NoC Router Buffer_Occupancy < 6 All AXI Bus Activity Read_Data_Bytes >= 1.00E+07 All CMN_XP Buffer_Overflow >= 10 All Workload1 Latency < 1.23E-06 Mean Workload_2 Latency < 4.60E-03 Max Workload_3 Latency < 6.00E-05 Min DMA Channel Utilization < 70% All HW Interface Asset Mgmt Communication Generation Repeat Trade-off And Optimize
- 11. VisualSim System-Level IP Library VisualSim System-Level IP Library Quantity and Time Queue System Resources Scheduler RTOS Builder, ARINC 653, AUTOSAR Task Graph, Workload Builder Stochastic and Software SoC Compute, Interconnect and Hardware Systems and Networks Traffic Custom Builder Distribution- and Trace-based Sensors, VCD, Network, Sequence Scripting language RegEx C/C++/Java/Python Wrapper Statistics Latency, Throughput, Utilization, hit-ratio Ave/peak power (instant, ave) Heat, Temp TSN, AVB, 10BaseT1S, Switched Ethernet Resilient Packet Ring, RP3, WiFi 802.11 Bluetooth, PAN, Spacewire, SpaceFibre IEEE802.1Q, Time-Triggered Ethernet AFDX, 5G VME, PCI/PCI-X/PCIe 6.0, CXL, SPI 3.0, 1553B, FlexRay, CAN-FD/XL AFDX, TTEthernet, OpenVPX AMBA (AHB/ APB/ AXI/CHI),Tilelink Corelink (600, 700), NoC (Generic, Arteris), Virtual Channel, DMA, Crossbar, Serial Switch, Bridge, UCie CPU, DSP, GPU, TPU, MCU ARM (M0-55), R5, Cortex (A8, A72, A53, A76, A77, A65, A78, A720, Neoverse V and X), Nvidia- Pascal to Ampere, Leon, Power, X86, DSP & ADI- TI, Tensilica- Lx8, Renesas, AI RISC-V SiFive In-Order/Out-of-Order Flash, NVMe, Disk, SSD, NAS, Fibre Channel, FireWire, HBM3.0, HMC • Memory Controller, Disk, SDR DRAM 2-5, LPDDR 2-5-X, SSD QDR, RDRAM, MPMC, Cache, Coherent cache Storage and Memory FPGA Xilinx- Versal, Zynq, Ultrascale, Kintex Altera-Stratix, Arria Microsemi- Smartfusion Programmable logic generator Power States, Allocation Transition, Loss, Battery Consumption, Management Generation, Distribution and Thermal Power Communication RF Tx/Rx, Baseband, Channels, Analog, A/D transceivers, Antenna Signal/audio/Image algorithms
- 12. Comparing VisualSim and Physical Implementation • Simulation results comparison with physical prototype, 92-98% accuracy, for various use cases – • Different traffic rates (40 Mbps vs 90 Mbps vs 150 Mbps etc.) • Different bandwidth reservation for AVB classes –using sendslope and idleslope parameters • Different Scheduling algorithms – Strict Priority, Round Robin, TSN Scheduler (Time Aware Shaper) etc. • Single Node results were used to scale to 124 Node network Data from Real Board Results from discrete- event model
- 13. VisualSim Solution VisualSim with libraries Quickstart Training Modeling services Analysis and insight Integration The Offerings The Product
- 15. Modeling Vehicle Network with abstract HW and SW Model the entire Vehicle for a realistic analysis
- 17. Evaluation Stats for 124 node Network ADAS application latency is higher in 124 node that in a 5 Node network • 6.8 msec vs 1.42 msec • Concurrent traffic and contention in a larger 124 node network • Scheduling algorithm being used was Strict Priority and hence Class A (Priority 5) frames were passed over by Priority 6 and 7 frames • Per packet analysis across TSN Switch for all nodes • Buffering • Network latency • Bandwidth utilization • Buffer overflow across TSN Switch (SW2) as a result of insufficient bandwidth being allocated for Best Effort frames
- 18. Automotive Hardware and Software Requires Multi-ECU and Sensor Integration
- 19. ECU Performance under Different Use Cases Model environment 1. Brake ECU integrated to a CAN Network 2. Sensors write data to the memory 3. Brake Pedal or Proximity sensor triggers the braking action from the Brake ECU ECU Using a processor for the Brake ECU Analysis 4. Latency (Time taken for the signal to reach all the wheels from the Brake ECU) 5. Processor performance (MIPS) 6. Power Consumption (Breaking activity, ECU usage and Network activity) Wheel 1 Wheel 4 Wheel 3 Wheel 2 Gateway CAN Bus Engine Proximity Sensor Brake Pedal Gyro Sensor Road condition sensor CAN Bus CAN Bus ECU Gateway Transfer messages between different CAN networks CAN Bus CAN bus is the network that connects sensors and ECU’s
- 20. Translating into VisualSim Block Diagram N CAN Wire CAN Node Wheel1 Wheel2 Wheel3 Wheel4 Brake Pedal Proximity Sensor Gyro Sensor Gateway ECU Road condition sensor Engine CAN BUS CAN BUS CAN BUS N N N N N N N N N N N N N
- 21. VisualSim Model of the Braking System Network Gateway Hardware Failure Generation Setup
- 22. 28/01/2025 Mirabilis Design Inc. 22 Configuration of the ECU/Processor Processor Spec 1. Processor (ECU) 5 Pipeline stages 2. Number of core 1 - 2 2. Processor Speed 800 MHz - 1.2GHz 3. DRAM Type DDR3 SDRAM (Synchronous DRAM) 4. DRAM Speed Range 400 – 1066 MHz 5. Cache Speed 500Mhz 6. Cache Size 64Kbytes 7. Memory Controller DDR3, 750MHz 8. Bus CAN ECU Data input 1. Wheels 2. Engine 3. Proximity Sensor 4. Brake Pedal 5. Gyro Sensor 6. Road Condition Sensor
- 23. 28/01/2025 Mirabilis Design Inc. 23 Results – Multi-Core Processor System Slight improvement in Processor Task Latency in few instances
- 25. Architecting Hardware-Software for Infotainment System DRAM Display IO A M B A A X I B u s CPU GPU Display Ctrl P C I e Video Camera SRAM Packet • System Overview • Camera ： 30fps, VGA corresponds • CPU ： Multi-core ARM Cortex-A53 1.2GHz • GPU ： 64Cores(8Warps×8PEs), 32Threads, 1GHz • DisplayCtrl ： DisplayBuffer 293,888Byte • SRAM ： SDR, 64MB, 1.0GHz • DRAM ： DDR3, 64MB, 2.4GHz Explore at the board- and semiconductor-level to size uP/GPU, memory bandwidth and bus/switch configuration
- 26. System Model of an Infotainment System NXP i.MX6 / nVIDIA Drive PX Xilinx FPGA Kintex 8 Discrete DMA ARM A53 GPU Display Ctrl SRAM3 DRAM3 Video IN Parameters Video OUT
- 27. Conducting Architecture Trade-off • By changing the amount of video input data (packet number), observe the SRAM -> DRAM transfer performance and examine the upper limit performance of the video input that the system can tolerate. 210Packet/Sec 12ms 21Packet/Sec 41.4us 300Packet/Sec • 250 Packet/Sec is the system limit • With 300 Packet/Sec, simulation cannot be executed due to FIFO buffer overflow.
- 28. Software and OS Autosar and RTOS Trade-off Abstracting Hardware Architecture using System Resources
- 29. ADAS Logical to Physical Mapping in VisualSim Engine function Brake function EPS function Body function ADAS function1 Other functions Engine ECU Brake ECU EPS ECU ADAS ECU ADAS function2 ADAS function3 ADAS functions Other ECU Gateway ECU Other ECU Logical arch Physical arch Other ECU Move to another network layer Map to physical ECU CAN BUS LIN Trade-off mapping applications and services across distributed ECU network
- 31. Example 1: Current SoC Architecture with Single Die CPU CMN DRAM Task Graph
- 32. Example 1: New SoC Architecture with Chiplets and UCIe SoC_with_A720AE_4Clusters_UCIe_Demo_flow.xml CPU CMN DRAM Task Graph UCIe Links Die 1 Die 2
- 33. Comparing Monolithic vs Multi-Die Architectures Multi-Chiplet Analysis Monolithic Die Analysis
- 34. HPC Heterogeneous Compute for Edge Processing Integrating AI tiles with HBM
- 35. Challenges faced An operation in the ALU require 4 memory accesses. 2 for the operand data, 1 for the partial sum from previous operation and 1 for storing the result. If this memory access is made to off chip memory, then there will be significant power consumption Need for specialized hardware Source – Intel press report, MIT charts Moors law – Transistors are not getting efficient Carbon footprint – Neural networks produce carbon footprint at higher orders of magnitude
- 36. Hardware accelerator for deep learning Hardware Architecture - Processing Elements(ALU + Register memory (< 1KB)) + NoC + Memory Challenges – • Power Consumption cannot be predicted - Depending on the workloads and AI model used, power consumption will be different • Hard to determine the cause of bottleneck – Lower throughput or MACs/second could be due to lower cores or due to lower data reuse or due to increased off chip memory access
- 37. Mask Region-CNN (MR-CNN) for object detection and image segmentation Overall representation of Mask R-CNN model Network Architecture of Mask R-CNN output CPU Preprocessing CPU Postprocessing
- 38. VisualSim Model Application sequence from Task Graph is mapped to HW architecture • PE – 12x14 • 4 memory hierarchy • Power computation per PE, Buses and memory
- 39. Results – Base model (168 AI Cores, 90% data availability at SRAM) • Peak Power consumption at around 10.8 Watts • Obtained FPS = 0.414
- 40. Results – 8x8 (64) cores, 90% data availability at SRAM • Peak Power consumption at around 5.6 Watts as the number of cores were reduced • Obtained FPS = 0.29, which is lower than the base model results as the number of resources for doing MAC operations were lower
- 41. Results- 100% data availability at SRAM, 168 cores • The number of off chip memory accesses were reduced. The only accesses made were to load the images and weights into the SRAM • Obtained FPS = 9.93, which is higher than the base model results as the number of off chip memory accesses were reduced • Peak Power consumption (10.4 W) is lower as off chip memory accesses were reduced
- 42. Power Modeling Consumption, Management, Test Benches and Thermal
- 43. Power Generation Power Storage Power Consumption Thermal Management • Different charging schemes • Impact of surge and shocks • Battery Lifecycle • Battery Consumption • Statistics • Heat and temperature • Impact of cooling strategy • Add impact of power spikes • State based power consumption of electronics (controller, SOC) and Mechanical (brakes, wheels) • Average, instant and Cumulative • Power per device and application Verification and Debugging • 4 Types of Power Generators in VisualSim • Constant, variable, motor, solar charge • Charge sent to battery 1 2 3 5 6 • Optimize and test the power management algorithms • Sizing of power generators and battery • Optimize the schedule, supplynet and voltage • Estimate power consumed by the software application Downstream Integration • Generate UPF file with power domains and associated voltage levels • Generate SystemVerilog power testbench • Generate powerState change VCD dump 7 Power Management • Change in power state controlled by time, utilization, temperature and expected activity 4 Integrate Power and Thermal into the Performance Model
- 44. Behavior Task Graph Power Table Power management Unit SystemVerilog Output for Power System Test VCD Waveform for Verification create_power_domain PD_Top -include_scope create_power_domain -name PD_1_2.0 -elements {"CLKMUX"} create_power_domain -name PD_1_1.0 -elements {"PLL","G2","G3"} create_power_domain -name PD_1_3.0 -elements {"PROC"} create_supply_port -port VDD_1.0 -direction in -domain PD_Top create_supply_port -port VDD_2.0 -direction in -domain PD_Top create_supply_port -port VDD_3.0 -direction in -domain PD_Top create_supply_port -port VSS_0.0 -direction in -domain PD_Top create_supply_net VDD_1.0 -domain PD_Top create_supply_net VDD_2.0 -domain PD_Top create_supply_net VDD_3.0 -domain PD_Top create_supply_net VSS_0.0 -domain PD_Top connect_supply_net VDD_1.0 -ports VDD_1.0 connect_supply_net VDD_2.0 -ports VDD_2.0 connect_supply_net VDD_3.0 -ports VDD_3.0 connect_supply_net VSS_0.0 -ports VSS_0.0 add_power_state PD_1_2.0 -state Active {-supply_expr (VDD_2.0 == {ON, 2.0}) && (VSS_0.0 =={ON,0.0})} add_power_state PD_1_2.0 -state OFF {-supply_expr (VDD_2.0 == {OFF, 0.0}) && (VSS_0.0 =={ON,0.0})} add_power_state PD_1_1.0 -state Active {-supply_expr (VDD_1.0 == {ON, 1.0}) && (VSS_0.0 =={ON,0.0})} add_power_state PD_1_1.0 -state OFF {-supply_expr (VDD_1.0 == {OFF, 0.0}) && (VSS_0.0 =={ON,0.0})} add_power_state PD_1_3.0 -state Active {-supply_expr (VDD_3.0 == {ON, 3.0}) && (VSS_0.0 =={ON,0.0})} add_power_state PD_1_3.0 -state OFF {-supply_expr (VDD_3.0 == {OFF, 0.0}) && (VSS_0.0 =={ON,0.0})} Power Modeling Integration
- 45. Heat(J) and Temperature (°C) statistics With poor cooling Time_to_Reduce_1_Degree = 1.0 With better cooling Time_to_Reduce_1_Degree = 1.0e-8 Heat (J) is lower with better cooling Temp (°C) is lower with better cooling
- 46. Cyber Security and Failure •System performance under failure – Message Loss and Incorrect Addressing •DDoS attack on Inter Vehicle Communication
- 47. Case Study 1: System performance under failure Different types of faults were injected into our discrete event model in order to evaluate the behaviour of system under faults
- 48. Results No Faults injected Message Loss injected Incorrect Addressing
- 49. Resource usage extremely high due to continued high traffic levels Case Study 2 : DDoS Attack in Inter Vehicle Communication A DDoS attack involves multiple connected devices, collectively known as a botnet, which are used to overwhelm a target vehicle with fake/malicious traffic. • Virtually emulating the System behavior using DDoS attack technique • Simulation methodology is designed to test automotive systems for cyber security and safety that are under development • Evaluate Risk assessment on network simulation can predict how the interaction of restrictions and behavior may affect overall network hygiene. • Moreover, testing multiple potential settings can aid in finding a near-optimal configuration for restrictions. • The above design analyze the overall throughput and latency on the network under attack. High Delay in processing request result in low throughput What is DDoS? DDoS Attack Outcomes ? Analyze the System Design and find best optimal configuration High Resource Usage due to Attacks on On-Board Units. Unable to discern between normal and attack traffic OBU Diagnostic DDoS attack on larger node N/W gives us an idea on where the network bottlenecks and stress points are located as it resembles the real network
- 50. Results Normal Operation Under Attack Significant bursts in response times are observed Very high buffering across network
- 51. About Mirabilis Design Automotive Design and Integration Environment
- 52. Mirabilis Design EDA Software Company based in Silicon Valley Integrating sub-system teams to the OEM Flow using System-Level Design Highly experience Management and Engineering team Over 150 man-years of background in semiconductors, automotive and aerospace VisualSim Architect –Design the Right product Graphical modeling and simulation platform with complete set of system-level modeling IP Eliminate all surprises prior to integration Optimizing specification, collaboration between OEM, Tier One and suppliers, evaluating use-cases and identify test scenarios for system validation Networking 18th companies & 32nd universities Electronics Modeling 35th customer 2008 Company Incorporated 2011 First Engagement with HP and ISRO 2013 Announced VisualSim 2014 University Program 10th Customer 2015 Stochastic and Network modeling 2016 2018 2019 Automotive & Avionics 2020 System-level IP Open API 2022/23 Re-engineered AI, DNN, Power, GPU 2021 Requirements Tracking 60th customer Best Embedded Paper at DAC 2024 – Second time in 3 years
- 53. Conclusion • Single platform for all companies to collaborate on the architecture • Performance, power and functional statistics prior to development • VisualSim library of System-level IP covers all modeling requirements • Eliminate all surprises and bottlenecks prior to development • Seamless integration with other simulators and code
- 54. Automotive Webinar Simulating Auto Systems & E/E Architectures for Power and Performance