Offline Software-in-the-Loop Simulation Firmware Architecture
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing offline software-in-the-loop simulation methods are limited in their ability to generate firmware compatible with different controller chips, requiring separate simulation software and models for each chip type, which increases development time and restricts support to only a few chip manufacturers.
Innovation Solution
A development system and method utilizing a common firmware architecture with a hardware abstraction layer (HAL) that allows for the generation of chip control programs compatible with various controller chips or circuit simulation software without modifying the product program, enabling rapid porting to different chip types by using a database of chip peripheral libraries and a configuration header file.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If separate simulation software and models are used for each controller chip type, then compatibility with specific chip types is achieved, but device complexity and development time increase
Solution Approach 1:
The patent implements a universal simulation system that can simulate multiple different controller chip types using a single simulation software platform. The simulation object model is designed to accommodate various chip architectures and instruction sets, allowing the same simulation environment to support different chip types through configuration rather than requiring separate software instances for each chip type.
Solution Approach 2:
The simulation system is divided into distinct modular components: a universal simulation software platform, a configurable simulation object model, and separate compilation toolchains for different chip types. This segmentation allows the core simulation engine to remain simple while supporting multiple chip types through interchangeable modules and configuration files.
2Manufacturing precision
If separate simulation software and models are used for each controller chip type, then chip-specific accuracy is maintained, but development time increases
Solution Approach 1:
The simulation object model is pre-configured with chip-specific parameters, instruction set definitions, and peripheral device models for multiple controller chip types. This preliminary preparation allows developers to quickly switch between chip types by simply changing configuration parameters rather than setting up entire simulation environments from scratch, maintaining accuracy while reducing setup time.
Solution Approach 2:
The system maintains chip-specific simulation accuracy by allowing dynamic parameter changes in the simulation object model. Different controller chip types are supported by modifying configuration parameters such as instruction set architecture, register definitions, and peripheral device characteristics, rather than requiring fundamentally different simulation models for each chip type.
3Reliability
If circuit simulation software provides different controller models for different chip manufacturers, then code generation compatibility is achieved, but adaptability to new chip types is reduced
Solution Approach 1:
The simulation object model serves as an intermediary layer between the universal simulation software and chip-specific code generation requirements. This intermediary translates various chip manufacturer specifications into a standardized simulation interface, allowing the system to maintain code generation compatibility while easily adapting to new chip types through updates to the simulation object model configuration.
Data Source
AI summary
A development system and a method of an offline software-in-the-loop simulation are disclosed. A common firmware architecture generates a chip control program. The common firmware architecture has an application layer and a hardware abstraction layer. The application layer has a configuration header file and a product program. A processing program required by a peripheral module is added to the hardware abstraction layer during compiling. The chip control program is provided to a controller chip or a circuit simulation software to be executed to control the product-related circuit through controlling the peripheral module.