ID 021C: Virtual Microcontroller & System Modeling – A platform for all seasons

1. ID 021C: Virtual Microcontroller & System Modeling – A platform for all seasons Everett Lumpkin Independent Consultant 13 October 2010 Version: 1.2

2. Everett Lumpkin • Experience • 20 years tier 1 Automotive • Many virtual prototypes for Body, Powertrain, Safety and Power Electronics • Passion • Microcontroller development and simulation • SW tools focus to “bake in” quality • Neutral • No product to sell

3. Renesas Technology and Solution Portfolio Microcontrollers& Microprocessors#1 Market shareworldwide * SolutionsforInnovation Analog andPower Devices#1 Market sharein low-voltageMOSFET** ASIC, ASSP& MemoryAdvanced and proven technologies * MCU: 31% revenue basis from Gartner "Semiconductor Applications Worldwide Annual Market Share: Database" 25 March 2010 ** Power MOSFET: 17.1% on unit basis from Marketing Eye 2009 (17.1% on unit basis). (Optional)

4. Renesas Technology and Solution Portfolio Microcontrollers& Microprocessors#1 Market shareworldwide * SolutionsforInnovation Analog andPower Devices#1 Market sharein low-voltageMOSFET** ASIC, ASSP& MemoryAdvanced and proven technologies * MCU: 31% revenue basis from Gartner "Semiconductor Applications Worldwide Annual Market Share: Database" 25 March 2010 ** Power MOSFET: 17.1% on unit basis from Marketing Eye 2009 (17.1% on unit basis). (Optional) 4

5. Embedded SW; Do We Plan to Fail? • 24% of projects are canceled due to schedule slip • 54% of SW designs are completed behind schedule • 33% of devices miss functionality/performance • 80% of our effort is to correct errors that are discovered late Source: http://www.vdcresearch.com/_Documents/pressrelease/press-attachment-1473.pdf

6. Innovation – The Virtual Prototype (VP) • What if we could.... • Develop software without hardware? • Support parallel simulation of legacy 'C' code and (UML/Matlab) models? • Gain test capability? (Automated test) • Gain quality?(Monitor firmware execution)

7. Agenda • What is a virtual prototype? • Characteristics and examples • The compelling benefit ... and some new ones • How do we build it? • Not your father's instruction set simulator • Is the virtual prototype better than the bench? • AND can we afford it? • AND who will create it?

8. Automotive Body Controller Source: “Delphi Power Body Controllers”, http://delphi.com/shared/pdf/ppd/controls/body_pcm.pdf

9. Body Controller Virtual Prototype Source: “How to make virtual prototyping better than designing with hardware”, 22-Jun-2010, E. Lumpkin and C. Alford, http://www.embedded.com/design/225701094

10. Virtual Prototype – Key Characteristics • Simultaneous verification of HW and SW (co-verification) • Loads and Executes same executable image as the physical ECU (no re-compile) • Behavior models of CPU, peripherals and ASICs have bench "look and feel" to software programmer • Within1 order of magnitude of speed of the physical ECU • May be aggregated with other ECU's sensor and actuator plant models

11. Automotive Rollover System • Computer-Operating-Properly watchdog reset processor erroneously • Accelerometer device-driver read wrong register • Software segment not being initialized to zero caused an OS halt • Memory-fail register was not being reset following memory error • Math overflow problem caused late deployment of airbag by one second • Math overflow problem in timer code • Stack overrun • Bootstrap switched to PLL clock before PLL was running • Programmable timer initialized incorrectly • Asymmetrical rounding errors Source: VaST/Synopsys White Paper: "Virtual prototyping benefits in safety-critical automotive systems"C. Alford, October 21, 2005

12. Prototyping Options Source: “EDA, ESL, and more ideas from DAC” 14-Oct-2009, Synopsys- F. Schirrmeister

13. The Compelling Use Case Source: “EDA, ESL, and more ideas from DAC” 14-Oct-2009, Mentor Graphics – S. Matalon

14. VP Use Cases • “Early” SW development • For SW developers, most compelling use case • Co-Verification of Register-Transfer-Level (RTL) models • For Verification Engineers, requires both an initial virtual prototype and initial software • Architecture Exploration • For Architects, feedback architecture changes into current or derivative projects Source: “TLM+ Modeling of Embedded HW/SW Systems”, Ecker, Esen, Velton, DATE Feb 2010, http://www.date-conference.com/proceedings/PAPERS/2010/DATE10/PDFFILES/02.6_1.PDF

15. Common Misconception Once physical hardware is available, ALL software development should switch to bench development

16. Virtual Prototype – Conceptual Puzzle Legacy Embedded Code Hardware Drivers Test Automation GUIs HW Models Plant Models Simulink, UML, Labview Models

17. Build on Host • No need for these models in target code Test Automation HW Models Plant Models

18. Build on Host or Target • Simulink, UML, Labview • Natively are host compile • Can usually be "autocoded" to target • Product GUIs can usually be built on either host or target GUIs Simulink, UML, Labview Models

19. Build on Target • Host compile – possible but difficult • Target compiler extensions • Drivers may have to be bypassed/stubbed • Host compile may mask ... • Data size differences • Fixed point math • Thread concurrency issues • Target compiler issues • Hardware requirements (timing, bit order) Legacy Embedded Code Hardware Drivers

20. VP Design Tools (Example) Source: "Using the new TLM-2.0 Standard for the Creation of Virtual Platforms for ESL Design" 20-May-2008 CoWare (Dr. Tim Kogel) http://www.synopsys.com/Tools/SLD/VirtualPrototyping/pages/Webinars.aspx

21. systemC™ (IEEE Std. 1666™-2005) • Extends C++ with class libraries for system design and verification • Spans Hardware AND Software • Used for Architectural exploration, IP hardware blocks, Virtual Platforms • ESL: Electronic System Level • http://www.systemc.org

22. Transaction Level Modeling (TLM) 101 RTL Functional Model Transaction level - function call Pin accurate, cycle accurate write(address,data) RTL Functional Model Simulate every event 100-10,000 X faster simulation

23. Wireless SW"Sweet Spot" ASIC/SOC development"Sweet Spot" Automotive SW"Sweet Spot" Use Cases and Simulation Speed Use cases Software development Software performance Architectural analysis Hardware verification TLM-2 Coding styles Loosely-timed Approximately-timed Mechanisms Blocking interface DMI Quantum Generic payload Non-blocking interface Sockets Phases

24. Abstracting the details • How to pass SPI/CAN transactions? • How to represent A/D voltages? • Model VDD/VCC? • Pullup/Pulldowns? • Data Flash programming? • Code Flash reprogramming? • What are the essential things to model in a FET driver? • Does EVERY memory map register need to be modeled? Source: SAE 2004-21-0085 “Design Process Changes Enabling Rapid Development“, Winters et al.

25. In Addition to Early SW Development… • Visibility • Controllability • Availability • Repeatability • Testability • Acceptability Benefits! Source: “How to make virtual prototyping better than designing with hardware” 22-Jun-2010, E. Lumpkin and C. Alford, http://www.embedded.com/design/225701094

26. Visibility - Debugging • Bench • Limited breakpoints • Trace buffer size limitations • Lengthy bench re-flash • Virtual Prototype • Unlimited breakpoints • Trace buffer only limited by disk space and simulation time • “Instant” program load

27. Visibility – Internal MCU state • Interrupt Lock Duration • Monitor the "I" bit in the MCU Source: “How to make virtual prototyping better than designing with hardware” 22-Jun-2010, E. Lumpkin and C. Alford, http://www.embedded.com/design/225701094

28. Visibility • Example: RF Receiver to MCU • Signal changes  Value Change Dump • Internal MCU states (interrupts!)  VCD Source: “How to make virtual prototyping better than designing with hardware” 22-Jun-2010, E. Lumpkin and C. Alford, http://www.embedded.com/design/225701094

29. Visibility – Pause/Resume • Consider an internal combustion engine rotating 6000 RPM • User typically gets one meaningful opportunity to view data structures in an interrupt routine • Upon resume: • Bench: Several pending interrupts then execute in priority order, but not real-time sequence • VP: Synchronous pause and resume of engine controller model • Multi-core further accentuates need! Source: “How to make virtual prototyping better than designing with hardware” 22-Jun-2010, E. Lumpkin and C. Alford, http://www.embedded.com/design/225701094 (Optional)

30. Controllability • De-bounce switch after 78us "on" • Perl script used to precisely control stimuli Discovered firmware race conditions! Source: “How to make virtual prototyping better than designing with hardware” 22-Jun-2010, E. Lumpkin and C. Alford, http://www.embedded.com/design/225701094 (Optional)

31. Controllability – Fault Injection • Induce conditions that normally require custom hardware variants. For a FET driver ASIC: • Short to ground • Open output • Thermal overload • "Checkbox" on GUI to induce fault • MCU read of ASIC (via SPI) acts as if fault has occurred

32. Virtual Bench  data/scripts  Physical Bench Source: SAE 2008-21-0043 "Adaptation of a “Virtual Prototype” for Systems and Verification Engineering Development“, Chandrashekar et al.

33. Repeatability Physical Bench Virtual Prototype Source: “How to make virtual prototyping better than designing with hardware” 22-Jun-2010, E. Lumpkin and C. Alford, http://www.embedded.com/design/225701094 (Optional)

34. Trends • Multi-core systems will REQUIRE virtual prototyping • Synchronization solution for complex debugging issues • Some domains (automotive) will demand VPs to address multi-core • Multi-core workstations enable the simulation of BIG systems Source: “How to make virtual prototyping better than designing with hardware” 22-Jun-2010, E. Lumpkin and C. Alford, http://www.embedded.com/design/225701094

35. Testability • Save money and increase safety via experiments • Validate design with multiple grid simulation of virtual prototypes • Allow testing where physical prototypes may be unsafe or inaccessible • Entire system may be large Source: “How to make virtual prototyping better than designing with hardware” 22-Jun-2010, E. Lumpkin and C. Alford, http://www.embedded.com/design/225701094

36. Testability – Extensive Model Warnings • Alert user of specification violations • “Omnipotent FAE watching the Software Development” • Typically 2-20 warning messages per ASIC/peripheral • VP is good complement to existing verification techniques Source: “How to make virtual prototyping better than designing with hardware” 22-Jun-2010, E. Lumpkin and C. Alford, http://www.embedded.com/design/225701094

37. Example: Internal MCU Warnings “WARNING: EEPROM1 data read from address 0xXXXX while in the write state” • Other real examples: • Illegal Memory Access • Turn on timer prior to proper initialization • Power off UART or SPI while still receiving data • Alert to a user manual caution: Switch of timer from “interval count” to “capture mode” – Must disable timer first to avoid a meta-stability issue. Source: “How to make virtual prototyping better than designing with hardware” 22-Jun-2010, E. Lumpkin and C. Alford, http://www.embedded.com/design/225701094

38. Availability • Which bench do you want to ship to Mexico or India? • Which bench is easier to modify? Source: “How to make virtual prototyping better than designing with hardware” 22-Jun-2010, E. Lumpkin and C. Alford, http://www.embedded.com/design/225701094

39. Time Check • 25 minutes or less?Take two questions Our Agenda... • What is a virtual prototype? • Characteristics and examples • The compelling benefit ... and some new ones • How do we build it? • Not your father's instruction set simulator • Is the virtual prototype better than the bench? • AND can we afford it? • AND who will create it? (Optional)

40. Visibility Deep investigations Internal signal and state visibility Unlimited breakpoints and trace history Debugging easier Bypass lengthy bench re-flash Faster edit-test cycle Better SW analysis results in fewer defects Controllability and Repeatability Deterministic – Precise applied stimuli allows study/control of race conditions Hardware variants  Config files Induce faults easily and repeatedly Better SW control results in fewer defects Once physical hardware is available, ALL software development should switch to bench development Use Case for Post-Silicon (Optional)

41. Use case for post-silicon • Availability • Embedded development simply requires more setup and care than server/desktop software • Power supplies, oscilloscopes, voltage and current meters, debuggers, static and dynamic test panels  $$$ • Changes to embedded system are easier to deploy in virtual prototype (Optional)

42. Acceptability – Non-Technical • "It's different“ • Answer: Mimic debuggers, scripting and GUI of real bench • "Not as accurate as hardware” • Accuracy or Ambiguity? • Modeling helps clarify the HW specifications • "It's not real hardware” • Pilot test – Develop w/o HW Source: “How to make virtual prototyping better than designing with hardware” 22-Jun-2010, E. Lumpkin and C. Alford, http://www.embedded.com/design/225701094

43. Acceptability – Non-Technical • Virtual Prototype not tangible • Hidden on Developer desktops • Until budget (hunting) season... • "Models not available" – Tough issue Source: “How to make virtual prototyping better than designing with hardware” 22-Jun-2010, E. Lumpkin and C. Alford, http://www.embedded.com/design/225701094

44. Where do I get the Models? Model availability is a Roadblock!

45. Renesas MCU models • Most popular EDA vendors have, or are willing to develop, the necessary CPU models • Renesas has the most extensive library of high speed peripheral models (V850, R32C, SH2A, SH4A families) • Unfortunately many of these have customer specific abstractions and business arrangements

46. Who will create the Virtual Prototype? • Semiconductor Provider • Has domain expertise for MCU peripherals • Can leverage systemC / ESL methodologies • ESL tool provider • Typically offers the CPU/ISS portion of the simulation • Contract services for a specific design • Offers value for infrastructure technology (ESL, tools) • Self grown modeling team • Integrate the MCU and component models • Close coordination with software team and milestones • Access to hardware (schematic) • Domain knowledge • End User • Graphical environment, watch for point solutions • Difficult to optimize the ROI

47. Model Availability – The Hard Truth • The models you really need are not available! • MCU libraries are customer – not supplier driven • Your plant models must be custom developed • Potential Solutions • Amortize cost of model development (share!) • systemC and TLM 2.0 • Automotive: Why do Toyota, Bosch and Delphi all independently develop model libraries? • Raise the level of abstraction • Hint: “TLM+ Modeling of Embedded HW/SW Systems”, Ecker, Esen, Velton, DATE Feb 2010

48. Summary • VPs have big (SW) value before HW avail. • systemC/TLM is aiding the silicon design process • Value even when HW is available • Visibility, Controllability, Repeatability, Availability, Testability • Multi-core will both drive and enable VPs • But VPs remain expensive to develop • As demand increases there will be more cost sharing

49. Questions?

50. Innovation – The Virtual Prototype (VP) • What if we could.... • Develop software without hardware? • Support parallel simulation of legacy 'C' code and (UML/Matlab) models? • Gain test capability? (Automated test) • Gain quality?(Monitor firmware execution)