A processor system simulation platform implementation method

Abstract

The application belongs to the technical field of embedded processors, and discloses a processor system simulation platform implementation method, which comprises the following steps: a custom board class inherited from a machine class is designed, basic attributes and an initialization interface are set, and a board card level simulation framework is constructed; under the framework, an existing processor model is reused or a custom processor core class is written to implement instruction translation and GDB remote debugging commands, so that the adaptation problem of processor instruction simulation is solved; a storage domain is used to simulate peripheral register access space, and a front-end and back-end separation mechanism is combined to realize peripheral communication function, so that the simulated peripheral has basic communication function; the custom board class, the processor core class and the peripheral class are encapsulated, registered and added with compilation information, so that system integration of custom components is realized; finally, a graphical interface is developed according to the registered components to support visual check and parameter editing, so that the configuration complexity of the simulation platform is reduced.

Description

Technical Field

[0001] This invention belongs to the field of embedded processor technology, specifically a method for implementing a processor system simulation platform. Background Technology

[0002] Processor behavior simulation is an important technical aspect of processor R&D, mainly covering two core directions: instruction simulation and peripheral simulation. System-level simulators are the core tools for implementing this simulation.

[0003] Existing mainstream system-level simulators have limited compatibility with hardware boards and peripheral simulation functions, making it difficult to fully match the processor's specific design requirements and support the complete system simulation development work for the processor.

[0004] Currently, the mainstream approach in the industry is to rely on the QEMU system-level simulator for processor system simulation. This simulator boasts strong versatility and applicability, making it a widely used simulation tool in the industry. Its core employs binary translation technology, abandoning the traditional direct translation of instructions from different architectures. Instead, it adds a TCG op operator, independent of specific instructions, between the target instruction set and the host instruction set. Through the conversion of this intermediate operator, it breaks down instruction set architecture barriers, easily supporting the simulation of processor instructions from various different architectures. Simultaneously, QEMU integrates simulation modules for various common hardware peripherals, enabling the simulation of processor-related peripherals in general scenarios. It can meet the basic system simulation needs of most general-purpose processors, possessing advantages such as high maturity and wide adaptability.

[0005] Overall, existing processor system emulation solutions based on QEMU suffer from a core compatibility shortcoming, failing to specifically adapt to the customized hardware designs and dedicated peripheral architectures of processors. The hardware boards and peripheral emulation modules built into QEMU are of a general-purpose design, only compatible with mainstream general-purpose processor architectures on the market, without optimization for the processor's specific hardware characteristics and customized peripheral configurations, resulting in a significant gap in coverage. This issue directly leads to the inability of existing emulation platforms to quickly and accurately build processor-compatible emulation environments, lacking standardized and universal rapid setup processes. This severely restricts the efficient conduct of system simulation testing and functional verification during processor development, making it difficult to meet the development needs of independent processor research and development. Summary of the Invention

[0006] This invention provides a method for implementing a processor system simulation platform, which solves the problem that the hardware boards and peripheral simulation modules built into QEMU are all general-purpose designs, only compatible with mainstream general-purpose processor architectures on the market, and not optimized for the processor's exclusive hardware characteristics and customized peripheral configurations, resulting in a significant gap in coverage.

[0007] To achieve the above objectives, the present invention provides the following technical solution: This invention provides a method for implementing a processor system simulation platform, comprising the following steps: Step 1: Design a custom board class that inherits from the machine class, and set the basic board properties and system module initialization interface; Step 2: Simulate the processor core under the board framework designed in Step 1: If the processor adopts a standard instruction set, reuse the existing processor model; if a custom instruction set is adopted, write a custom processor core class that inherits from the processor class to implement the instruction translation operator and the debugging module access interface. Step 3: Develop peripheral modules under the board framework designed in Step 1: simulate peripheral register access space through memory domain and simulate peripheral communication functions through front-end and back-end separation mechanism; Step 4: Encapsulate the custom board class designed in Step 1, the custom processor core class written in Step 2, and the peripheral class developed in Step 3 into type information structures, register them into the system simulation platform, and add compilation information to the build system. Step 5: Develop a graphical interface based on the component information registered in Step 4. The graphical interface is configured to allow for visual selection and parameter editing of simulator components.

[0008] According to one embodiment of the present invention, in step 1, the initialization interface of the custom board class sets the number of processor cores and the size of the storage space, and creates and initializes other modules in the system.

[0009] According to one embodiment of the present invention, the instruction translation operator in step 2 is implemented as follows: the registers in the processor core are converted into TCG operation variables, and the target instruction code is parsed and translated into TCG micro-operation codes with the same semantics; the debug module access interface implements reading and writing registers, reading and writing memory areas, and accessing the PC register.

[0010] According to one embodiment of the present invention, the specific way to simulate the peripheral communication function through the front-end and back-end separation mechanism in step 3 is as follows: the front-end is a custom peripheral class, and the back-end is the underlying interface provided by the operating system; the data to be sent by the peripheral is sent to the connected peer or output stream through the storage domain via the back-end, and the data received by the back-end is passed to the register of the front-end.

[0011] According to one embodiment of the present invention, the specific sub-steps of developing the peripheral module in step 3 include: designing a structure containing the resources required for simulating the peripheral, the structure including registers, FIFO, interrupts and a backend for peripheral binding; writing a custom class inherited from the device class as the frontend for simulating the peripheral, implementing the class initialization interface and the instance initialization interface; allocating a storage domain for each peripheral instance and mapping it to the address space of the peripheral control register, implementing the read and write interface of the storage domain, the read and write interface simulating the internal processing logic of the peripheral and the frontend and backend data transfer.

[0012] According to one embodiment of the present invention, the specific method of registering the custom class in step 4 is as follows: the custom board class and peripheral class encapsulated as type information structure are loaded in the initialization phase of the system simulation platform through the registration interface; the method of adding compilation information in the build system is as follows: add compilation option switches to the source file corresponding to the custom class and start the corresponding compilation switches.

[0013] According to one embodiment of the present invention, in step 4, conditional compilation is added by modifying the build file, and the compilation switch of the custom hardware board is started by modifying the configuration file. The compilation switch of the peripheral is determined by the configuration options of the board.

[0014] According to one embodiment of the present invention, the graphical interface in step 5 includes a component tree selection area, a parameter list editing area, and a component or parameter retrieval area; the component tree selection area allows selection of components supported by the simulator, the parameter list editing area displays and allows input of parameter information of the currently selected component, and the component or parameter retrieval area allows retrieval by keyword or parameter value.

[0015] Compared with existing technologies, this invention has the following advantages: This invention provides a method for implementing a processor system simulation platform. By designing a custom board class that inherits from the machine class and setting basic attributes and initialization interfaces, a board-level simulation framework is constructed. Within this framework, existing processor models are reused or custom processor core classes are written to implement instruction translation and debugging access, solving the adaptation problem of processor instruction simulation. Peripheral register access space is simulated through memory domains, and peripheral communication functions are implemented by combining a front-end / back-end separation mechanism, making peripheral simulation consistent with real hardware behavior. Custom board classes, processor core classes, and peripheral classes are encapsulated, registered, and have compilation information added, achieving system integration of custom components. Finally, a graphical interface is developed based on the registered components to support visual selection and parameter editing, reducing the complexity of the simulation platform configuration. This forms a complete simulation platform construction process from boards and processors to peripherals, enabling the system simulation platform to cover the processor's instruction set and peripheral requirements, shortening the hardware board development cycle, improving the reusability and configurability of the simulation platform, and solving the technical problem that existing QEMU cannot fully adapt to processor designs. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating a method for implementing a processor system simulation platform according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the peripheral analog communication function in an embodiment of the present invention; Figure 3 This is a diagram illustrating the simulated CAN device communication mechanism in an embodiment of the present invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0019] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0020] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0021] To enable those skilled in the art to better understand the technical solution of the present invention, the present invention will be further described in detail below with reference to the accompanying drawings.

[0022] like Figure 1 As shown, this embodiment of the invention provides a method for implementing a processor system simulation platform, including the following steps: S1: Design a custom board class that inherits from the machine class, and set the basic board properties and system module initialization interface; S2: Simulates the processor core under the board framework designed in S1: If the processor adopts a standard instruction set, the existing processor model is reused; if a custom instruction set is adopted, a custom processor core class that inherits from the processor class is written to implement the instruction translation operator and the debugging module access interface. S3: Develop peripheral modules under the board design framework of S1: simulate peripheral register access space through memory domain and simulate peripheral communication function through front-end and back-end separation mechanism; S4: Encapsulate the custom board class designed in step 1, the custom processor core class written in S2, and the peripheral class developed in S3 into type information structures, register them into the system simulation platform, and add compilation information to the build system. S5: Develop a graphical interface based on the component information registered in S4. The graphical interface is configured to allow for visual selection and parameter editing of simulator components.

[0023] The detailed steps are as follows: S1: Design a custom board class that inherits from the Machine class, and set the board's basic properties and system module initialization interface. The board class is the core of the processor SOC-level system simulation, including CPU (implementing instruction simulation), various peripherals, storage and other modules. The board class directly or indirectly inherits from the MACHINE class. When writing, it is also necessary to specify its name and initialization interface machine_class_init. The interface mainly completes two tasks: (1) setting the basic attributes of the board such as the number of processor cores and the size of the storage space, and (2) creating and initializing other modules in the system.

[0024] S2: Simulate the processor core within the board framework designed in step 1: If the processor uses a standard instruction set, reuse the existing processor model; if it uses a custom instruction set, write a custom processor core class that inherits from the processor class, and implement the instruction translation operator and debug module access interface. If the processor's instructions are consistent with the standard instruction set, the CPU model implemented under the corresponding instruction set architecture in QEMU can be used as the processor core of the simulation board. If the processor uses a custom instruction set, a custom processor core class that inherits from the CPU class needs to be written, implementing the following interfaces: The TCG instruction translation operator, based on the TCG code generator module of QEMU, translates the simulated target instructions into host machine instructions running on the system simulation platform through dynamic binary translation technology. The processor core implements the following core functions through the instruction translation operator: converting the registers in the processor core into TCG operation variables. The implementation method is: during the instruction translation initialization process, the tcg_global_mem_new_i32 / 64 interface is called to allocate TCG variables of the corresponding type for each core register. The target instruction code is parsed and translated into TCG micro-operation codes with the same semantics.

[0025] The debugging module access interface, QEMU contains a gdb debugging server that can parse remote debugging commands. If you want to support remote debugging simulation of processor cores on the system simulation platform, you need to implement interfaces for reading and writing registers, reading and writing memory areas, and accessing the PC register for custom processor cores.

[0026] S3: Develop peripheral modules under the board design framework of S1: simulate peripheral register access space through memory domain and simulate peripheral communication function through front-end and back-end separation mechanism; Peripherals primarily simulate the basic communication functions of devices such as serial ports and CAN buses. In embedded software development, the sending and receiving of peripherals are achieved by reading and writing their control and data registers, such as... Figure 2 As shown, the simulation of peripherals mainly includes two aspects: (1) simulating peripheral register access space through the memory_region, and (2) simulating peripheral communication function through the front-end and back-end separation mechanism. The front-end is a custom peripheral class, and the back-end is the underlying interface provided by the operating system, such as socket, stdio (standard input and output stream), pipe, file, etc. The data to be sent by the peripheral is sent to the connected peer or output stream through the memory_region mapped by the register through the back-end. The data received by the back-end will also be passed to the register of the front-end.

[0027] The specific steps are as follows: The design includes a structure containing the resources required by the simulated peripherals, including registers, FIFOs, interrupts, and the backend for peripheral binding. Write a custom class that inherits from the DEVICE class as the front end of the simulated peripheral. The front end includes the structure designed in step 1 and implements the class initialization interface device_class_init and the instance initialization interface instance_init. In the class initialization interface, set the attributes of the peripheral that can be configured through the simulation platform startup parameters.

[0028] A processor board may have multiple peripherals of the same model, but with different access addresses. In the instance initialization interface instance_init of the peripheral, a memory region is allocated for each peripheral instance, which is mapped to the address space of the peripheral control register on the actual development board. The read and write interface of the memory region is implemented to simulate the internal processing logic of the peripheral, which mainly involves data transfer between the front end and the back end.

[0029] Different types of devices employ different analog backends and mechanisms in analog communication. Taking CAN devices as an example, the analog communication mechanism used is as follows: Figure 3 As shown.

[0030] CAN bus devices belong to the network device category. The SocketCAN interface provided by the Linux system serves as the backend of the simulated CAN device, while a CAN_HOST device is introduced as a data relay between the frontend and backend of the simulated CAN device. To enable the CAN-HOST to connect the frontend and backend of the simulated CAN device, two attributes are designed for the CAN-HOST device: interface and the connected CAN bus. The CAN-HOST device and the custom CAN device on the simulated processor are connected to the same CAN bus. During initialization, the CAN-HOST device binds to the SocketCAN socket created through the socket(PF_CAN, SOCK_RAW, CAN_RAW) interface, and the address corresponds to the peer device connected via the simulated CAN bus specified by the "interface" attribute. Figure 3 The virtual network device vcan0 in the middle.

[0031] When the simulated CAN device in the processor sends data, it encapsulates the data into CAN-FRAME format and transmits it to the CAN-HOST device via CAN-bus. After receiving the data, the CAN-HOST device sends it to the virtual device vcan0 via the socket interface. The CAN data frames received by vcan0 can be displayed using the can-utils tool.

[0032] When the virtual device vcan0 sends CAN data to the processor, the data is transmitted to the CAN-HOST device through the socket interface. After receiving the data, the CAN-HOST device calls the receive function of the custom CAN device connected to its CAN-BUS. In the receive function, the CAN-FRAME format data is parsed and stored in the corresponding CAN device data register.

[0033] S4: Encapsulate the custom board class designed in step 1, the custom processor core class written in S2, and the peripheral class developed in S3 into type information structures, register them into the system simulation platform, and add compilation information to the build system. The processor board class and peripheral class implemented in the above steps are all encapsulated as a struct of type TypeInfo when defined. In order for them to be called in the system simulation platform, the following two steps need to be performed: (1) Register the custom class encapsulated as a TypeInfo structure into the system simulation platform so that the corresponding board and peripheral classes can be loaded during the initialization phase of the simulation platform startup.

[0034] (2) Add compilation information of custom classes during the construction of the system simulation platform so that the system simulation platform contains the target code of custom classes.

[0035] QEMU uses meson as its build tool. During the build process, it generates a system simulator for the specified processor architecture based on the configured target processor architecture. The processor board is compiled according to the processor architecture, and the peripheral class code is classified according to the access method: character device (char), block device (block), network (net), etc. The compilation of peripheral classes is determined by the board configuration information.

[0036] Add compiler option switches to the .c source files for implementing custom hardware boards and peripherals respectively.

[0037] By modifying the meson.build file in the corresponding directory, conditional compilation can be added, such as "when: 'CONFIG_xxx (compile switch)' if true: files (path name of the compilation file)". For hardware boards, modify the meson.build file under hw\processor core architecture (e.g., arm, ppc, riscv) according to the type of the board's processor core; for peripherals, such as custom serial ports, modify the meson.build file under the hw\char directory.

[0038] Enable the compilation switch for custom hardware boards and peripherals. Whether a custom hardware board is compiled depends on the compilation options under the corresponding processor architecture. Modify the default softmmu configuration file for the corresponding processor architecture and enable the compilation switch for the custom hardware board in the format "CONFIG_xxx (custom hardware board name) = y".

[0039] The compile-enabled peripherals are determined by the board's configuration options. Custom peripherals are enabled in the configuration options (Kconfig file) of the custom hardware board. The specific steps are as follows: config allows you to customize the name of the hardware board. bool select custom peripheral 1 (compile switch for peripheral 1) select custom peripheral 2 (compile switch for peripheral 2) The above steps generally need to be completed manually. However, tools can be used to design a more user-friendly way (shown in the examples below) to automatically modify the multiple meson.build and Kconfig files for custom boards and peripherals.

[0040] S5: Develop a graphical interface based on the component information registered in S4. The graphical interface is configured to allow for visual selection and parameter editing of simulator components. To facilitate the use of the system simulation platform, a visual simulator component configuration tool was developed. Based on Eclipse, a simulator configuration manager suitable for processors was designed to dynamically create corresponding objects when the simulation platform starts. The interface is divided into a component tree selection area and a parameter list editing area.

[0041] (1) Simulator component selection area The simulator component tree selection area is used to select all components supported by the simulator. Users can select or deselect the corresponding components by clicking the checkboxes in the simulator component tree selection area.

[0042] (2) Parameter list editing area The parameter list editing area is mainly used to display and input all parameter information of the currently selected simulator component, and to verify in real time whether the user's input parameter values ​​meet the assignment requirements. When an error is entered, the system will pop up an error message dialog box to remind you.

[0043] (3) Component or parameter retrieval area The component or parameter search area is an intelligent search function area designed to facilitate user operation of simulator components. It supports searching by keywords or directly by parameter values. Search results will be highlighted in the tree-view selection area and parameter list area.

[0044] Another embodiment of the present invention provides a method for implementing a processor system simulation platform, comprising: To build a system simulation platform for PPC processors, using the e200 series standard instruction set, and including 2MB SRAM, 3 serial ports, and 2 CAN modules, the implementation steps are divided into three parts, based on the implementation method described above: designing custom hardware board classes, designing custom peripheral classes, and registering the custom classes in the simulation system. The detailed steps for each part are as follows: 1. Design custom hardware boards (1) Define a structure of type TypeInfo for the package board class, with parent member being TYPE_MACHINE and class name being LCCORE_SOC. Assign its class_init member to specify the initialization interface of the class.

[0045] (2) In the class initialization interface, set the default CPU type of the board to PPC e200, specify the board initialization interface, and add configurable attributes related to the board. Specific implementation method: In the class initialization interface, assign the default_cpu_type member representing the class object to the CPU class name corresponding to the e200 type PPC, and assign the init member to its corresponding board initialization function.

[0046] (3) In the board initialization interface, instantiate a CPU of the specified type and register the board's accessible storage space into the simulator's global address space.

[0047] (4) Divide the board's storage space (memory-region) and map different types of storage regions to the address space consistent with the actual hardware.

[0048] (5) Initialize 3 serial ports and 2 CAN devices, and call the custom serial port and CAN device creation functions respectively (implemented below) to create corresponding peripheral instances in the system.

[0049] 2. Develop custom serial port and CAN modules: 2.1 Serial Port Peripheral Module Serial ports are character-based access devices. The system simulation platform provides the "-serial" parameter to specify the backend to which the serial port is bound. When designing a custom serial port, its backend is also designed to be flexible and configurable. The specific implementation steps are as follows: (1) Design a custom serial port class: Define a TypeInfo type structure that encapsulates the serial port class. The parent member is TYPE_SYS_BUS_DEVICE, the class name is UART_LC, the class_init member is assigned to specify the class initialization interface, and the instance_init member is assigned to specify the class instance initialization interface.

[0050] (2) Design the front end of the serial port device and define the structure uart_state that encapsulates the resources required for serial port simulation, including various control register variables, the memory region (memory_region type) corresponding to the address space accessed by the serial port, interrupt (qemu_irq type), character device back end, and FIFO.

[0051] (3) In the instance initialization interface, initialize the storage field of the serial port, specify the size of the storage field and the read / write access interface, and allocate interrupt resources for the serial port. In the class initialization interface, add the attribute "chr" to the serial port to correspond to its character device backend.

[0052] (4) Implement the read and write access interface of the serial port storage domain to simulate the internal processing logic of the device, realize the data transmission between the simulated serial port front end and back end, and thus simulate the serial port sending and receiving function.

[0053] Both the read and write interfaces can access the `uart_state` structure, which contains resources for the simulated serial port front-end. In the write interface, the data to be transmitted, stored in the peripheral front-end control register, is passed to the character device back-end bound to the serial port. In the read interface, a character is read from the character device back-end and stored in the corresponding control register of the front-end.

[0054] (5) Implement the serial port device creation interface, which is called during the board initialization process. In this interface, a custom serial port instance is first created by qdev_new, then its chr attribute is set to the serial port backend specified by "-serial" in the simulation platform startup parameters, then the IORead and IOCanRead handles of the character device are set, and then the memory domain of the serial port device is mapped to the starting address of the actual access space.

[0055] 2.2 CAN Peripheral Module Based on the CAN simulation implementation mechanism described above, the specific implementation process requires: (1) implementing a custom CAN device, including its front-end structure and various interfaces, such as CAN data frame receiving and sending interfaces and device connection bus interfaces; (2) creating CAN-HOST and CAN-BUS devices respectively, and attaching the CAN-HOST and the custom CAN device to the CAN-BUS; (3) creating a parallel device that simulates CAN bus connection, and connecting the CAN-HOST device to the device via a socket.

[0056] Implement a custom CAN device class (1) Define a TypeInfo type structure that encapsulates CAN device information. The parent member is TYPE_SYS_BUS_DEVICE, the class name is CAN_LC, the class_init member is assigned a value to specify the class initialization interface, and the instance_init member is assigned a value to specify the class instance initialization interface.

[0057] (2) Design the front end of the CAN device and define the structure can_state that encapsulates the resources required for CAN simulation, including various control register variables, the memory region (memory_region type) corresponding to the address space accessed by the device, the interrupt (qemu_irq type), the corresponding bus client (CanBusClient type), and the attached CAN bus pointer (CanBus type).

[0058] (3) In the class initialization interface, add the "canbus" attribute to correspond to the CAN bus connected to the device. In the instance initialization interface, allocate the resources contained in the structure can_state designed in step (2), initialize the storage domain, specify the size of the storage domain and the read / write access interface, and map the storage domain to the access space of the CAN controller on the real hardware board.

[0059] (4) Implement the CAN device connect bus (can_connect_to_bus) interface. In this interface, set the CAN bus pointer in the front-end can_state structure to point to the CAN bus to be connected, and insert the bus client into the client list of the connected bus.

[0060] (5) Implement the transmit and receive interfaces of the CAN device bus client. In the receive interface, the CAN data frames sent by the CAN-HOST device connected to the same bus are parsed and filled into the memory field mapped to the corresponding data register. In the transmit interface, the data in the CAN register is encapsulated into CAN data frames and sent to the CAN-HOST device connected to the same CAN-BUS as the CAN device.

[0061] (6) Implement the CAN device creation interface. In this interface, a custom CAN device instance is created using qdev_new. If the canbus attribute of the CAN device is not empty, the CAN device bus interface implemented in step (4) is called to map the memory domain of the CAN device to the starting address of the actual access space. This interface is called during the board initialization process to create a CAN device instance.

[0062] Create a peer device that simulates a CAN bus connection. (7) In the environment of the system simulation platform, create a virtual network device van0 of type vcan as the peer device for simulating CAN bus communication by using the command "ip link add dev".

[0063] Creating CAN-HOST and CAN-BUS devices (8) Create CAN-BUS devices under the system simulation platform, with device ID as canbus0.

[0064] (9) Create a CAN-HOST device under the system simulation platform, set the interface attribute of the CAN-HOST device to van0, so as to realize the socket corresponding to the CAN-HOST to bind the address of the virtual network device van0. Set the canbus attribute of the CAN-HOST device and the simulated CAN device to canbus0 respectively, so as to realize the CAN-HOST device and the simulated CAN device to be connected to the same CAN bus.

[0065] 3. Register custom hardware boards and device classes in the simulation system. (1) Call the type_register_static interface on the TypeInfo type structure that encapsulates the information of custom hardware board, CAN and serial port devices respectively to load and initialize the three custom classes LCCORE_SOC, CAN_LC and UART_LC during the startup of the system simulation platform.

[0066] (2) Write the board component description file for the analog processor chip, with the following content: machine { nameLCCORE_SOC targetppc src_filelccore_soc.c } device { nameUART_LC classchar src_fileuart_lc.c } device { nameCAN_LC classnet / can src_filecan_lc.c } In this description file, the contents within `machine{}` represent the compilation information for a custom hardware board class named `LCCORE_SOC`, with the corresponding source file path being `hw / ppc / lccore_soc.c`. Each `device{}` represents a type of custom device. This description file defines two peripherals: one named `UART_LC` with the corresponding source file path `hw / char / uart_lc.c`, and the other named `CAN_LC` with the corresponding source file path `hw / net / can / can_lc.c`.

[0067] (3) Use parsing tools to process the board component description files, modify the .meson file and Kconfig file in the corresponding directory according to the rules introduced above, and compile the corresponding source code files of the LCCORE_SOC board and the two peripherals UART_LC and CAN_LC on the board during the construction of the system simulation platform, thereby completing the registration of the custom class.

[0068] 4. The component-based configuration of the system simulation platform is implemented by organizing different types of components such as general components, hardware boards (machine), and peripherals (DEVICES) in a tree structure. The configurable parameters of the components can be seen in the interface. When a component is selected, the corresponding object is created with the parameters configured in the interface when the system simulation platform starts.

[0069] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or basic characteristics. Therefore, the embodiments should be considered exemplary and non-limiting in all respects.

[0070] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can be appropriately combined to form other embodiments that can be understood by those skilled in the art. The above content is only for illustrating the technical concept of the present invention and should not be construed as limiting the scope of protection of the present invention. Any modifications made based on the technical concept proposed in this invention shall fall within the scope of protection of the claims of this invention.

Claims

1. A method for implementing a processor system simulation platform, characterized in that, Includes the following steps: Step 1: Design a custom board class that inherits from the machine class, and set the basic board properties and system module initialization interface; Step 2: Simulate the processor core under the board framework designed in Step 1: If the processor adopts a standard instruction set, reuse the existing processor model; if a custom instruction set is adopted, write a custom processor core class that inherits from the processor class to implement the instruction translation operator and the debugging module access interface. Step 3: Develop peripheral modules under the board framework designed in Step 1: simulate peripheral register access space through memory domain and simulate peripheral communication functions through front-end and back-end separation mechanism; Step 4: Encapsulate the custom board class designed in Step 1, the custom processor core class written in Step 2, and the peripheral class developed in Step 3 into type information structures, register them into the system simulation platform, and add compilation information to the build system. Step 5: Develop a graphical interface based on the component information registered in Step 4. The purpose of the graphical interface configuration is to visually select and edit the parameters of the simulator components.

2. The processor system simulation platform implementation method according to claim 1, characterized in that, The number of processor cores and storage space size are set through the initialization interface of the custom board class in step 1, and other modules in the system are created and initialized.

3. The method for implementing a processor system simulation platform according to claim 1, characterized in that, The instruction translation operator in step 2 is implemented by converting the registers in the processor core into TCG operation variables and parsing the target instruction code into TCG micro-operation codes with the same semantics; the debug module access interface enables reading and writing registers and memory areas, as well as controlling the processor's stop and run states.

4. The method for implementing a processor system simulation platform according to claim 1, characterized in that, In step 3, the specific method of simulating peripheral communication function through front-end and back-end separation mechanism is as follows: the front-end is a custom peripheral class, and the back-end is the underlying interface provided by the operating system; the data to be sent by the peripheral is sent to the connected peer or output stream through the storage domain via the back-end, and the data received by the back-end is passed to the register of the front-end.

5. The processor system simulation platform implementation method according to claim 4, characterized in that, The specific sub-steps for developing the peripheral module in step 3 include: The design includes a structure containing the resources required by the analog peripherals, the structure including registers, FIFO, interrupts and a backend for peripheral binding; Write a custom class that inherits from the device class as the front end of the simulated peripheral device, and implement the class initialization interface and instance initialization interface; A storage domain is allocated to each peripheral instance and mapped to the address space of the peripheral control register to implement the read and write interface of the storage domain. The read and write interface simulates the internal processing logic of the peripheral and the front-end and back-end data transmission.

6. The method for implementing a processor system simulation platform according to claim 1, characterized in that, The specific method for registering custom classes in step 4 is as follows: the custom board class and peripheral class, which are encapsulated as type information structures, are loaded during the initialization phase of the system simulation platform startup through the registration interface; the method for adding compilation information in the build system is as follows: add compilation option switches to the source files corresponding to the custom classes and start the corresponding compilation switches.

7. The method for implementing a processor system simulation platform according to claim 6, characterized in that, In step 4, conditional compilation is added by modifying the build file, and the compilation switch of the custom hardware board is started by modifying the configuration file. The compilation switch of the peripheral is determined by the configuration options of the board.

8. The method for implementing a processor system simulation platform according to claim 1, characterized in that, The graphical interface in step 5 includes a component tree selection area, a parameter list editing area, and a component or parameter retrieval area. The component tree selection area allows users to select components supported by the simulator. The parameter list editing area displays and allows users to input parameter information for the currently selected component. The component or parameter retrieval area allows users to search for components by keywords or parameter values.

Images