Mirabilis Design is a software company that develops VisualSim Architect modeling and simulation software to optimize system specifications prior to development. The software enables power-performance-area modeling and simulation of semiconductor systems and software. It uses dynamic simulation and evaluation of power, timing, and behavior using a single system model. This achieves 95%+ accurate power measurement during architecture exploration. The software separates behavior and architecture and supports multiple abstraction levels in a single model to optimize system designs early in the development process.

1. MIRABILIS DESIGN LEADS SYSTEM DESIGN INNOVATION
How to achieve 95%+ Accurate
power measurement during
architecture exploration?

2. About Mirabilis Design
Software Company based in Silicon Valley
Goal is to optimize and validate system specification and eliminate bottlenecks prior to
development and integration
Development and Support Centers
USA, India, China, South Korea, Japan and Europe
VisualSim Architect - Modeling and Simulation Software
Power-Performance-Area modeling and simulation of Semiconductor, systems and
software
Digital Enablement of the Electronics Product Development Front-End
Market Segments
Semiconductors, Automotive and, Aerospace and Defense
Design Enablement
Architecture trade-offs, system validation, early functional testing and communication
Networking

3. VisualSim System Design
VisualSim
Architect
• Graphical and
Hierarchical
Modeling
System-Level IP
• Parameterized
components
• Hardware, software
and networking
• Contains power,
timing and behavior
Open API
Import and export
models, traces and
custom output
formats
Integrated
Systems
Engineering
Requirements
Multi-core
Regression
AI-based decision
Cloud and Desktop Version available
Key Innovations
• Dynamic simulation and evaluation of power,
timing and behavior using a single model
• Parameterized library components of software,
component builder and vendor hardware
• Separation of Behavior and Architecture
• Multiple-level of abstraction in a single model
• Single-event calendar to integrate analog, digital
and external simulators
• Full-suite of statistics and Generator-API for
product generation

4. Concept of VisualSim Power Technology
Based on system model activity and state change logic
◦ Covers task-based power, transitions, management logic
◦ Incorporate the hardware, software and network
Looks at each of the entities in detail
◦ Generation from multiple sources- wind, solar, motor, steady, custom
◦ Storage- looks at various types of batteries
◦ Consumption at various rates by multiple devices and different clock speeds
◦ Management based on time and custom logic
Generate power profile for downstream test
◦ Average, instant, battery life, usage, comparison between input, available and consumed
Triggered with use-cases, workloads, traffic and traces
◦ Average, instant, battery life, usage, comparison between input, available and consumed
Power is now an integral part of Architecture Exploration
Block Power Mode Diagram
Function 1
Function 2
Function N
.
.
.
Functional
Portion
Timing 1
Timing 2
Timing N
.
.
.
Timing and Resource
Portion
Block Functional and Timing Diagram

5. System Power Accuracy
Benchmark FPGA VisualSim Difference Comments
ED1 5.94ms 6.425ms 7.55% Integer processing
MM 12.084ms 11.863ms 1.08% Most load operations
with random addresses
MM_st 13.984ms 14.65ms 4.5% Most store operations
with random addresses
Test System
Xilinx Ultrascale+ Zynq® UltraScale+™ XCZU9EG-2FFVB1156E MPSoC running on the ZCU102 board
Specification: 4 core ARM Cortex A53 @ 1200Mhz; 32KB i-cache; 32KB d-cache, 1MB L2; 2GB DDR4 DRAM 2400
ARM Cortex A53 Processor Accuracy
Frequency Simulated
Power
Measured
Power
Delta
percentage
500.0 Mhz 0.037 W 0.038 W 2.63%
600.0 Mhz 0.053 W 0.051 W -3.92%
800.0 Mhz 0.097 W 0.090 W -7.77%
1000 Mhz 0.157 W 0.159 W 1.25%
1200 Mhz 0.233 W 0.227 W -2.64%
1300 Mhz 0.277 W 0.269 W -2.97%

6. Power Modeling Abstraction
Power must be evaluated at:
Mission engineering
Network of Systems
Boards and Semiconductors
Each level of abstraction needs data from the level below
IP to Semiconductor to Systems to Missions
Dynamic data for all possible is required to test specific use-cases
Extrapolation of data from specification can be vastly incorrect
Data is provided for specific clock speeds to interconnects
Power impacts battery size, generator capacity, thermal, packaging and cost

7. Power Modeling Requires Analog, Digital,
Software, Transmitter/Receiver and Antenna
Baseband
Microwave
Antenna Power must incorporate all
devices or IP in the system
Traffic or workloads traverse
entire system, not a block

8. VisualSim model of SoC Architecture running MPEG
Mirabilis Design Inc. 8
Use Cases

9. SoC Power Intent Overview

10. SoC Device Power Definition
Subsystems and IPs whose power to be
tracked are listed here. Power state
values are linked to variables which are
defined in the “ExpressionList” section
The voltage and current values from the
document are used to calculate the
power for different states of each
device

11. Power-Performance-Area Trade-Off
Observations:
1. Avg power consumption
within requirements
(<1.0 W)
2. Performance requirement
not achieved (Only a max
of 1.419K frames)
3. Total Area = 442.8 mm sq

12. SoC Power Statistics
These detailed stats were
used to verify whether the
simulation results match the
data specified in the vendor
documents

13. Power State Transition Log
Current Time
Power in Watts
Current power state
Device name

14. Power Activity Diagram
Device activity
graph – identify
when each of the
devices are
active and their
sequence of
operation.

15. Power, Heat, Waveform and Temperature

16. Intermediate Power Representation
Generated UPF and Test Benches
Generated UPF File
Generated Test Benches using SystemVerilog and UVM Methodology

17. Capture Requirements from SysML/
Database into VisualSim Diagnostic Block
• Requirements from SysML is
imported using Diagnostic block
• Requirements are stored in the
form of csv files
• Requirements are continuously
tracked throughout simulation
SysML VisualSim Architect

18. Parameter Regression on Multi-Core
Different parameter combinations based on the
configured ranges are generated and simulated

19. AI-Based Study using Requirements
• Run number 19 – clock
frequency at 1000 MHz satisfied
the performance requirements
we had set.
• Since the frequency was
increased from 600 MHz, the
total power consumption went
up while running the system at
1000 MHz
• Architect can evaluate
different processing
resources – DSP vs Xeon
cores vs Power cores if
they have stringent power
thresholds
Requirements being evaluated for each simulation
run in the parameter sweep
Overall Results – We can identify the simulation runs which
meet the requirements and select the right configuration
after considering cost vs performance trade-offs

20. Generating Documentation - Interactive

21. Functional Unit Testing
Software load and
FPGA/Emulator

22. Co-Simulation with FPGA and Emulators
11/15/2023 MIRABILIS DESIGN INC. 22
Provide dynamic testbenches
and golden reference Connect to Emulator and
real system

23. System-Level Power
Modeling
Translating Data Sheet to
Power Intent

24. Using datasheet from NXP –
Document Number: IMX8MDQLQIEC
• This document provides detailed
information on power architecture and
the necessary details to setup the power
table
Source - https://www.nxp.com/docs/en/data-
sheet/IMX8MDQLQIEC.pdf

25. Capture - Voltage and Current values
• RUN state in the document
will be considered as
“Active” state in Power
Table
• IDLE state in the
document, based on the
description, is same as
“Standby” state in Power
Table
• For the Max current, the
median value of the range
was considered.
• For ARM subsystem,
since it has 4 cores,
the median value was
divided by 4
For voltage, Typical (Typ) values were used

26. Power Table using NXP Values
Subsystems and IPs whose power to be
tracked are listed here. Power state
values are linked to variables which are
defined in the “ExpressionList” section
The voltage and current values from the
document are used to calculate the
power for different states of each
device

27. Mission Modeling

28. Evaluating Space Vehicle Orbits
List of Tasks
Task in Each Orbit

29. MIRABILIS DESIGN LEADS THE SYSTEM DESIGN INNOVATION
Advanced Capabilities

30. Battery
Used to capture
◦ Rate of consumption
◦ Impact of continuous charging
◦ Lifecycle loss due to power spikes and thermal shock
◦ (Experimental) Heat and Temperature
Types of batteries support
◦ Battery database support NiCd, Li-Ion, NiMh, LdAcid
Activities modeled
◦ Charging- SOC threshold, Turbo charge, all input charge
◦ Discharge- From the PowerTable
◦ Lifecycle, discharge

31. Power Generator
Time-Energy
◦ Constant Power Source
◦ File Based
◦ Time Based
Motor-Energy
◦ Motor Based Power Generation
◦ Wind Based Power Generation

32. Advanced Power Modeling
powerUpdate() RegEx is used here to update the device
power state. If the current power state is same as the
required power state, then no updates were made.
G2_OFF G2_S*Switch_Leakage(G2_V)*G2_Vin ;
G2_Sleep clk*G2_Vin*NDP*G2_Vin+G2_A*LBV(G2_V)*G2_Vin+G2_S*Switch_Leakage(G2_V)*G2_Vin ;
G2_Act clk*G2_Vin*NDP*G2_Vin+G2_A*LBV(G2_V)*G2_Vin+G2_S*Switch_Leakage(G2_V)*G2_Vin ;
G3_OFF G3_S*Switch_Leakage(G3_V)*G3_Vin ;
G3_Sleep clk*G3_Vin*NDP*G3_Vin+G3_A*LBV(G3_V)*G3_Vin+G3_S*Switch_Leakage(G3_V)*G3_Vin ;
G3_Act clk*G3_Vin*NDP*G3_Vin+G3_A*LBV(G3_V)*G3_Vin+G3_S*Switch_Leakage(G3_V)*G3_Vin ;
PROC_OF PROC_S*Switch_Leakage(PROC_V)*PROC_Vin ;

33. Power Management & Dynamic Compute
● Delay_to_State_Change is the power control state machine that changes state if
the device has been in a particular state for a time period. The format is
Textual and Scripted
Graphical FSM

34. Power RegEx Functions
Function & Argument Type(s) Description Example
powerCumulative
(String power_manager_name, String block_name)
Gets the cumulative power
consumed for a device.
powerCumulative
("ARM_Power_Manager",
"Architecture_1_Bus_1")
powerCurrent
(String power_manager_name, String block_name)
Gets the instantaneous power
as a double value for the
device.
powerCurrent ("ARM_Power_Manager
", "Architecture_1_Bus_1")
powerManager
(String power_manager_name)
Gets the complete power
table.
powerManager
("ARM_Power_Manager ")
powerUpdate
(String power_manager_name, String block_name,
String power_state)
Updates the current power
state of the block. LHS value
is the new power state of the
block.
powerUpdate ("ARM_Power_Manager
", "Architecture_1_Bus_1",
"Standby")
powerUpdateN
(String power_manager_name, String block_name,
String power_state,
integer Queue_Number)
Updates the current power
state of the
Smart_Timed_Resource
block. LHS value is the new
power state of the block.
powerUpdateN
("ARM_Power_Manager ",
"STR_Queue", "Standby",2)

35. MIRABILIS DESIGN LEADS THE SYSTEM DESIGN INNOVATION
Conclusion

36. Accelerating System Trade-offs
Using Alternate Design Methodology
Project Schedule
Model Creation (6)
Implementation (18)
Analysis (1.5)
Communication and Refinement (6)
Implementation (15)
Using VisualSim Model-Based Design Methodology
Note: All times in months
Communication and Refinement (4)
Analysis (2.5)
Model Creation (1)
Average gain for
24-month
project is 25%-
30%
Ensuring Highest
Quality Product
Accelerate Model
Development

37. MIRABILIS DESIGN LEADS SYSTEM DESIGN INNOVATION
How to achieve 95%+ Accurate
power measurement during
architecture exploration?