RISC-V virtual prototype platform based on Crypto-VP architecture

Abstract

The invention relates to an RISC-V virtual prototype platform based on Crypto-VP architecture, which is characterized in that a CPU (Central Processing Unit) kernel in the RISC-V virtual prototype platform is respectively connected with a debugging and monitoring interface controller and a coprocessor model, and is connected with a transaction-level modeling 2.0 standard bus through a transaction-level modeling 2.0 standard bus interface; one end, far away from the CPU kernel, of the debugging and monitoring interface controller is connected with the main memory; the local interrupt controller and the platform-level interrupt controller are connected to a transaction-level modeling 2.0 standard bus through a transaction-level modeling 2.0 standard interface; the accelerator model is connected with a transaction-level modeling 2.0 standard bus through a transaction-level modeling 2.0 standard interface and is allocated to a specified address range of the CPU core; one end of the executable and linkable format loader obtains executable and linkable format files of the RISC-V architecture generated by the external GNU compiler set, and the other end of the executable and linkable format loader is connected with the main memory; and each module is integrated with a power consumption statistics and visualization module. According to the RISC-V virtual prototype platform, the simulation and exploration speed is greatly improved.

Description

Technical Field

[0001] This application relates to the field of integrated circuits, and more particularly to a RISC-V virtual prototyping platform based on the Crypto-VP architecture. Background Technology

[0002] Against the backdrop of the continuous evolution of modern chip design, and with the rapid development of the RISC-V open-source instruction set architecture, the design complexity of System-on-a-Chip (SoC) is increasing exponentially. At the same time, market demands for product performance, power consumption, and development cycles are becoming increasingly stringent. To achieve a balance between high performance and high energy efficiency in this fiercely competitive environment, design teams not only need to complete hardware and software co-design in the early stages, but also need to explore and optimize large-scale design spaces within a limited timeframe. While traditional RTL-level implementation and verification processes can provide accurate performance, power consumption, and area (PPA) results, they often require significant time and computing resources, making it difficult to meet the demands of rapid iterative development.

[0003] Against this backdrop, Electronic System-Level (ESL) design methodologies are widely used in the early modeling and verification of System-on-Chips (SoCs). By building virtual prototypes (VPs) within the SystemC and TLM-2.0 frameworks, designers can achieve system functional descriptions and hardware-software interaction verification at a higher level of abstraction, thereby significantly improving design efficiency and flexibility. Currently, there are various RISC-V-based virtual prototyping platforms, such as Spike, RV8, RISC-CV-QEMU, gem5, RISC-CV-VP, Renode, OVPsim, and Crypto-VP. These platforms generally integrate an Instruction Set Simulator (ISS), supporting functional-level simulation of the RISC-V architecture and playing a crucial role in early software development and system verification.

[0004] However, existing RISC-V virtual prototyping platforms still have significant shortcomings in Design Space Exploration (DSE). First, most platforms only support performance analysis, lacking independent power consumption and area assessment capabilities, and thus cannot perform complete Power-to-Average (PPA) analysis. For example, while the RISC-V V-VP platform supports System-C level simulation, it can only perform performance evaluation; and while gem5 provides more refined system-level modeling capabilities, it comes at the cost of simulation speed and requires additional external EDA tools for power consumption analysis, making the process complex and time-consuming. Second, existing automated DSE methods are mostly based on low-level hardware description languages ​​(such as Verilog, VHDL, and Chisel), requiring a complete front-end and back-end design flow to obtain accurate PPA results, which significantly prolongs the exploration cycle. Furthermore, existing virtual prototyping platforms have limited capabilities in supporting RISC-V custom instruction and coprocessor modeling, making it difficult to meet the design requirements of specific applications. For power consumption modeling, existing tools such as McPAT or DESTINY provide relatively accurate energy consumption assessments, but they usually require circuit-level or architecture-level input parameters and cannot achieve fast calculations at the ESL level, thus limiting DSE efficiency.

[0005] In summary, in order to address the lack of a RISC-V virtual prototyping platform in the existing technology that can perform joint performance and power consumption analysis at the electronic system level, support the verification of custom instruction functions, and efficiently explore the design space, the applicant has made corresponding explorations to solve this problem. Summary of the Invention

[0006] The purpose of this application is to solve the above problems by providing a RISC-V virtual prototyping platform based on the Crypto-VP architecture.

[0007] A RISC-V virtual prototyping platform based on the Crypto-VP architecture is proposed for the purposes of this application. The Crypto-VP-based RISC-V virtual prototyping platform includes a CPU core using a 32-bit basic integer and multiplication / division extended RISC-V architecture, main memory, an executable and linkable format loader, a debug and monitor interface controller, a local interrupt controller, a platform-level interrupt controller, a transaction-level modeling 2.0 standard bus, an accelerator model, a coprocessor model, and a power consumption statistics and visualization module. The CPU core is connected to both the debug and monitor interface controller and the coprocessor model, and is connected to the transaction-level modeling 2.0 standard bus via a transaction-level modeling 2.0 standard bus interface. The end of the debug and monitor interface controller furthest from the CPU core is connected to the main memory.

[0008] Both the local interrupt controller and the platform-level interrupt controller are connected to the transaction-level modeling 2.0 standard bus through the transaction-level modeling 2.0 standard interface;

[0009] The accelerator model is connected to the Transaction-Level Modeling 2.0 standard bus via the Transaction-Level Modeling 2.0 standard interface and is assigned to a specified address range of the CPU core;

[0010] The executable and linkable format loader obtains the executable and linkable format files of the RISC-V architecture generated by an external GNU compiler set at one end, and is connected to the main memory at the other end;

[0011] The main memory, the transaction-level modeling 2.0 standard bus, the accelerator model, the CPU core, the local interrupt controller, the platform-level interrupt controller, the debug and monitoring interface controller, and the executable and linkable format loader all integrate the power consumption statistics and visualization module, and each power consumption statistics and visualization module is connected to a graphical user interface.

[0012] Optionally, the coprocessor model interacts directly with the CPU core to define custom instructions for the target algorithm. In the software layer, the custom instructions are compiled into single machine instructions through C inline assembly. Here, C inline assembly refers to a programming method that directly embeds assembly language instructions into C language code.

[0013] In the hardware layer, after the instruction set emulator of the CPU core fetches instructions from the main memory, the decoder parses the register index and sends it to the coprocessor model. The coprocessor model calls the read() function to resolve register conflicts and obtain operands. After processing by the algorithm operation unit, the result and the target register index are fed back to the CPU core, which calls the write() function to complete the write-back. At the same time, the coprocessor model calls the advance() function to dynamically update the cycle count.

[0014] Optionally, the accelerator model interacts with the CPU core through the Transaction-Level Modeling 2.0 standard bus, and cross-compiles and links the C program, C++ program and standard library through the GNU compiler set to generate the executable and linkable format file of the RISC-V architecture. The executable and linkable format file is then loaded into the main memory by the executable and linkable format loader and read and executed by the CPU core.

[0015] Optionally, the CPU core is connected to the debug and monitoring interface controller and the coprocessor model respectively, and is connected to the transaction-level modeling 2.0 standard bus through the transaction-level modeling 2.0 standard bus interface, including:

[0016] Acquire CPU cores, debug and monitor interface controllers, coprocessor models, and transaction-level modeling 2.0 standard buses based on the RISC-V architecture with 32-bit basic integers and multiplication and division extensions;

[0017] The direct connection between the CPU core and the debug and monitor interface controller allows the CPU core to access the main memory to obtain instructions via the debug and monitor interface controller.

[0018] Through the direct connection between the CPU core and the coprocessor model, the CPU core can transmit register indices and operands related to custom instructions to the coprocessor model, and the coprocessor model can return the results and target register indices to the CPU core after processing the data.

[0019] By connecting the CPU core to the Transaction-Level Modeling 2.0 standard bus, the CPU core can perform transaction interactions with modules connected to the Transaction-Level Modeling 2.0 standard bus.

[0020] Optionally, the debug and monitoring interface controller is connected to the main memory at the end furthest from the CPU core, including:

[0021] Acquire a CPU core, debug and monitor interface controller, and main memory that employ a 32-bit basic integer and multiplication and division extended RISC-V architecture, wherein the main memory is used to store executable and linkable format files of the RISC-V architecture loaded by the executable and linkable format loader.

[0022] One end of the debug and monitor interface controller is directly connected to the CPU core, and the other end of the debug and monitor interface controller, which is away from the CPU core, is directly connected to the main memory, forming a data transmission path for the CPU core to access the main memory through the debug and monitor interface controller;

[0023] Through the data transmission path, the CPU core reads instruction data from executable and linkable format files in the main memory via the debug and monitor interface controller. Simultaneously, the power consumption statistics and visualization module is integrated into the debug and monitor interface controller to collect static and dynamic power consumption data in real time during the CPU core's access to the main memory through the debug and monitor interface controller. The static and dynamic power consumption data are then transmitted to the graphical user interface for display. The number of instructions per cycle is calculated using a pipeline timing model, achieving synchronous acquisition of performance and power consumption data.

[0024] Optionally, both the local interrupt controller and the platform-level interrupt controller are connected to the transaction-level modeling 2.0 standard bus via a transaction-level modeling 2.0 standard interface, including:

[0025] The system acquires a local interrupt controller, a platform-level interrupt controller, and a transaction-level modeling 2.0 standard bus. The local interrupt controller is used to generate local interrupt signals for the CPU core, the platform-level interrupt controller is used to manage interrupt requests from external devices, and the transaction-level modeling 2.0 standard bus is used to implement transaction interactions between various modules in the RISC-V virtual prototype platform based on the Crypto-VP architecture.

[0026] Configure transaction-level modeling 2.0 standard interfaces for the local interrupt controller and the platform-level interrupt controller respectively. Connect the local interrupt controller to the transaction-level modeling 2.0 standard bus through its configured transaction-level modeling 2.0 standard interface, and connect the platform-level interrupt controller to the transaction-level modeling 2.0 standard bus through its configured transaction-level modeling 2.0 standard interface.

[0027] The local interrupt controller and the platform-level interrupt controller are respectively integrated with power consumption statistics and visualization modules to collect static and dynamic power consumption data in real time during the process of the local interrupt controller and the platform-level interrupt controller accessing the bus and transmitting interrupt signals through the transaction-level modeling 2.0 standard interface. The static and dynamic power consumption data are transmitted to the graphical user interface for display. The number of instructions per cycle is calculated using a pipeline timing model to achieve synchronous acquisition of performance and power consumption data.

[0028] Optionally, the accelerator model is connected to the Transaction-Level Modeling 2.0 standard bus via the Transaction-Level Modeling 2.0 standard interface and is allocated to a specified address range of the CPU core, including:

[0029] The accelerator model, transaction-level modeling 2.0 standard bus, and CPU core using a 32-bit basic integer and multiplication-division extended RISC-V architecture are obtained. The accelerator model is used to implement hardware acceleration of the target algorithm.

[0030] Configure the accelerator model with a transaction-level modeling 2.0 standard interface, and establish a connection between the accelerator model and the transaction-level modeling 2.0 standard bus through the interface, so that the accelerator model can transmit data with the CPU core and other modules through the bus;

[0031] A specified address range accessible to the CPU core is allocated to the accelerator model, enabling the CPU core to read and write the external registers of the accelerator model via memory address mapping to control its operation. Simultaneously, a power consumption statistics and visualization module is integrated into the accelerator model. This module is connected to a graphical user interface to collect real-time statistics on static and dynamic power consumption data during the accelerator model's interaction with the Transaction-Level Modeling 2.0 standard bus via the Transaction-Level Modeling 2.0 standard interface and the execution of the target algorithm. This static and dynamic power consumption data is then transmitted to the graphical user interface for display. A pipeline timing model is used to calculate the number of instructions per cycle, achieving synchronous acquisition of performance and power consumption data.

[0032] Optionally, the executable and linkable format loader acquires the executable and linkable format files of the RISC-V architecture generated by an external GNU compiler set at one end, and is connected to the main memory at the other end, including:

[0033] The executable and linkable format loader, main memory, and external GNU compiler set are obtained. The executable and linkable format loader is used to parse and load RISC-V architecture executable files. The GNU compiler set is used to cross-compile C programs, C++ programs, and standard libraries to generate RISC-V architecture executable and linkable format files.

[0034] One end of the executable and linkable format loader establishes a data interaction relationship with an external GNU compiler set to obtain the RISC-V architecture executable and linkable format files generated by the compiler set. At the same time, the other end of the executable and linkable format loader is directly connected to the main memory, forming a file transfer path in the order of GNU compiler set, executable and linkable format loader, and main memory.

[0035] Through the file transfer path, the executable and linkable format loader parses and processes the RISC-V architecture executable and linkable format files obtained from the external GNU compiler set, and loads the instructions and data in the executable and linkable format files into a designated storage area of ​​the main memory for the CPU core to read and execute. At the same time, the power consumption statistics and visualization module is integrated into the executable and linkable format loader to collect static and dynamic power consumption data in real time during the file acquisition, parsing and loading process, and transmits the static and dynamic power consumption data to the graphical user interface for display. The pipeline timing model is used to calculate the number of instructions per cycle to achieve synchronous acquisition of performance and power consumption data.

[0036] Optionally, the target algorithm includes the SM4 algorithm.

[0037] Compared to existing technologies, this application addresses the lack of a RISC-V virtual prototyping platform in the prior art that can achieve joint performance and power consumption analysis at the electronic system level, support the verification of custom instruction functions, and efficiently explore the design space. This application includes, but is not limited to, the following beneficial effects:

[0038] Firstly, existing RISC-V virtual prototyping platforms (such as RISC-CV-VP and gem5) mostly only support performance analysis and require external tools to evaluate power consumption, which is a complex and time-consuming process. In contrast, the RISC-V virtual prototyping platform based on the Crypto-VP architecture in this application integrates the Pwt-NM power consumption model into all core modules. It can statistically analyze static and dynamic power consumption data in real time and display it intuitively through a graphical user interface (GUI). Simultaneously, it combines pipeline timing models to calculate IPC (instructions per cycle), achieving simultaneous acquisition of performance and power consumption data. This allows for analysis of core dimensions such as performance, power consumption, and area without the need for additional tools.

[0039] Secondly, the RISC-V virtual prototyping platform based on the Crypto-VP architecture in this application enhances support for custom instructions and coprocessors, supplementing functional verification scenarios. Existing platforms have limited capabilities in modeling RISC-V custom instructions and coprocessors, making it difficult to meet the design requirements of specific applications. The RISC-V virtual prototyping platform based on the Crypto-VP architecture in this application features a specially designed coprocessor model that supports instruction-level granularity verification of custom instructions. It ensures the independence of instruction compilation through C inline assembly, while the coprocessor interacts directly with the CPU core, reducing communication overhead. This allows for efficient verification of the functional correctness and timing rationality of custom instructions, covering the entire process from software instruction definition to hardware execution verification.

[0040] Third, the RISC-V virtual prototyping platform based on the Crypto-VP architecture in this application is based on electronic system-level (ESL) modeling, which greatly improves the simulation and exploration speed. Traditional design space exploration relies on RTL-level description, which requires a complete front-end and back-end process to obtain PPA results, and the cycle can take up to several weeks. However, the RISC-V virtual prototyping platform based on the Crypto-VP architecture in this application can carry out exploration in the early stage without waiting for the underlying hardware implementation.

[0041] Fourth, automated Pareto optimization reduces the cost of manual decision-making. During the design space exploration, the platform can automatically calculate the performance-power trade-off indicators under different configurations and select the optimal solution through the Pareto optimization principle.

[0042] Fifth, the RISC-V virtual prototyping platform based on the Crypto-VP architecture in this application is compatible with diverse hardware acceleration and storage solutions, and can be flexibly configured according to design goals (such as high performance, low power consumption, and low cost). For example, PCRAM storage can be used for power-sensitive scenarios, while the SM4 hardware accelerator can be enabled for performance-sensitive scenarios, adapting to the SoC design needs of multiple fields such as embedded systems and edge computing.

[0043] Sixth, the RISC-V virtual prototyping platform based on the Crypto-VP architecture proposed in this application has the advantages of open source compatibility, lowering the threshold for industrial applications. The platform is built on the open-source RISC-V architecture and the GCC toolchain. The software layer supports cross-compilation of C / C++ programs, and the hardware modules adopt a modular design, making it easy for developers to expand functionality according to their needs. At the same time, the platform is compatible with the existing RISC-V software ecosystem and can be used without refactoring the development environment, lowering the application threshold for enterprises and research institutions. Attached Figure Description

[0044] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:

[0045] Figure 1 This is an exemplary network architecture used in the RISC-V virtual prototyping platform based on the Crypto-VP architecture of this application;

[0046] Figure 2 This is an exemplary network architecture of the Crypto-VP architecture in the embodiments of this application;

[0047] Figure 3 This is a schematic diagram illustrating the task scheduling and register optimization strategies employed during the expansion process in an embodiment of this application.

[0048] Figure 4 This is a schematic diagram illustrating the application of task scheduling and critical path optimization during the compression process in the embodiments of this application;

[0049] Figure 5 This is a schematic diagram illustrating the generation of round keys through round function iteration in an embodiment of this application.

[0050] Figure 6 This is a schematic diagram of the data decryption structure in an embodiment of this application;

[0051] Figure 7 This is a schematic diagram showing how the interface registers of the SMx core are generated by the register wrapper in an embodiment of this application.

[0052] Figure 8 This is a schematic diagram illustrating the implementation of the software layer in the coprocessor model of this application using C inline assembly;

[0053] Figure 9 This is a schematic diagram illustrating how the control register switches functions through bit field definitions in an embodiment of this application. Detailed Implementation

[0054] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application.

[0055] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this application means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. It should be understood that when we say an element is “connected” or “coupled” to another element, it can be directly connected or coupled to the other element, or there may be intermediate elements. Furthermore, “connected” or “coupled” as used herein can include wireless connections or wireless coupling. The term “and / or” as used herein includes all or any units and all combinations of one or more associated listed items.

[0056] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the same meaning as in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined as herein.

[0057] Those skilled in the art will understand that the terms "client," "terminal," and "terminal device" as used herein include both devices that receive wireless signals, devices that only possess wireless signal receiver capabilities without transmission capabilities, and devices with receiving and transmitting hardware, devices that have receiving and transmitting hardware capable of bidirectional communication over a bidirectional communication link. Such devices may include: cellular or other communication devices such as personal computers or tablets, having single-line displays, multi-line displays, or cellular or other communication devices without multi-line displays; PCS (Personal Communications Service) that can combine voice, data processing, fax, and / or data communication capabilities; PDA (Personal Digital Assistant) that may include a radio frequency receiver, pager, internet / intranet access, web browser, notepad, calendar, and / or GPS (Global Positioning System) receiver; and conventional laptops and / or handheld computers or other devices that have and / or include radio frequency receivers. As used herein, "client," "terminal," and "terminal device" can be portable, transportable, installed in a means of transportation (air, sea, and / or land), or suitable and / or configured to operate locally and / or in a distributed manner, operating in any other location on Earth and / or in space. "Client," "terminal," and "terminal device" as used herein can also be a communication terminal, an internet access terminal, or a music / video playback terminal, such as a PDA, a MID (Mobile Internet Device), and / or a mobile phone with music / video playback capabilities, or a smart TV, set-top box, etc.

[0058] The hardware referred to by the names "server," "client," and "service node" in this application is essentially an electronic device with the equivalent capabilities of a personal computer. It is a hardware device with the necessary components revealed by the von Neumann architecture, such as a central processing unit (including an arithmetic logic unit and a control unit), memory, input devices, and output devices. The computer program is stored in its memory, and the central processing unit loads the program stored in the secondary storage into the main memory to run it, execute the instructions in the program, and interact with the input and output devices to complete specific functions.

[0059] It should be noted that the concept of "server" used in this application can also be extended to the case of server clusters. Based on the network deployment principles understood by those skilled in the art, the servers should be logically divided. Physically, these servers can be independent of each other but accessible through interfaces, or they can be integrated into a single physical computer or a computer cluster. Those skilled in the art should understand this flexibility and should not use it to constrain the implementation of the network deployment method in this application.

[0060] One or more of the technical features of this application, unless explicitly specified herein, can be deployed on a server and accessed by a client remotely calling the online service interface provided by the server, or can be directly deployed and run on a client for access.

[0061] Unless otherwise specified, the neural network models referenced or potentially referenced in this application may be deployed on a remote server and invoked remotely on the client, or deployed on a client with the capability to invoke directly. In some embodiments, when running on the client, the corresponding intelligence may be acquired through transfer learning in order to reduce the requirements on the client's hardware resources and avoid excessive consumption of the client's hardware resources.

[0062] Unless otherwise specified, all data involved in this application may be stored remotely on a server or on a local terminal device, as long as it is suitable for use by the technical solution of this application.

[0063] Those skilled in the art will understand that although the various methods in this application are described based on the same concept and thus present commonality among them, they can be performed independently unless otherwise specified. Similarly, the various embodiments disclosed in this application are all based on the same inventive concept; therefore, concepts expressed in the same way, as well as concepts that are appropriately changed for convenience but are expressed differently, should be understood equivalently.

[0064] Unless otherwise expressly stated, the various embodiments disclosed in this application can be combined in a cross-cutting manner to flexibly construct new embodiments, as long as such combination does not depart from the inventive spirit of this application and can meet the needs of the prior art or solve a certain deficiency in the prior art. Those skilled in the art should be aware of such modifications.

[0065] Please see Figure 1 In one embodiment of the Crypto-VP-based RISC-V virtual prototyping platform of this application, the platform includes:

[0066] The RISC-V virtual prototype platform based on the Crypto-VP architecture includes a CPU core using a 32-bit basic integer and multiplication / division extended RISC-V architecture, main memory, an executable and linkable format loader, a debug and monitor interface controller, a local interrupt controller, a platform-level interrupt controller, a transaction-level modeling 2.0 standard bus, an accelerator model, a coprocessor model, and a power consumption statistics and visualization module. The CPU core is connected to both the debug and monitor interface controller and the coprocessor model, and is connected to the transaction-level modeling 2.0 standard bus via an interface. The debug and monitor interface controller is connected to the main memory at the end furthest from the CPU core. Both the local interrupt controller and the platform-level interrupt controller are connected to the transaction-level modeling 2.0 standard bus via an interface. The .0 standard interface is connected to the transaction-level modeling 2.0 standard bus; the accelerator model is connected to the transaction-level modeling 2.0 standard bus through the transaction-level modeling 2.0 standard interface and is allocated to a specified address range of the CPU core; the executable and linkable format loader obtains the executable and linkable format files of the RISC-V architecture generated by an external GNU compiler set at one end, and is connected to the main memory at the other end; the main memory, the transaction-level modeling 2.0 standard bus, the accelerator model, the CPU core, the local interrupt controller, the platform-level interrupt controller, the debug and monitoring interface controller, and the executable and linkable format loader all integrate the power consumption statistics and visualization module, and each power consumption statistics and visualization module (Pwt-NM power consumption model) is connected to a graphical user interface.

[0067] Specifically, such as Figure 1As shown, the RISC-V virtual prototype platform based on the Crypto-VP architecture includes a CPU core using a 32-bit basic integer and multiplication-division extended RISC-V architecture (RV32 IM), main memory, an Executable and Linkable Format (ELF) loader, a Debug and Monitor Interface (DMI) controller, a Local Interrupt Controller (CLINT), a Platform Interrupt Controller (PLIC), a Transaction Modeling 2.0 (TLM2.0) bus, an accelerator model, a coprocessor model, and a power consumption statistics and visualization module (Pwt-NM power consumption model). The CPU core is connected to both the DMI controller and the coprocessor model, and is connected to the TLM2.0 bus via a TLM2.0 standard interface. The DMI controller is connected to the main memory at the end furthest from the CPU core. Both the CLINT and PLIC are connected to the TLM2.0 standard via the TLM2.0 interface. The accelerator model is connected to the Transaction Modeling 2.0 Standard (TLM2.0) bus via a Transaction Modeling 2.0 Standard (TLM2.0) interface and is assigned to a specified address range of the CPU core. The Executable and Linkable Format (ELF) loader obtains the RISC-V architecture executable and linkable format file generated by an external GNU compiler collection (GCC) on one end and connects to the main memory on the other end. The main memory, the Transaction Modeling 2.0 Standard bus, the accelerator model, the CPU core, the Local Interrupt Controller (CLINT), the Platform Interrupt Controller (PLIC), the Debug and Monitor Interface (DMI) controller, and the Executable and Linkable Format (ELF) loader all integrate the power consumption statistics and visualization module (Pwt-NM power consumption model), and each power consumption statistics and visualization module (Pwt-NM power consumption model) is connected to a graphical user interface.

[0068] In a specific embodiment, the coprocessor model interacts directly with the CPU core, defining custom instructions for the target algorithm. In the software layer, these custom instructions are compiled into single machine instructions using C inline assembly, where C inline assembly represents a programming method that directly embeds assembly language instructions into C language code. In the hardware layer, after the CPU core's instruction set emulator fetches instructions from the main memory, the decoder parses the register index and sends it to the coprocessor model. The coprocessor model calls the `read()` function to resolve register conflicts and obtain operands. After processing by the algorithm's computation unit, the result and the target register index are fed back to the CPU core, which then calls the `write()` function to complete the write-back. Simultaneously, the coprocessor model calls the `advance()` function to dynamically update the cycle count.

[0069] In a specific embodiment, the accelerator model interacts with the CPU core through the Transaction-Level Modeling 2.0 standard bus, and cross-compiles and links the C program, C++ program and standard library through the GNU Compiler Collection (GCC) to generate the executable and linkable format file of the RISC-V architecture. The executable and linkable format (ELF) file is then loaded into the main memory by the executable and linkable format (ELF) loader and read and executed by the CPU core.

[0070] In a specific embodiment, the CPU core is connected to the Debug and Monitor Interface (DMI) controller and the coprocessor model, and is connected to the Transaction-Level Modeling 2.0 standard bus via a Transaction-Level Modeling 2.0 standard bus interface. This includes: acquiring a CPU core using a 32-bit basic integer and multiplication / division extended RISC-V architecture, the DMI controller, the coprocessor model, and the Transaction-Level Modeling 2.0 standard bus; through the direct connection between the CPU core and the DMI controller, the CPU core can access the main memory to obtain instructions via the DMI controller; through the direct connection between the CPU core and the coprocessor model, the CPU core can transmit register indices and operands related to custom instructions to the coprocessor model, and the coprocessor model can return results and target register indices to the CPU core after processing the data; through the connection between the CPU core and the Transaction-Level Modeling 2.0 standard bus, the CPU core can perform transactional interactions with modules connected to the Transaction-Level Modeling 2.0 standard bus.

[0071] In a specific embodiment, the debug and monitor interface (DMI) controller, with one end away from the CPU core connected to the main memory, includes: acquiring a CPU core using a 32-bit basic integer and multiplication-division extended RISC-V architecture, a debug and monitor interface (DMI) controller, and main memory, wherein the main memory is used to store RISC-V architecture executable and linkable format files loaded by the executable and linkable format (ELF) loader; directly connecting one end of the debug and monitor interface (DMI) controller to the CPU core, and directly connecting the other end of the debug and monitor interface (DMI) controller away from the CPU core to the main memory, forming a connection between the CPU core and the debug and monitor interface. The Debug and Monitor Interface (DMI) controller provides a data transfer path for accessing main memory. Through this data transfer path, the CPU core reads instruction data from executable and linkable format files in main memory via the DMI controller. Simultaneously, the DMI controller integrates a power consumption statistics and visualization module (Pwt-NM power consumption model) to collect real-time static and dynamic power consumption data during the CPU core's access to main memory via the DMI controller. This static and dynamic power consumption data is then transmitted to a graphical user interface for display. A pipeline timing model is used to calculate the number of instructions per cycle, achieving synchronous acquisition of performance and power consumption data.

[0072] In a specific embodiment, both the local interrupt controller (CLINT) and the platform-level interrupt controller (PLIC) are connected to the transaction-level modeling 2.0 standard bus via a transaction-level modeling 2.0 standard interface, including:

[0073] The system acquires a local interrupt controller (CLINT), a platform-level interrupt controller (PLIC), and a transaction-level modeling 2.0 standard (TLM2.0) bus. The local interrupt controller (CLINT) generates local interrupt signals for the CPU core, the platform-level interrupt controller (PLIC) manages interrupt requests from external devices, and the transaction-level modeling 2.0 standard bus enables transaction interactions between modules in a RISC-V virtual prototyping platform based on the Crypto-VP architecture. Transaction-level modeling 2.0 standard interfaces are configured for both the local interrupt controller (CLINT) and the platform-level interrupt controller (PLIC). The local interrupt controller (CLINT) is then connected to the transaction-level modeling 2.0 standard (TLM2.0) bus via its configured TLM2.0 interface. The platform interrupt controller (PLIC) is connected to the transaction level modeling 2.0 standard (TLM2.0) bus via its configured transaction level modeling 2.0 standard (TLM2.0) interface. Power consumption statistics and visualization modules (Pwt-NM power consumption model) are integrated into the local interrupt controller (CLINT) and the platform interrupt controller (PLIC) respectively. This allows for real-time statistics of static and dynamic power consumption data during the process of the local interrupt controller (CLINT) and the platform interrupt controller (PLIC) connecting to the bus via the transaction level modeling 2.0 standard (TLM2.0) interface and transmitting interrupt signals. The static and dynamic power consumption data are then transmitted to a graphical user interface for display. A pipeline timing model is used to calculate the number of instructions per cycle, achieving synchronous acquisition of performance and power consumption data.

[0074] In a specific embodiment, the accelerator model is connected to the Transaction Level Modeling 2.0 (TLM2.0) bus via a Transaction Level Modeling 2.0 (TLM2.0) interface and is allocated to a specified address range of the CPU core, including:

[0075] The system acquires an accelerator model, a Transaction Level Modeling 2.0 (TLM2.0) bus, and a CPU core using a 32-bit basic integer and multiplication / division extended RISC-V architecture (RV32 IM). The accelerator model is used to implement hardware acceleration for the target algorithm. A TLM2.0 interface is configured for the accelerator model, establishing a connection between the accelerator model and the TLM2.0 bus, enabling data transfer between the accelerator model, the CPU core, and other modules. A specified address range accessible to the CPU core is allocated to the accelerator model, allowing the CPU core to read and write the accelerator model's external registers via memory address mapping to control its operation. Simultaneously, the accelerator model... The device model integrates the power consumption statistics and visualization module (Pwt-NM power consumption model), which is connected to the graphical user interface. The real-time statistical accelerator model interacts with the Transaction Level Modeling 2.0 standard (TLM2.0) bus through the Transaction Level Modeling 2.0 standard (TLM2.0) interface to execute the static and dynamic power consumption data during the target algorithm operation process, and transmits the static and dynamic power consumption data to the graphical user interface for display. The pipeline timing model is used to calculate the number of instructions per cycle, realizing the synchronous acquisition of performance and power consumption data.

[0076] In a specific embodiment, the Executable and Linkable Format (ELF) loader acquires the RISC-V architecture executable and linkable format file generated by an external GNU Compiler Collection (GCC) at one end, and connects to the main memory at the other end. This includes: acquiring the ELF loader, the main memory, and the external GNU Compiler Collection (GCC). The ELF loader is used to parse and load the RISC-V architecture executable file, and the GNU Compiler Collection (GCC) is used to cross-compile C programs, C++ programs, and standard libraries to generate the RISC-V architecture executable and linkable format file. A data interaction relationship is established between one end of the ELF loader and the external GNU Compiler Collection (GCC) to acquire the RISC-V architecture executable and linkable format file generated by the compiler collection. Simultaneously, the ELF loader... The other end is directly connected to the main memory, forming a file transfer path that sequentially consists of the GNU Compiler Collection (GCC), the Executable and Linkable Format (ELF) loader, and the main memory. Through this file transfer path, the Executable and Linkable Format (ELF) loader parses the RISC-V architecture executable and linkable format file obtained from the external GNU Compiler Collection (GCC), loads the instructions and data from the executable and linkable format file into a designated storage area of ​​the main memory for the CPU core to read and execute. Simultaneously, the power consumption statistics and visualization module (Pwt-NM power consumption model) is integrated into the Executable and Linkable Format (ELF) loader to collect static and dynamic power consumption data in real time during file acquisition, parsing, and loading. The static and dynamic power consumption data are then transmitted to a graphical user interface for display. A pipeline timing model is used to calculate the number of instructions per cycle, achieving synchronous acquisition of performance and power consumption data.

[0077] Based on any of the above embodiments, the target algorithm includes the SM4 algorithm.

[0078] like Figure 1As shown, the RISC-V virtual prototype platform based on the Crypto-VP architecture, named DSE-VP, consists of: a CPU core using a 32-bit basic integer and multiplication / division extended RISC-V architecture (RV32IM), main memory, an Executable and Linkable Format (ELF) loader, a Debug and Monitor Interface (DMI) controller, a Local Interrupt Controller (CLINT), a Platform Level Interrupt Controller (PLIC), a Transaction Level Modeling 2.0 (TLM2.0) bus, an accelerator model, a coprocessor model, and a power statistics and visualization module with a graphical user interface (Pwt-NM power model). RV32I is the RISC-V basic integer instruction set, while RV32M is a RISC-V instruction set extension specifically designed for integer multiplication and division operations. The CPU core can access main memory to obtain instructions via the TLM2.0 bus or the DMI controller. Furthermore, the coprocessor model can directly interact with the CPU core to execute custom instructions. Except for the coprocessor model, all components are connected to the bus via the TLM2.0 interface. The bus routes transactions from master devices to slave devices based on memory address mapping. The accelerator model is allocated a portion of the CPU core's address range, allowing the CPU core to control slave modules by reading and writing external registers via memory address mapping. Each module integrates a Pwt-NM power consumption model for real-time power calculation and display via a GUI. At the software level, the GCC toolchain is used to cross-compile and link C / C++ programs and standard libraries, generating an executable RISC-V ELF file, which is then loaded into the DSE-VP main memory for execution via ELFLoader.

[0079] In some embodiments, the Crypto-VP architecture is as follows: Figure 2 As shown, the platform consists of a CPU core, 32MB of random access memory, a DMA controller, two interrupt sources (CLINT and PLIC), a TLM2.0 bus module, SM3 / SM4 cryptographic accelerators, and other peripherals (UART, GPIO, etc.). The CPU core module adopts the RV32IM instruction set architecture, and its newly added multiplication and division instructions are suitable for cryptographic applications. All modules are connected to the bus via TLM2.0 sockets, and the bus routes transactions from the master device to the slave device according to memory address mapping. The integrated SM3 and SM4 cryptographic accelerators are allocated a portion of the CPU core's address range. In addition, the AHB interface, designed based on a register encapsulation layer, accesses the accelerators through embedded AHB sockets, allowing the CPU core to read and write external registers of the accelerators via memory address mapping, thereby controlling the slave modules.

[0080] The cryptographic algorithm program and the C / C++ standard library were compiled using a cross-compiler to generate an executable ELF file, which was then loaded into the virtual platform's main memory. The premise of the hardware-software co-design was to implement resource-intensive modules in hardware and the rest in software. Initially, preliminary partitioning was achieved by modeling the execution time of the cryptographic algorithm. Then, frequently called operations were implemented in hardware, while the high-level control modules were implemented in software. Finally, we simultaneously completed the co-design and verification of the software, hardware, and interface modules.

[0081] Furthermore, the SM3 module consists of padding, expansion, and compression operations. The input message is m, and the padding operation is implemented in software. In the expansion part, the length of the padded message m′ is an integer multiple of 512 bits n. Each 512-bit block B(i) is expanded into 132 words w0~w 67 w′0~w′ 63 The extension operation can be represented in the following form, which includes:

[0082] The formula for generating character expansion is expressed as follows:

[0083]

[0084] The formula for generating auxiliary characters is expressed as follows:

[0085]

[0086] The formula for the permutation function is expressed as follows:

[0087]

[0088] The recursive formula for the compression function is expressed as:

[0089] V(i+1) = CF(V(i), B(i));

[0090] Where m represents the original input message, which is the plaintext data to be hashed; m′ represents the message after padding, with a length that is an integer multiple of 512 bits n. The padding operation is implemented in software to meet the message length requirements of the SM3 algorithm; B(i) represents the i-th 512-bit block of the padded message m′, which is the input unit for the expansion operation. i This represents the i-th word (32 bits) generated by expanding B(i), with a total of w0~w... 67 , used as input for compression operations; w′ i Indicated by w i Further expanding the generated auxiliary characters, a total of w′0~w′ were generated. 63, assist in the calculation of compression operations. P1(x) represents a permutation function; V(i) represents the input value of the i-th round of compression operation; CF(·) represents a compression function; <<k represents a cyclic left shift operation of k bits; represents the exclusive-or operation, which is the main operator of logical operations in the SM3 algorithm and is used to achieve data confusion.

[0091] V(0) is the 256-bit initial value IV, and the hash value is V(n). Eight registers A to H are used in the compression process. To improve the performance of SM3, a task scheduling and register optimization strategy is proposed during the expansion process as Figure 3 shown; during the compression process, task scheduling and critical path optimization are applied to reduce latency and the number of registers as Figure 4 shown.

[0092] It can be seen that the data required for the second group of 64-round iterations can be obtained after the 4th round of the first group of 68-round iterations. Therefore, only 68-round iterations are required for the expansion. Compression can also be nested in the expansion, ultimately only increasing two clock cycles.

[0093] The SM4 module consists of two parts: round key generation and encryption / decryption. The block length and key length are both 128 bits. The round key generation part is as Figure 5 shown, generating 32 round keys through 32 iterations of the round function, which are represented as rk i , i = 0, 1,..., 31, where rk i represents the i-th round key.

[0094] First, the key MK = (MK0, MK1, MK2, MK3) is exclusive-ored with the system parameter FK, and the result is grouped as K0, K1, K2, K3 as the input of the round function. Among them, the formula of the round function is expressed as:

[0095]

[0096] Among them, T(·) represents the composite substitution operation, which is expressed as T(·) = L(τ(·)), and it includes three operations: exclusive-or, S-box substitution, and L transformation. CK i represents a 32-bit fixed parameter for differential calculation of the round function; MK represents the 128-bit initial key; FK represents the system parameter, and the exclusive-or with MK obtains the initial input K0, K1, K2, K3 of the round function; rk i represents the i-th round key.

[0097] Further, the decryption structure is the same as that of encryption. The difference between the round function used for encryption / decryption and round key generation lies in the L transformation. As Figure 6As shown, the input data is divided into four groups (X0, X1, X2, X3). After 32 rounds of round function calculations and inverse transformation R, a 128-bit output (Y0, Y1, Y2, Y3) is obtained. During the decryption process, the round keys are used in reverse order.

[0098] To achieve efficient operation of SM4, we adopt the following optimization strategies: First, the round key is pre-computed only when the key is updated, which significantly reduces the number of key expansion executions; second, a general round function structure is proposed for round key generation and encryption / decryption; in addition, time-division multiplexing technology is used to call the round function unit to reduce hardware resource overhead.

[0099] Furthermore, the SM3 / SM4 modules (SMx cores) are implemented as peripherals on the SoC platform. The peripheral interface design adopts the AHB bus protocol. For example... Figure 7 As shown, the SMx core's interface registers (such as input, output, status, and control registers) are generated by register wrappers. These registers transmit data to the socket-based AHB via the AHB interface controller, and the AHB socket enables transaction-level to AHB timing-level signal conversion. Furthermore, the cryptographic module connects to the TLM2.0 system bus via the TLM socket to interact with the master module. This interface design allows for more accurate simulation of hardware behavior.

[0100] Since existing full-system simulation simulators cannot provide high-performance, cycle-accurate results, we propose a hybrid-precision timing model and integrate it into the Virtual Platform (VP) to achieve fast and accurate performance evaluation of RISC-V-based SoC systems. As mentioned above, we propose cycle-accurate and relaxed timing models for cryptographic accelerators and other peripherals, respectively.

[0101] For RISC-V CPUs, a precise instruction timing model is proposed. First, the timing model is corrected by adjusting the latency of each instruction; then, a two-stage pipeline timing model is added. This makes the total program execution cycle approximate real hardware. In this design, we propose a timing configuration matching the E2031 core and combine it with a two-stage execution pipeline. Assuming that a single instruction takes one cycle to compute, and without data dependencies, the initial result latencies for store instructions, multiplication / division instructions, and other instructions are set to 2, 17 / 33, and 1 cycles, respectively. Based on this, a two-stage pipeline is added to simulate multi-cycle instructions, including store access instructions (store: 1-cycle result latency, load: 2-cycle result latency), multiplication / division instructions (4-cycle result latency), CSR instructions (2-cycle result latency), etc. The pipeline timing model structure is as follows: Figure 5 As shown, this model can reduce design errors and improve design accuracy.

[0102] In some embodiments, the DSE-VP coprocessor model is a core component designed to support RISC-V custom instruction function verification and design space exploration. Its core lies in achieving rapid function verification and PPA trade-off analysis at the instruction-level granularity through hardware / software collaboration. This model interacts directly with the RV32 IM CPU core, eliminating the need for data transmission via the TLM2.0 bus, thus significantly reducing communication overhead. In a specific implementation, taking the SM4 symmetric encryption algorithm as an example, the coprocessor model defines eight custom instructions, corresponding to key operations such as round functions and linear transformations. These instructions adopt the RISC-V R-Type encoding format, using the reserved opcode 0x7B and distinguishing functions through func3 and func7. Their software layer is implemented using C inline assembly. Figure 8 As shown, the `_STATIC_FORCEINLINE` macro ensures compilation into a single machine instruction. The hardware execution flow includes a complete pipeline stage: after the ISS fetches instructions from memory, the decoder parses the register index and sends it to the coprocessor model. The `read()` function resolves register conflicts and obtains operands. The SM4 arithmetic unit processes the data and returns the result and the target register index. Finally, the `write()` function completes the write-back. The innovation of the coprocessor model lies in its tightly integrated pipeline timing control method, which is inherited from the Crypto-VP platform. The `advance()` function dynamically updates the cycle count to ensure timing accuracy.

[0103] In some embodiments, the DSE-VP accelerator model is a key component designed to support diverse hardware accelerator modeling and design space exploration. Its core architecture enables rapid integration and verification of hardware functions through SystemC and the TLM2.0 protocol. The model employs a modular design. Taking the SM4 encryption algorithm as an example, its structure comprises four main parts: the SM4_Top module handles overall coordination, the SM4_Reg module provides the register interface, the SM4_Socket module implements TLM2.0 bus communication, and the SM4_Core module encapsulates the functional units of the two sub-cores: KeyExp and EncDec. This hierarchical architecture allows the accelerator to interact efficiently with the CPU core via memory mapping. Specifically, SM4_Socket maps 10 control registers to the main memory address range 0x50003000 to 0x50003024, allowing the CPU to control the accelerator behavior through simple memory read and write operations.

[0104] In terms of register design, the SM4_Reg module is designed for the characteristics of the 32-bit CPU data bus. It divides the 128-bit input and output data into four 32-bit registers (such as x_in_0 to x_in_3 and y_out_0 to y_out_3), and is equipped with a control register and a state register to achieve fine operation control.

[0105] like Figure 9 As shown, the control register switches functions through bit field definitions (such as the Reset bit and the EncDec Mode bit): when the Reset bit is set to 0, the accelerator is reset; when the EncDec Mode bit is set to 1, the encryption process is started. The status register provides real-time feedback on the running status; for example, a status value of 2 indicates that key expansion is ready. This design allows the software layer to trigger hardware acceleration operations simply by writing control parameters through storage instructions, significantly reducing instruction overhead.

[0106] In some embodiments, a design space exploration case for the SM4 algorithm and main memory is used to verify the DSE-VP method: First, six types of computing modules are constructed for different implementations of the national cryptographic standard algorithm SM4, including a pure software implementation (SM4 SW), an instruction-optimized version (SM4 FF, SM4 TT, SM4 LL, SM4 NN), and a hardware-accelerated version (SM4 HW). These different implementations are mapped to different computing unit models in DSE-VP: the pure software version is directly executed by the RISC-V core; the instruction-optimized version implements some operations in hardware through a custom instruction mechanism (custom3 encoding space) and a coprocessor interface; and the hardware-accelerated version is embedded in the system as an external accelerator and interacts with the main core through the TLM bus. This configuration fully demonstrates the platform's custom instruction and coprocessor verification capabilities. During simulation, the coprocessor model and ISS achieve periodic timing interaction through the read / advance / write interface, accurately reflecting the performance differences and latency characteristics brought about by different implementations while ensuring correct functionality.

[0107] Meanwhile, to verify the platform's performance-power consumption joint evaluation mechanism, the experiment further conducted comprehensive simulations of the system under five main memory models (RRAM, STT-MRAM, PCRAM, 2D-DRAM, 3D-DRAM) and four memory control strategies (PerfectMemory, FCFS, FRFCFS, FRFCFS-WQF), resulting in 120 design space combinations. During the simulation, the DSE-VP platform utilized the Pwt-NM power consumption modeling system to perform real-time statistics on the static and dynamic power consumption of each module: the main memory section employed a trace-based fine-grained power consumption model, capable of estimating energy consumption based on read / write request timestamps, access frequencies, and memory type parameters (read / write energy, hold time, cell area, etc.); the processor and coprocessor sections used an activity factor model to evaluate dynamic power consumption. Combined with the pipeline timing model and time quantum retention mechanism, the system can simultaneously obtain IPC (instructions per cycle) and power consumption (W) for each configuration, achieving joint performance and power consumption evaluation. Experimental results show that the SM4HW has the highest IPC (0.929) and a power consumption of 2.174W, with a performance-to-power ratio (PP_tradeoff) of 0.427. In contrast, the SM4 SW has an IPC of 0.783, a power consumption of 2.002W, and a PP_tradeoff of 0.391, verifying the advantages of hardware acceleration and custom instruction mechanisms in improving performance and energy efficiency.

[0108] In the main memory design space exploration, DSE-VP further analyzed the impact of storage architecture on overall system performance and power consumption by traversing different memory types and control strategies. Experimental results show that non-volatile memories (such as PCRAM and STT-MRAM) have significant advantages in energy consumption, while DRAM-type memories have a performance advantage in access latency. Finally, the platform determined the optimal system configuration for performance and power consumption tradeoff through Pareto optimal selection under the automated DSE process—PCRAM main memory combined with FRFCFS-WQF control strategy and SM4 hardware acceleration unit. This combination achieved the best overall energy efficiency index (PP_tradeoff) (approximately 0.419), verifying the ability of this invention to quickly find the optimal solution in complex design spaces.

[0109] As can be seen from the above embodiments, compared with the prior art, this application addresses the problem that the prior art lacks a RISC-V virtual prototyping platform based on the Crypto-VP architecture that can achieve joint performance and power consumption analysis at the electronic system level, support custom instruction function verification, and efficiently explore the design space. This application has, but is not limited to, the following beneficial effects:

[0110] Firstly, existing RISC-V virtual prototyping platforms (such as RISC-CV-VP and gem5) mostly only support performance analysis and require external tools to evaluate power consumption, which is a complex and time-consuming process. In contrast, the RISC-V virtual prototyping platform based on the Crypto-VP architecture proposed in this application integrates the Pwt-NM power consumption model into all core modules, which can statistically analyze static / dynamic power consumption in real time and display it intuitively through a graphical user interface (GUI). At the same time, it combines pipeline timing models to calculate IPC (instructions per cycle), realizing the synchronous acquisition of performance and power consumption data. It can complete the analysis of core dimensions such as performance, power consumption, and area without additional tools.

[0111] Secondly, it enhances support for custom instructions and coprocessors, completing functional verification scenarios. Existing platforms have limited capabilities in modeling RISC-V custom instructions and coprocessors, making it difficult to meet the design requirements of specific applications. DSE-VP features a specially designed coprocessor model that supports instruction-level verification of custom instructions. It ensures the independence of instruction compilation through C inline assembly, while the coprocessor interacts directly with the CPU core, reducing communication overhead. This allows for efficient verification of the functional correctness and timing rationality of custom instructions, covering the entire process from software instruction definition to hardware execution verification.

[0112] Third, based on electronic system-level (ESL) modeling, the simulation and exploration speed is improved. Traditional design space exploration relies on RTL-level description, which requires a complete front-end and back-end process to obtain PPA results, with a cycle of up to several weeks. However, the RISC-V virtual prototyping platform based on the Crypto-VP architecture in this application can carry out exploration in the early stage without waiting for the underlying hardware implementation.

[0113] Fourth, automated Pareto optimization reduces the cost of manual decision-making. During the design space exploration, the platform can automatically calculate the performance-power trade-off indicators under different configurations and select the optimal solution through the Pareto optimization principle.

[0114] Fifth, the RISC-V virtual prototyping platform based on the Crypto-VP architecture in this application is compatible with diverse hardware acceleration and storage solutions, and can be flexibly configured according to design goals (such as high performance, low power consumption, and low cost). For example, PCRAM storage can be used for power-sensitive scenarios, while the SM4 hardware accelerator can be enabled for performance-sensitive scenarios, adapting to the SoC design needs of multiple fields such as embedded systems and edge computing.

[0115] Sixth, the RISC-V virtual prototyping platform based on the Crypto-VP architecture proposed in this application has the advantages of open source compatibility, lowering the threshold for industrial applications. The platform is built on the open-source RISC-V architecture and the GCC toolchain. The software layer supports cross-compilation of C / C++ programs, and the hardware modules adopt a modular design, making it easy for developers to expand functionality according to their needs. At the same time, the platform is compatible with the existing RISC-V software ecosystem and can be used without refactoring the development environment, lowering the application threshold for enterprises and research institutions.

[0116] The above description is only a partial embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A RISC-V virtual prototyping platform based on the Crypto-VP architecture, characterized in that, The RISC-V virtual prototype platform based on the Crypto-VP architecture includes a CPU core using a 32-bit basic integer and multiplication / division extended RISC-V architecture, main memory, an executable and linkable format loader, a debug and monitor interface controller, a local interrupt controller, a platform-level interrupt controller, a transaction-level modeling 2.0 standard bus, an accelerator model, a coprocessor model, and a power consumption statistics and visualization module. The CPU core is connected to both the debug and monitor interface controller and the coprocessor model, and is connected to the transaction-level modeling 2.0 standard bus via a transaction-level modeling 2.0 standard bus interface. The end of the debug and monitor interface controller furthest from the CPU core is connected to the main memory. Both the local interrupt controller and the platform-level interrupt controller are connected to the transaction-level modeling 2.0 standard bus through the transaction-level modeling 2.0 standard interface; The accelerator model is connected to the Transaction-Level Modeling 2.0 standard bus via the Transaction-Level Modeling 2.0 standard interface and is assigned to a specified address range of the CPU core; The executable and linkable format loader obtains the executable and linkable format files of the RISC-V architecture generated by an external GNU compiler set at one end, and is connected to the main memory at the other end; The main memory, the transaction-level modeling 2.0 standard bus, the accelerator model, the CPU core, the local interrupt controller, the platform-level interrupt controller, the debug and monitoring interface controller, and the executable and linkable format loader all integrate the power consumption statistics and visualization module, and each power consumption statistics and visualization module is connected to a graphical user interface.

2. The RISC-V virtual prototyping platform based on the Crypto-VP architecture according to claim 1, characterized in that, The coprocessor model interacts directly with the CPU core, defines custom instructions for the target algorithm, and compiles the custom instructions into a single machine instruction through C inline assembly in the software layer. Here, C inline assembly refers to a programming method that directly embeds assembly language instructions into C language code. In the hardware layer, after the instruction set emulator of the CPU core fetches instructions from the main memory, the decoder parses the register index and sends it to the coprocessor model. The coprocessor model calls the read() function to resolve register conflicts and obtain operands. After processing by the algorithm operation unit, the result and the target register index are fed back to the CPU core, which calls the write() function to complete the write-back. At the same time, the coprocessor model calls the advance() function to dynamically update the cycle count.

3. The RISC-V virtual prototyping platform based on the Crypto-VP architecture according to claim 1, characterized in that, The accelerator model interacts with the CPU core through the Transaction-Level Modeling 2.0 standard bus, and cross-compiles and links C programs, C++ programs and standard libraries through the GNU compiler set to generate executable and linkable format files for the RISC-V architecture. These executable and linkable format files are then loaded into the main memory by the executable and linkable format loader and read and executed by the CPU core.

4. The RISC-V virtual prototyping platform based on the Crypto-VP architecture according to claim 1, characterized in that, The CPU core is connected to the debug and monitoring interface controller and the coprocessor model respectively, and is connected to the transaction-level modeling 2.0 standard bus through the transaction-level modeling 2.0 standard bus interface, including: Acquire CPU cores, debug and monitor interface controllers, coprocessor models, and transaction-level modeling 2.0 standard buses based on the RISC-V architecture with 32-bit basic integers and multiplication and division extensions; The direct connection between the CPU core and the debug and monitor interface controller allows the CPU core to access the main memory to obtain instructions via the debug and monitor interface controller. Through the direct connection between the CPU core and the coprocessor model, the CPU core can transmit register indices and operands related to custom instructions to the coprocessor model, and the coprocessor model can return the results and target register indices to the CPU core after processing the data. By connecting the CPU core to the Transaction-Level Modeling 2.0 standard bus, the CPU core can perform transaction interactions with modules connected to the Transaction-Level Modeling 2.0 standard bus.

5. The RISC-V virtual prototyping platform based on the Crypto-VP architecture according to claim 4, characterized in that, The debug and monitoring interface controller is connected to the main memory at the end furthest from the CPU core, including: Acquire a CPU core, debug and monitor interface controller, and main memory that employ a 32-bit basic integer and multiplication and division extended RISC-V architecture, wherein the main memory is used to store executable and linkable format files of the RISC-V architecture loaded by the executable and linkable format loader. One end of the debug and monitor interface controller is directly connected to the CPU core, and the other end of the debug and monitor interface controller, which is away from the CPU core, is directly connected to the main memory, forming a data transmission path for the CPU core to access the main memory through the debug and monitor interface controller; Through the data transmission path, the CPU core reads instruction data from executable and linkable format files in the main memory via the debug and monitor interface controller. Simultaneously, the power consumption statistics and visualization module is integrated into the debug and monitor interface controller to collect static and dynamic power consumption data in real time during the CPU core's access to the main memory through the debug and monitor interface controller. The static and dynamic power consumption data are then transmitted to the graphical user interface for display. The number of instructions per cycle is calculated using a pipeline timing model, achieving synchronous acquisition of performance and power consumption data.

6. The RISC-V virtual prototyping platform based on the Crypto-VP architecture according to claim 1, characterized in that, Both the local interrupt controller and the platform-level interrupt controller are connected to the transaction-level modeling 2.0 standard bus via the transaction-level modeling 2.0 standard interface, including: The system acquires a local interrupt controller, a platform-level interrupt controller, and a transaction-level modeling 2.0 standard bus. The local interrupt controller is used to generate local interrupt signals for the CPU core, the platform-level interrupt controller is used to manage interrupt requests from external devices, and the transaction-level modeling 2.0 standard bus is used to implement transaction interactions between various modules in the RISC-V virtual prototype platform based on the Crypto-VP architecture. Configure transaction-level modeling 2.0 standard interfaces for the local interrupt controller and the platform-level interrupt controller respectively. Connect the local interrupt controller to the transaction-level modeling 2.0 standard bus through its configured transaction-level modeling 2.0 standard interface, and connect the platform-level interrupt controller to the transaction-level modeling 2.0 standard bus through its configured transaction-level modeling 2.0 standard interface. The local interrupt controller and the platform-level interrupt controller are respectively integrated with power consumption statistics and visualization modules to collect static and dynamic power consumption data in real time during the process of the local interrupt controller and the platform-level interrupt controller accessing the bus and transmitting interrupt signals through the transaction-level modeling 2.0 standard interface. The static and dynamic power consumption data are transmitted to the graphical user interface for display. The number of instructions per cycle is calculated using a pipeline timing model to achieve synchronous acquisition of performance and power consumption data.

7. The RISC-V virtual prototyping platform based on the Crypto-VP architecture according to claim 1, characterized in that, The accelerator model is connected to the Transaction-Level Modeling 2.0 standard bus via the Transaction-Level Modeling 2.0 standard interface and is allocated to a specified address range of the CPU core, including: The accelerator model, transaction-level modeling 2.0 standard bus, and CPU core using a 32-bit basic integer and multiplication-division extended RISC-V architecture are obtained. The accelerator model is used to implement hardware acceleration of the target algorithm. Configure the accelerator model with a transaction-level modeling 2.0 standard interface, and establish a connection between the accelerator model and the transaction-level modeling 2.0 standard bus through the interface, so that the accelerator model can transmit data with the CPU core and other modules through the bus; A specified address range accessible to the CPU core is allocated to the accelerator model, enabling the CPU core to read and write the external registers of the accelerator model via memory address mapping to control its operation. Simultaneously, a power consumption statistics and visualization module is integrated into the accelerator model. This module is connected to a graphical user interface to collect real-time statistics on static and dynamic power consumption data during the accelerator model's interaction with the Transaction-Level Modeling 2.0 standard bus via the Transaction-Level Modeling 2.0 standard interface and the execution of the target algorithm. This static and dynamic power consumption data is then transmitted to the graphical user interface for display. A pipeline timing model is used to calculate the number of instructions per cycle, achieving synchronous acquisition of performance and power consumption data.

8. The RISC-V virtual prototyping platform based on the Crypto-VP architecture according to claim 1, characterized in that, The executable and linkable format loader acquires the executable and linkable format files of the RISC-V architecture generated by an external GNU compiler set at one end, and is connected to the main memory at the other end, including: The executable and linkable format loader, main memory, and external GNU compiler set are obtained. The executable and linkable format loader is used to parse and load RISC-V architecture executable files. The GNU compiler set is used to cross-compile C programs, C++ programs, and standard libraries to generate RISC-V architecture executable and linkable format files. One end of the executable and linkable format loader establishes a data interaction relationship with an external GNU compiler set to obtain the RISC-V architecture executable and linkable format files generated by the compiler set. At the same time, the other end of the executable and linkable format loader is directly connected to the main memory, forming a file transfer path in the order of GNU compiler set, executable and linkable format loader, and main memory. Through the file transfer path, the executable and linkable format loader parses and processes the RISC-V architecture executable and linkable format files obtained from the external GNU compiler set, and loads the instructions and data in the executable and linkable format files into a designated storage area of ​​the main memory for the CPU core to read and execute. At the same time, the power consumption statistics and visualization module is integrated into the executable and linkable format loader to collect static and dynamic power consumption data in real time during the file acquisition, parsing and loading process, and transmits the static and dynamic power consumption data to the graphical user interface for display. The pipeline timing model is used to calculate the number of instructions per cycle to achieve synchronous acquisition of performance and power consumption data.

9. The RISC-V virtual prototyping platform based on the Crypto-VP architecture according to claim 7, characterized in that, The target algorithm includes the SM4 algorithm.

Images