Author: Laurent Maillet Contoz , STMicroelectronics, France DATE 20 Design, Automation & Test in Europe)

1. Laurent Maillet-Contoz, STMicroelectronics, France
Virtual Twins:
Modeling Trends and Challenges Ahead

2. Outline
• Flavours of Digital Twins
• Evolution of the modeling trends over the last decade
• Illustration on two examples
• Upcoming challenges
• Conclusion
2

3. Flavours of Digital Twins
IP IP
IPSOCSystem
System of
systems
Digital Twin, model of:
• Product
• Production line
• Manufacturing process
Digital Twin, model of:
• System architecture
• Interaction between
system components
Virtual Twin, model of:
• SoC architecture
• Interactions between
hardware and software
3

4. Evolution of Design Flow: the Old Days
Shift-left paradigm
Architecture Implementation DebugArchitecture Implementation Debug
Software design
Architecture Design Verification Silicon Board
Hardware design
Specification
Integration/Validation
Functionality, safety, security
Performance
Virtual
prototype /
Twin
Savings
2000’s
2010’s
1666-2011
1685-2014
4

5. Usage of Virtual Twins Nowadays
• Before development of embedded software
• Find ambiguities and contradictions in specifications
• Prototype certain aspects of the specification (performance, low-power…)
• Development of embedded software / Validation
• Implement and test maximum number of aspects of the software and system
• Mature software
• Bringup
• Tool to understand “final” software execution and remaining bugs
• Customer own developments
• Develop user parts of the embedded software
• Integrate in bigger system
Pre
Si
Post
Si
5

6. Spec to Silicon Product =
Continuum of SoC Virtual Twins
Project lifetime
SOC
SoC
Black box model
SoC SystemC
architecture model
1666-2011
1685-2014
SoC systemC /
HDL co-simulation
SOC
Specification HW & SW Specifications
CPU IP IP
IPSOC
CPU IP IP
IPSOC
CPU
IP
(TLM)
IPSOC
IP
(RTL)
CPU
IP
(TLM)
IPSOC
IP
(RTL)
=Transactor
SoC systemC /
HDL Co-emulation / Co-protoyping
= SystemC model
= RTL
= HW emulator
= SW
6

7. Typical Profile for Complex SoC
• Processing intensive
• CPU, GPU, Neural PE, Image processing
• Many I/Os
• Sensors: LIDAR, Camera, GPS, etc.
• Electronic Control Units
• Safety and security constraints!
• Unexpected behaviours
• Hardware failures
7

8. Platform Case #1:
Complex SoC
• Multi-core CPU
• DDR 3 or 4
• Clusters
• Processing (Video encode/decode, Image)
• Security (dedicated processor)
• I/O (SATA, USB, PCIe, Wifi, Ethernet, CAN,
SPI, I2C, FlexRay, MiPHY …)
• Actuation/Sampling (PWM, ADC, etc.)
• “Raw” complexity
• 20+M lines of code for software
(Linux, proprietary RTOS, etc.)
• 1 M lines of code for the models
• Complex IPs
(P10)
(P11)
IP (P4)
Processor
(P1)
Processor
(P2)
IP (P3) memory
Interconnect
Eth
Wifi
CAN
USB
(P12)
8

9. Smart Objects & IoT
• Many Applications domains
• Consumer
• Industrial
• Medical
• …
• Connectivity
• Ethernet, Industrial buses
• Bluetooth, Wi-Fi, LoRa
• Security
• Distributed systems
• Low-power
9

10. Platform Case #2:
Proliferation of Small SoCs
• MCU/MPU: Few embedded cores
• SRAM
• “Offloading” IPs (DMA, Graphics)
• I/Os: GPIO (with some PWM), I2C, SPI...
• Connectivity: USB, Bluetooth, Ethernet
• Energy efficiency
• Security
• Complexity in the distributed system
“Locally simple, Globally complex”
Sensor 1
Sensor 2
Actuator
M7
STM32
Sensor 1
Sensor 2
Actuator
M7
STM32
Sensor 1
Sensor 2
Actuator
M7
STM32
Sensor 1
Sensor 2
Actuator
M7
STM32
Sensor 1
Sensor 2
Actuator
M7
STM32
Sensor 1
Sensor 2
Actuator
M7
STM32
Sensor 1
Sensor 2
Actuator
M7
STM32
Sensor 1
Sensor 2
Actuator
M7
STM32
10

11. Modeling Trends
• Anticipation of functional embedded software development and validation
• Introspection and diagnosis capabilities in virtual twins
• Running « untestable » scenarios
• Validation of dynamic power management strategies
• Reset and clock controller, clock trees
• Wake-up, low-power modes
• Integration of security features
• Validation of the (system-of-) system
• Sensor inputs and environmental effects
• From 10+ to 1000+ node instances
• Physical/virtual device unification
• Mixing actual devices and virtual twins in a single execution
11

12. Example: BLE Device Model

13. STM32 Bluetooth Low Energy (BLE)
Virtual Twins
BLE
USART
I/O
USART Window
USART
I/O
Bluetooth
RF channel
BLE
Node 0
GPIOs
Cortex M4
STM32
subsystem
Nucleo
Panel
Cortex M0
BlueTooth
Node 1
GPIOs
Cortex M4
STM32
subsystem
Nucleo
Panel
Cortex M0
BlueTooth
13

14. STM32 BLE Virtual Twin
• Abstract Hardware + Firmware: executable specification
• BLE state machine & BLE I/F
• STM32 subsystem
• ARM Cortex M4 Instruction Set Simulator
• GPIO, SPI, USART (core functionality needed)
• RCC, EXTI, SYSCFG (partial)
• Flash Interface, PWR (stub)
• Benefits
• Early availability of Virtual Twin: low effort thanks to high
abstraction level
• Scalable to tens of nodes
• Corner case software bugs identified
Ex: illegal values programmed in clock controller
GPIO
sNucleo
Panel
BLE I/FGATT
Cortex M0
BlueTooth
Cortex M4
STM32
subsystem
14

15. Example: Sensor Node Model
for Critical Water Management Infrastructure

16. IoT Device Model
Typical Architecture
MCU
Connectivity
Sensor
Embedded
software
Open
(%)
Flow
(m3/s)
Satur.
(%)
m
Benefits:
1. System validation without constraints
of physical devices
2. Manage complexity
3. Increase flexibility and productivity
4. Increase the system reliability
16

17. Sensor Node Black Box Model
• A simple service-oriented model
• Black-box
• No detail on internal architecture
• Embedded firmware is abstracted
• Measures obtained from a file
• Early availability
• Fast execution
• Generation of data communication
to the gateway
• Used as the functional contract of
the sensor node specification
Fecha;EMALCSA/00 PRESA CECEBRE/02
Válvulas/Compuerta 3/Apertura (%);EMALCSA/00
PRESA CECEBRE/02 Válvulas/Compuerta 3/Caudal
(m3/s);EMALCSA/00 PRESA CECEBRE/02
Válvulas/Compuerta 3/Desague (%)
08/04/2019 00:25:21.871;10.11571;2.615295;9.07122
08/04/2019 00:35:21.879;10.11571;2.616884;9.061384
08/04/2019 00:45:21.887;10.11571;2.616821;9.061776
08/04/2019 00:55:21.911;10.11571;2.617014;9.060584
08/04/2019 01:05:21.920;10.11571;2.618574;9.050963
08/04/2019 01:15:21.928;10.11571;2.618614;9.050715
Post data towards gateway
17

18. Sensor Node SystemC Architecture Model
• Sensor node architectural model
includes
• Microcontroller Instruction Accurate
model
• Register accurate model of
peripherals
• Embedded software
• Running on STM32 model
• Using STM32 HAL
• Collects data from sensor model
through I2C bus
• Programs connectivity IP model to
issue communication
• Generation of data communication
to the gateway
• Conform to the functional
contract of the sensor node
Fecha;EMALCSA/00 PRESA CECEBRE/02
Válvulas/Compuerta 3/Apertura (%);EMALCSA/00
PRESA CECEBRE/02 Válvulas/Compuerta 3/Caudal
(m3/s);EMALCSA/00 PRESA CECEBRE/02
Válvulas/Compuerta 3/Desague (%)
08/04/2019 00:25:21.871;10.11571;2.615295;9.07122
08/04/2019
00:35:21.879;10.11571;2.616884;9.061384
08/04/2019
00:45:21.887;10.11571;2.616821;9.061776
08/04/2019
00:55:21.911;10.11571;2.617014;9.060584
08/04/2019
01:05:21.920;10.11571;2.618574;9.050963
08/04/2019
01:15:21.928;10.11571;2.618614;9.050715
Post data towards the gateway
Cortex M4
STM32
Connectivity
Flow
Meter
sensor
i2c
registers
Payload
(registers values)
Embedded
software
STM32 F411
ARM
CM4
I
C
N
Flash
RCC
SPI
GPIO
EXTI
Mem
PWR
I2C
SCI
SYS
CFG
1666-2011
18

19. Challenges Ahead

20. Extending the Virtual Twin
at the Next Level
• Automotive domain: the whole system is a big network!
• CAN, LIN, FlexRay, Ethernet AVB, MOST…
• How to model inter-components protocols?
• Which abstraction for the “blocks”?
• Interoperability concern for virtual twins integration
• Standardization effort still to be undertaken
https://www.hyundai.news/eu/brand/hyundai-and-cisco-to-bring-vehicle-with-next-generation-network-technology-in-2019/
20

21. Multi-system Integration
Computing farm
System
address
map
TLM IP
model
Process
or model
AMS
model
TLM IP
model
Memor
y
model
I/O
Interconnect model
• Models in different technical states
• OS, Compiler, Simulation kernel
• Heterogeneous domains
• Digital, AMS, Multi-physics
• Code sharing constraints vs flexibility
required by customers
• Replace IP X by Y
• Add customer-specific IP
• Idea: each domain in separate simulation
• Challenges: performance, semantics
• Opportunity: exploiting multi-cores?
21

22. Multi-level Twins Integration
• Address simulation speed concern
• Manage several levels of abstraction
• Guaranty functional equivalence
• Mitigate the modeling costs
• Ensure seamless integration / substitution of twins
• Interfaces interoperability
• Heterogeneous modeling languages & frameworks
22

23. Takeaways
• Usage of virtual twins for different categories of circuits
• Complex SoCs
• Smart objects
• Trends and benefits
• Early validation of embedded software & power management strategies
• Testing “untestable“ scenarios
• Integration of security features
• Manage connectivity
• Scalable validation of the (system-of-) system
• Physical/virtual device unification
• Upcoming challenges
• Expand to the next level
• Heterogeneous models integration
• Management of multi-abstraction twins
23