RISC-V security SoC verification and evaluation method based on virtual platform

Abstract

The invention belongs to the technical field of SoC design and verification, and discloses an RISC-V security SoC verification and evaluation method based on a virtual platform, and the method comprises the steps: building a processor behavior mode according to a target design requirement, and carrying out the configuration of a selectable RISC-V instruction set; building a transaction-level model of the bus, the peripheral and the security module library; performing circuit-level design, and defining a time sequence, an area and a power consumption model of each module; adjusting the configuration file setting of the security module library to determine a security module to be started, constructing an SoC virtual platform, and calculating the area of the designed security SoC; simulating an application program on the virtual platform, and recording time sequence and power consumption data simulated by the virtual platform; the simulation result is compared with the expected area, time sequence and power consumption data, and if the comprehensive evaluation result meets the safety SoC design requirement, the virtual platform designed in the round is determined as the final design scheme. According to the invention, simulation verification and performance evaluation of the RISC-V security SoC are realized.

Description

Technical Field

[0001] The present invention belongs to the technical field of SoC design and verification, and particularly relates to a method for verifying and evaluating a RISC-V secure SoC based on a virtual platform, which is particularly suitable for efficient modeling, simulation, and performance analysis of a RISC-V secure SoC. Background Art

[0002] With the rapid development of the Internet of Things and intelligent devices, the improvement of system integration and the increase in design complexity, virtual platforms play an important role in the integrated circuit design and verification process. Traditional hardware verification methods usually rely on physical prototypes, which are not only time-consuming and costly but also difficult to meet the requirements of rapid iteration and verification. In addition, existing simulation tools often face the problem of low efficiency when dealing with complex security functions and multi-core architectures. The process from RTL hardware design and simulation to software development and chip performance evaluation is extremely time-consuming. Once the chip performance fails to meet market demands, all the long-term efforts will be in vain. Therefore, architecture design and simulation verification in the early stage of chip design are extremely important.

[0003] The open-source instruction set architecture, namely the RISC-V architecture, has become the first choice for the design of many system-on-chip (SoC) due to its open-source nature and flexibility. In the design process of SoC, simulation verification is a crucial link, which is not only used to verify the functional correctness of the design but also to evaluate the performance metrics of the SoC. With the rapid development of technologies such as the Internet of Things and cloud computing, the application scenarios of SoC are becoming increasingly widespread, and the security threats it faces have become more diverse and complex, which poses higher requirements for the security design of SoC. Building an efficient and secure SoC has become an urgent need in the industry. In order to accelerate the design of RISC-V secure SoC, it is very important to effectively evaluate and select the most suitable high-performance security modules. Although the electronic system level (ESL) simulator can provide hardware modeling and verification, it has limitations in quickly and accurately evaluating the performance of different security modules and is difficult to meet the growing security and performance requirements. In this context, how to effectively achieve rapid verification and performance evaluation of secure SoC design has become particularly important. Summary of the Invention

[0004] The purpose of the present invention is to propose a method for verifying and evaluating a RISC-V secure SoC based on a virtual platform, aiming to improve the speed of simulation verification and comprehensively evaluate the performance metrics such as power consumption, area, and timing of each key module (such as the processor core, security module, etc.) in the RISC-V secure SoC design, reduce design risks, and provide a powerful and flexible virtual verification environment for designers.

[0005] To achieve the above object, the present invention adopts the following technical solutions: A method for verifying and evaluating a RISC-V secure SoC based on a virtual platform, comprising the following steps: Step 1. According to the target design requirements of the RISC-V secure SoC, establish a processor behavior model, configure the optional RISC-V instruction set, and complete the conversion logic modeling from instructions to transaction processing; Step 2. Establish a transaction-level model of the bus and peripheral modules, including abstracting the functional characteristics of the peripheral modules and defining the interfaces and transaction types of the bus; Step 3. Establish a transaction-level model of the security module library, including constructing security modules and a security management unit to handle bus transactions, and designing a configuration file to achieve dynamic switching of security modules; Step 4. Use a hardware description language to perform circuit-level design on each module, namely the processor, security module library, bus, and peripheral modules, and analyze the power consumption, timing, and area metrics of each module through EDA tools; Step 5. Define timing, area, and power consumption models for each module according to the obtained performance index data; Step 6. According to the target design requirements of the RISC-V secure SoC, confirm different combinations of security modules, and adjust the settings of the security module library configuration file to determine the security modules to be enabled. Integrate the processor, security modules, and peripheral modules to build a SoC virtual platform, and complete the communication between modules through bus mapping; Step 7. Calculate the area of the designed secure SoC according to the constructed SoC virtual platform; Step 8. Compile test cases for platform simulation and record the timing and power consumption data of the virtual platform simulation; Step 9. Compare the simulation results with the expected area, timing, and power consumption data, and comprehensively evaluate whether the design of the SoC virtual platform meets the performance requirements of the secure SoC design; Step 10. If the result of the comprehensive evaluation does not meet the target design requirements, return to Step 6; otherwise, use the SoC virtual platform constructed in this round as the final design solution, that is, construct a secure SoC virtual platform that meets the design requirements.

[0006] The present invention has the following advantages: The present invention relates to a method for verifying and evaluating a RISC-V secure SoC based on a virtual platform. By specifically adapting the virtual platform, a virtual simulation platform compatible with the verified secure SoC is provided, ensuring high system performance and optimization, balancing performance and resource consumption, and simplifying the development and verification processes of the verified processor. Using the virtual platform for simulation verification can comprehensively cover various security test scenarios, ensuring the correctness and reliability of the secure SoC design. The clock and delay mechanisms are used to simulate the cycle-accurate and delay characteristics on actual hardware, ensuring the accuracy of the timing model. Power consumption and area attributes are added to the interfaces of each module, and synchronization between different modules is achieved through event passing, ensuring the coordination among modules during the simulation process. By comparing the performance metrics (delay, power consumption, area) of each module on the secure SoC virtual platform, the performance of the secure SoC virtual platform is evaluated, and the overall design is optimized. A transaction-level model of the security module library is constructed, and the dynamic switching of each security module is managed through a configuration file, making the system structure clear and easy to expand. Communication between modules is completed through the bus ports of the transaction-level bus, improving the flexibility and interoperability of the system. The present invention effectively realizes the rapid verification and performance evaluation of the RISC-V secure SoC design, improving the design efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1 is the operation flowchart of the method for verifying and evaluating a RISC-V secure SoC based on a virtual platform in the present invention.

[0008] Figure 2 is the architecture diagram of the SoC virtual platform built in the embodiment of the present invention.

[0009] Figure 3 is the structural block diagram of the security module library built in the embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0010] The present invention will be further described in detail below with reference to the drawings and specific embodiments:

[0011] Embodiment 1 This embodiment describes a method for verifying and evaluating a RISC-V secure SoC based on a virtual platform. By establishing a SoC virtual platform, efficient modeling, simulation, and performance analysis of the RISC-V secure SoC can be achieved.

[0012] The inventive concept of this method is as follows: Based on the verified RISC-V secure SoC, a fully functional virtual platform is constructed. First, the behavior mode of the processor is established, and the processor core with the optional RISC-V instruction set is integrated into the virtual platform to complete the logic modeling of the conversion from instructions to transaction processing. A security module library is established. The security management unit is responsible for receiving and processing bus transactions and passing the transactions to the corresponding security modules for processing. Different security modules are dynamically switched through a configuration file to evaluate and analyze the performance of different security modules, thereby optimizing the security and performance of the system. A transaction-level model of the bus and peripherals is established. Circuit-level design is carried out, and EDA tools are called to comprehensively analyze and define the timing constraints and area-power consumption models to construct a complete virtual platform for the secure SoC. Real-time monitoring and optimization of the performance of the SoC during the design phase contribute to the realization of a more energy-efficient SoC design.

[0013] As Figure 1 shown, the method for verifying and evaluating a RISC-V secure SoC based on a virtual platform includes the following steps: Step 1. According to the target design requirements of the RISC-V secure SoC, establish the behavior mode of the processor, configure the optional RISC-V instruction set, complete the interface definition, and implement the logical conversion from instructions to transaction processing.

[0014] Define the behavior mode of the processor, and use the sc_module class to create the processor core module; implement the arithmetic logic unit and program counter components as independent sc_module instances; model the internal state of the processor, including the update logic of register values and program counters, and use sc_signal to store the current state of the registers. When an instruction is executed, the PC value is updated according to the length of the current instruction.

[0015] Use the event-driven mechanism to manage the execution process of the processor. By defining sc_event and sc_process, corresponding events are triggered when the processor reads instructions from memory, undergoes state changes, or receives external signals. Each event activates the corresponding sc_process, thereby completing the decoding and execution of instructions. The instruction simulation of the processor is based on the event-triggered state transition logic, which converts instructions into corresponding transactions.

[0016] By defining boolean flags for optional instruction sets, different instruction sets can be dynamically enabled or disabled in a virtual platform; enabling different instruction sets adds new instructions, and during the execution process of the processor, the instruction decoding and execution processes perform corresponding processing logics according to the enabled instruction sets; encapsulate the processing logics of different instruction sets in independent modules; by selecting different instruction sets, the performance of the processor under different configurations can be tested, the instruction set most suitable for the current design requirements can be determined, and the best hardware design can be found. For example, vector instruction sets can accelerate the calculation of processing large-scale data and are suitable for high-performance computing; compressed instruction sets can reduce the size of program code and improve the efficiency of instruction caches.

[0017] Define the interface module required for the processor to interact with the transaction-level bus, and perform data interaction with the security module library and peripheral modules through the bus. This interface module integrates the functions of instruction and data memory access and is responsible for processing and forwarding the memory read and write requests of the processor.

[0018] Step 2. According to the functional requirements of the bus and peripheral modules of the verified RISC-V secure SoC and the interaction methods with other modules, select the bus architecture and determine the functional characteristics and interfaces of the peripheral modules that need to be built; build the transaction-level models of the bus and peripheral modules, perform high-level abstractions on the functional characteristics and interfaces of the peripheral modules, and define the transaction interfaces and transaction types of the bus.

[0019] Establish target sockets for each peripheral module to receive the transactions transmitted by the bus, create the register mapping tables of each peripheral module, allocate addresses and corresponding register objects for each register, and define the read and write operations of the register and the processing process of the control signals of the data in the register access processing function; define the bus signals, including address, data pointer, data length, transaction command, and response signals; define the processing function of the transaction-level bus to implement basic bus interactions. In the processing function, obtain the transmission information of the transaction, find the register through the address, and perform the read and write operations according to the command.

[0020] Step 3. Build the transaction-level model of the security module library, design the configuration file to define the parameters and enabled status of each security module, and manage the dynamic switching between security modules; build the security management unit responsible for receiving and processing bus transactions, select the security module according to the configuration file, and pass the transaction to the corresponding security module for processing; design the security algorithms required for each security module to implement processing such as encrypting, decrypting, and signature verification of the input data.

[0021] Adopting a modular design concept, the sc_module class is used to create a security management unit and different security modules. The security management unit processes the transmission of transactions in the security module library. The processor accesses the control registers and status registers of the security module library through memory address mapping to obtain the status of the security module. The control data input register is responsible for receiving transactions, and the data output register stores the results of transaction processing. The synchronization between the security module and the security management unit is achieved through an event-driven synchronization mechanism.

[0022] The security management unit receives processor requests through the blocking transmission callback function of the target socket. The requests contain the required data types, status, and control information. A register mapping table is created, and addresses and corresponding register objects are assigned to each register. The register access processing function is set. When there is a register access request, the function will be called to store and read register data and update the register status information. The thread functions are called: rxpush is responsible for receiving data and storing it in the register, and txpull is responsible for reading data from the register and transmitting it into the security module. The semaphore mechanism is used to ensure data synchronization between threads, waiting for the data ready notification from the rxpush thread.

[0023] During the data processing of the security module, the sending thread of the security management unit is called to obtain register information. According to the obtained control register information, the current processing type to be executed (such as encryption, decryption, hash calculation, etc.) and the required related parameters (such as keys, data lengths, etc.) are determined. The security algorithm of different security modules is called according to the data in the input register to process the data. The internal state of the security module is updated according to the processing results. The security management unit stores the data processing results and the updated status information in the corresponding registers by calling the receiving thread.

[0024] The process of dynamic switching of each security module and the design of the security algorithm are as follows: The names, types, algorithms, and required parameters (key lengths, encryption modes) of each security module are defined in the configuration file. Each security module has an independent configuration item in the configuration file, supporting the independent enabling and configuration of the module. A flag bit is set to enable or disable a certain security module, such as AES, PUF, SHA-1, SHA-256, SM1, SM2, SM3, SM4, DES, MD5, RSA, DSA, ECC, etc. When the virtual platform starts the simulation, the configuration file will be parsed first, and the corresponding security modules and security algorithms will be initialized according to the parameters of the configuration file.

[0025] Each security module needs to implement specific security algorithms. According to the functions of the security module, different security algorithms are designed and implemented. For example, the design of the SHA-256 hash algorithm focuses on data compression and digest generation. First, the input data is padded to make its length meet the condition that the remainder after modulo 512-bit is 448-bit, and then the data is processed in blocks. In the processing of each block, the intermediate state values are continuously updated through a series of logical functions (such as Ch, Maj, Σ0, Σ1, etc.) and circular shift operations. Finally, these intermediate state values are combined to obtain a hash value of a fixed length; for the AES symmetric algorithm, the round function is designed first. The byte substitution operation performs a non-linear substitution on the data by defining a lookup table S-box, converting the input byte into an output byte to achieve data confusion. The row shift and column confusion operations perform linear permutations on the data to spread the data information. The round key addition operation combines the round key with the data through exclusive-or operation. The entire encryption process is multiple rounds of iteration of these operations, increasing the degree of data confusion and diffusion in each round to ensure data security.

[0026] All security algorithms are encapsulated through corresponding transaction interfaces to ensure that the data interaction between security modules does not affect the independence of security algorithms.

[0027] Step 4. Use a hardware description language to perform circuit-level design on each module, namely the processor, security module library, bus, and peripheral modules, and analyze the power consumption, timing, and area metrics of each module through EDA tools.

[0028] Based on the processor behavior model defined in Step 1, the security module library defined in Step 2, and the transaction-level model of the bus and peripheral modules defined in Step 3, the processor, security module library, bus, and peripheral modules are divided into actual hardware circuit blocks and gradually transformed into the target hardware structure; for the processor module, the instruction set architecture and processor execution process described in a high-level language are transformed into a specific hardware circuit structure, including an instruction decoder, execution unit, data path, etc. When the functional model of the security module library is transformed into hardware implementation, according to different security algorithms and protocols, the corresponding hardware circuit structures are designed, such as the hardware implementation of encryption algorithms, the hardware circuit of authentication protocols, etc. When the transaction-level model of the bus and peripheral modules is transformed into a hardware structure, considering the arbitration mechanism of the bus, data transfer protocol, and the functional requirements of the peripheral modules, the hardware parts such as a bus controller and peripheral interface circuit are designed.

[0029] Define specific interfaces and timing requirements for each module. According to the performance requirements and working frequency needs of the verified RISC-V secure SoC, define clock signals, timing paths, synchronous logic, and asynchronous logic to ensure that the circuit meets the timing constraints. When defining the interfaces, clarify the data transfer protocols and signal types between each module, and implement communication between modules through signal lines; clarify the hardware resources required for each module (such as memories, multipliers, etc.), and define the connection relationships between these modules and the hardware resources.

[0030] Call the EDA synthesis tool for synthesis analysis, including logic synthesis, placement and routing, to generate the gate-level netlist of the target hardware, and perform power consumption and area analysis on the gate-level netlist of the target hardware, calculate the static power consumption, dynamic power consumption, and the total area of the design, and generate power consumption and area reports; then call the timing analysis tool of EDA. By extracting the gate-level netlist of the target hardware, determine the clock paths of the generated secure SoC hardware architecture according to the propagation paths of the clock signals in the secure SoC hardware architecture; and according to the timing constraints, analyze the entire hardware architecture, identify the critical paths of the generated secure SoC hardware architecture, and calculate the delays of each critical path and clock path.

[0031] According to the results of the EDA tool synthesis analysis and timing analysis, record the key power consumption, timing, and area metrics of the generated secure SoC hardware architecture, which include the delays of critical paths and clock paths, power consumption distribution, and area occupancy information.

[0032] Step 5. Define timing, area, and power consumption models for each module according to the obtained performance metric data.

[0033] According to the key performance metric data determined in Step 4, define data transfer delays and data processing delays for each module of the virtual platform, namely the processor, peripheral modules, bus, and secure module library; combine the structural types and state information changes of the modules to define area and power consumption models for each module library.

[0034] Based on the key metric data determined in Step 4, utilize the clock and delay mechanisms to simulate the cycle accuracy and delay characteristics on actual hardware. For the processor timing model, use the sc_clock class to define the clock signal, clarify the number of clock cycles required for each instruction in each pipeline stage, and trigger signal and state changes through event-driven means, that is, each instruction will trigger different events in sequence to drive the state changes of the instruction in each pipeline stage. For the bus timing model, simulate the data transmission delay through the delay mechanism of transaction-level modeling, use the sc_time class to control the event time interval, and adjust the transmission delay of the transaction according to the local time. For the timing models of peripheral modules and the security module library, use timestamps to mark the time from receiving a request to starting to respond and the time required for the module to process the request, including data processing and internal data transmission time within the module. And clock synchronization is achieved through event passing between different modules. After receiving a signal request, the module will trigger the corresponding event to ensure that each module executes synchronously at the correct moment.

[0035] Add power consumption and area attributes to the interfaces of each module, namely the processor, peripheral modules, bus, and security module library. Include the static power consumption, dynamic power consumption, and area information of the module in the defined module structure. During the initialization process of each module, add the static power consumption and area attributes of the corresponding module, set status variables for the module to represent the active state of the module. And within the clock cycle, monitor the changes in the module status variables and update the dynamic power consumption. After the module finishes processing a transaction, create a status interface inside the module, which includes obtaining timing, power consumption, and area information. After each transaction ends, update and record the power consumption, area, and timing data of the module.

[0036] Step 6. According to the design requirements of the RISC-V secure SoC target, confirm different combinations of security modules, and adjust the settings of the security module library configuration file to determine the security modules to be enabled. Integrate the processor, security modules, and peripheral modules to build a virtual SoC platform, and complete the communication between modules through bus mapping.

[0037] According to the performance requirements of the target SoC and based on the timing, area, and power consumption models established in Step 5, select different combinations of security modules, and modify the flag bits of each security module in the configuration file of the security module library defined in Step 2 to enable or disable different security modules. Each security module has its specific functions and parameter configurations, and it is decided whether to enable or disable each security module according to specific requirements. Different configurations of these security modules will affect the security, timing, and power consumption of the system.

[0038] Create the top-level module of the system, which is responsible for the initialization of the entire system, configuring the address spaces of each module, instantiating modules, and establishing the connection relationships between modules. Through the method of bus port mapping, map the addresses of each module to the transaction-level bus; bind the target socket interfaces of each module to the initiating socket interface of the bus; start the program simulation and wait for the system to complete running.

[0039] In the top-level module of the system, call the status interfaces created by each module, traverse each module and extract its timing, power consumption, and area information. At the end of the simulation, print the status information of each module. This is for subsequent overall performance evaluation of the virtual platform.

[0040] When the RISC-V processor initiates a transaction request, the bus will forward the request to the peripheral module at the corresponding address through the socket interface. After receiving the request, the peripheral module processes it and returns the response data to the bus through the same socket interface. The bus then forwards the response data to the RISC-V processor to complete the entire transaction process.

[0041] Step 7. Calculate the area of the designed secure SoC based on the constructed SoC virtual platform. According to the area model defined in Step 5, calculate the area of the designed secure SoC by performing a weighted sum of the areas of each module in the virtual platform.

[0042] Step 8. Use the RISC-V toolchain to compile multiple standard test cases for platform simulation, and record the results of each simulation of the virtual platform and the timing and power consumption data of the SoC virtual platform during the simulation process.

[0043] Step 9. Compare the simulation results with the expected area, timing, and power consumption data, and comprehensively evaluate whether the design of the SoC virtual platform meets the performance requirements of the secure SoC design.

[0044] Step 10. If the result of the comprehensive evaluation does not meet the target design requirements, return to Step 6; otherwise, use the SoC virtual platform constructed in this round as the final design solution, that is, construct a secure SoC virtual platform that meets the design requirements.

[0045] Through the above steps, the method for verifying and evaluating the RISC-V secure SoC based on a virtual platform provided by the present invention can achieve rapid verification of the secure SoC on the virtual platform and can comprehensively evaluate its performance. Taking a processor with the RISC-V32IMAC instruction set as an example, construct the expected secure SoC virtual platform, and combine Figure 2 and Figure 3 to list a specific example of the method for verifying and evaluating the RISC-V secure SoC based on a virtual platform of the present invention.

[0046] For the RISC-V secure SoC verification and evaluation method based on a virtual platform, the following steps are included: Step 1. Establish the processor behavior model in this instance, configure the optional RISC-V instruction set, and create a processor core module.

[0047] Use an event-driven mechanism to manage the execution flow of the processor. By defining boolean flags for the optional instruction set, which includes I (integer), M (integer multiplication and division), A (atomic operation), F (single-precision floating point), C (compressed), S (secure encryption), P (predicted calculation), enable the IMAC instruction set according to the design requirements.

[0048] Define the memory interface module required for the processor to interact with external components, integrate the instruction and data memory access functions, and based on the event-triggered state transition logic, convert the instructions into corresponding transactions.

[0049] Step 2. According to the performance requirements of the system, construct a transaction bus model, define bus signals, including address, data pointer, data length, transaction command, and response signals. Define the processing function of the transaction-level bus to achieve basic bus interaction.

[0050] Construct the transaction-level model of the memory, which is implemented as a peripheral on the SoC virtual platform. Establish a target socket for the memory module to receive the transactions transmitted by the bus, respond according to the transmission requirements of the bus transactions (such as read / write, address, data length, etc.), create a register mapping table, assign addresses and corresponding register objects to each register of the memory module, and define the read / write operations of the registers and the processing process of the control signals of the data in the register access processing function.

[0051] Construct a peripheral interrupt module, which is responsible for managing and scheduling the interrupt requests of each peripheral module. Create a thread for processing priorities through the SC_THREAD method and set the priority register. After the peripheral module completes the operation, it sends an interrupt request through the transaction-level bus. After receiving the interrupt signal, the interrupt controller processes and updates the interrupt status, notifies the processor, and the processor completes the corresponding interrupt handling program. After completing the interrupt handling, the processor updates the status register of the security module.

[0052] Step 3. Construct the transaction-level model of the security module library, including constructing a security management unit and multiple security modules, designing the security algorithms required for each security module, and performing algorithm processing on the data; modify the flag bits in the configuration file to determine the enabled status of each security module.

[0053] Such as Figure 3As shown, in this example, the created security module library, where each security module inherits from the security management unit. During the data processing of the security module, the sending thread of the security management unit is called to obtain register information. According to the obtained control register information, the processing type to be executed currently (such as encryption, decryption, hash calculation, etc.) and the required relevant parameters (such as keys, data lengths, etc.) are determined, and the security algorithms of different security modules are called to process the data according to the data in the obtained input register. The internal state of the security module is updated according to the processing result, and the security management unit stores the processing result of the data and the updated state information into the control register by calling the receiving thread.

[0054] Step 4. Use a hardware description language to describe each module of the virtual platform, including the RISC-V processor, security module library, peripheral interrupt controller, and transaction-level bus. Ensure that the interface definitions and internal logics of each module described by the hardware description language are consistent with those of the modules in the virtual platform.

[0055] Call the EDA tool vivado for synthesis analysis to generate the gate-level netlist of the target hardware, and perform power consumption and area analysis on the netlist of the target hardware, calculate the static power consumption, dynamic power consumption, and the total area of the design, and generate power consumption and area reports. Then, through the timing analysis tool of EDA, by extracting the gate-level netlist of the target hardware and analyzing according to the timing constraints, identify the critical paths (the longest signal propagation paths that determine the maximum delay of the circuit) of the generated secure SoC hardware architecture, and calculate the delays of each critical path and clock path.

[0056] According to the results of the synthesis analysis and timing analysis by the EDA tool, record the power consumption, timing, and area key metrics of the generated target SoC hardware architecture.

[0057] Step 5. Define data transfer delays and data processing delays for each module (processor, memory module, peripheral interrupt module, security module library, bus) of the virtual platform according to the key performance indicator data determined in Step 4; combine the structure type and state information changes of the module to define area and power consumption models for each module library.

[0058] Define the timing constraints, power consumption, and area models for each module of the virtual platform. According to the key metric data determined in Step 4, use the clock and delay mechanisms to simulate the cycle-accurate and delay characteristics on the actual hardware. For the processor timing model, use the sc_clock class to define the clock signal, clarify the number of time cycles required for each instruction in each stage of the pipeline, and use event-driven to trigger signal and state changes; for the bus timing model, use the transaction delay mechanism to simulate the delay during data transmission; adopt a quantization time control mechanism to adjust the delay of transaction sending through the local time obtained by the get_local_time() method of tlm_quantumkeeper, and pass the time parameter through tlm::tlm_generic_payload; for the timing models of the peripheral interrupt module, memory module, and security module library, use the sc_core::sc_time method of the timestamp to mark the time from receiving the request to starting the response and the time required for the module to process the request, including data preparation, data transmission, etc.; and different modules are synchronized between simulated clocks through event passing.

[0059] Add power consumption and area attributes to each module (processor, memory module, peripheral interrupt module, security module library, bus). Include dynamic power consumption, static power consumption, and area information in the defined module structure; during module initialization, set its corresponding power consumption and area attributes. During the clock cycle, trigger the power consumption update logic by listening for changes in the module status register, create a callback function and call it when the status of the status register changes. When the status register changes, record and analyze the time points before and after the status change in real time through the callback function, and calculate the power consumption during the status change. Create a status interface inside each module, which includes obtaining timing, power consumption, and area information. After each transaction ends, update and record the power consumption, area, and timing data of the module.

[0060] Step 6. According to the performance requirements of the target SoC and based on the timing, area, and power consumption models established in Step 5, select different combinations of security modules, confirm the enabling of the AES module and the SHA-1 module in the security module library, modify the flag bits of the SHA-1 module and the AES module in the configuration file of the security module library to enable these two security modules, and disable other security modules. Integrate the processor, the SHA-1 module, the AES module, the memory module, and the peripheral interrupt module, and connect them through the bus to build a virtual SoC platform; in the top-level module, map the addresses of each module to the transaction-level bus through the bus port mapping method. The target socket interfaces of each module need to be bound to the initiating socket interface of the bus. Call the status interfaces created by each module, traverse each module (processor, memory module, peripheral interrupt module, security module library, bus), and extract their timing, power consumption, and area information. At the end of the simulation, print the status information of each module to facilitate the subsequent overall performance evaluation of the virtual SoC platform.

[0061] When the RISC-V processor initiates a transaction request, the bus will forward the request to the module at the corresponding address through the socket interface. After receiving the request, the module processes it and returns the response data to the bus through the same socket interface. The bus then forwards the response data to the RISC-V processor to complete the entire transaction process.

[0062] As Figure 2 shown, in this example, the virtual SoC platform includes a processor that selects the RISC-V32 IMAC instruction set, an interface compatible with the processor core, a transaction-level bus, a main memory, and a security module library.

[0063] The security module library includes a security management unit, an AES module, a DES module, a SHA-1 module, a PUF module, an RSA module, an SM3 module, an RC4 module, an SM2 module, an MD5 module, and a SHA-256 module.

[0064] Step 7. Calculate the area of the designed secure SoC based on the constructed virtual SoC platform.

[0065] According to the area model defined in Step 5, calculate the area of the designed secure SoC by weighted summing the areas of each module in the virtual platform.

[0066] The application program for data encryption is compiled through the RISC-V toolchain to generate an executable RISC-V ELF file. Use the ELF loader to load the segments (such as the.text segment and the.data segment) in the ELF file into the specified address space in the system's memory. Conduct simulations on the virtual platform and record the results of each system simulation and the timing and power consumption data of the virtual SoC platform during the simulation process.

[0067] During the simulation of the virtual platform, the processor sends a transaction to the security management unit of the security module library. The SHA-1 module is called and reads the data in the registers of the security module library, processes the data, generates an encryption key and stores it in the transaction, and then transmits it to the registers of the security module library through the bus. Then, the processor and the AES module work together. The AES module reads the bus transaction stored in the register, encrypts the plaintext data using the designed AES symmetric encryption algorithm, and converts it into ciphertext. After the encryption is completed, a peripheral interrupt is triggered to generate a bus transaction signal to notify the system that the encryption process is completed.

[0068] The execution process of program encryption involves a large amount of data reading, writing and arithmetic operations. Collect the timing data and power consumption data of each module during the system execution process, especially the execution latency and power consumption of the AES module and the SHA-1 module, and the impact of the processor on the execution time and power consumption under specific instruction sets.

[0069] Step 9. By comparing the expected results with the results of the simulation run in Step 8, check whether the AES module and the SHA-1 module correctly processed all transactions as expected during the encryption process; compare the simulation results with the expected area, timing and power consumption data to evaluate whether the design of the SoC virtual platform meets the performance requirements of the secure SoC design;

[0070] Step 10. If the result of the comprehensive evaluation does not meet the target design requirements, return to Step 6 to adjust the combination of security modules to be enabled in the security module library; otherwise, use the SoC virtual platform constructed in this round as the final design solution, that is, construct a secure SoC virtual platform that meets the design requirements.

[0071] The present invention provides an efficient virtual verification environment by combining RISC-V instruction set simulation and performance evaluation techniques. In this environment, not only the functional verification of the RISC-V processor, memory and security modules is realized, but also the simulation and analysis of key indicators such as timing behavior, power consumption and area can be carried out, so as to discover and correct potential problems in the early stage of design. In addition, the present invention also has high flexibility and scalability, and can adjust the parameters and configurations of security modules and instruction sets according to actual needs to adapt to different security design scenarios and performance requirements. The present invention also supports the simulation and testing of multiple peripheral interfaces to comprehensively evaluate the overall performance of the secure SoC system.

[0072] Of course, the above description is only the preferred embodiment of the present invention. The present invention is not limited to listing the above embodiments. It should be noted that all equivalent substitutions and obvious deformation forms made by any person skilled in the art under the teaching of this specification fall within the substantial scope of this specification and should be protected by the present invention.

Claims

1. A RISC-V secure SoC verification and evaluation method based on a virtual platform, characterized in that: The steps include: Step 1. According to the RISC-V secure SoC target design requirements, establish the processor behavior model, configure the optional RISC-V instruction set, and complete the instruction-to-transaction conversion logic modeling; Step 2. Establish a transaction-level model of the bus and peripheral modules, including abstracting the functional characteristics of the peripheral modules and defining the bus interface and transaction type; Step 3. Establish a transaction-level model of the security module library, including building security modules and security management units to handle bus transactions, and designing configuration files to implement dynamic switching of security modules; Step 4. Use hardware description language to perform circuit-level design for each module, i.e., processor, security module library, bus, and peripheral module, and use EDA tools to analyze the power consumption, timing, and area indicators of each module; Step 5. Define the timing, area and power consumption models for each module based on the obtained performance indicator data; Step 6. According to the RISC-V security SoC target design requirements, confirm different security module combinations, adjust the security module library configuration file settings to determine the security modules to be enabled, integrate the processor, security module and peripheral module to build a SoC virtual platform, and complete the communication between modules through bus mapping; Step 7. Calculate the area of ​​the designed secure SoC based on the constructed SoC virtual platform; Step 8. Compile the test case to perform platform simulation and record the timing and power consumption data of the virtual platform simulation; Step 9. Compare the simulation results with the expected area, timing, and power consumption data to comprehensively evaluate whether the design of the SoC virtual platform meets the performance requirements of the secure SoC design; Step 10. If the result of the comprehensive evaluation does not meet the target design requirements, return to step 6; Otherwise, the SoC virtual platform constructed in this round is used as the final design solution, that is, a secure SoC virtual platform that meets the design requirements is constructed.

2. The RISC-V security SoC verification and evaluation method based on a virtual platform according to claim 1, characterized in that: The step 1 is specifically as follows: Define the behavior mode of the processor, use the sc_module class to create the processor core module; implement the arithmetic logic unit and program counter components as independent sc_module instances; model the internal state of the processor, including the register value and the update logic of the program counter, use sc_signal to store the current state of the register, and update the PC value according to the length of the current instruction when the instruction is executed; Use event-driven mechanism to manage the execution flow of the processor. By defining sc_event and sc_process, corresponding events are triggered when the processor reads instructions from memory, changes state, or receives external signals. Each event activates the corresponding sc_process to complete the decoding and execution of instructions. The processor's instructions simulate the state transfer logic based on event triggering and convert instructions into corresponding transactions. By defining Boolean flags for optional instruction sets, different instruction sets can be dynamically enabled or disabled in the virtual platform; the enabling of different instruction sets will add new instructions, and during the execution of the processor, the decoding and execution of instructions will execute the corresponding processing logic according to the enabled instruction set; the processing logic of different instruction sets is encapsulated in independent modules; by selecting different instruction sets, the performance of the processor under different configurations can be tested, the instruction set that best suits the current design requirements can be determined, and the best hardware design can be found; Define the interface module required for the processor to interact with the transaction-level bus, and exchange data with the security module library and peripheral modules through the bus. The interface module integrates instruction and data memory access functions and is responsible for processing and forwarding the processor's memory read and write requests.

3. The RISC-V security SoC verification and evaluation method based on a virtual platform according to claim 1, characterized in that: In step 2, the process of constructing the transaction level model of the bus and peripheral modules is as follows: Establish a target socket for each peripheral module to receive bus transmission transactions, create a register mapping table for each peripheral module, assign an address and a corresponding register object to each register, and define the register read and write operations and data control signal processing in the register access processing function; Define bus signals, including address, data pointer, data length, transaction command and response signal; define the processing function of transaction-level bus to implement basic bus interaction, obtain the transaction transmission information in the processing function, find the register by address and perform read and write operations according to the command.

4. The RISC-V security SoC verification and evaluation method based on a virtual platform according to claim 1, characterized in that: In step 3, the process of constructing the transaction-level model of the security module library is as follows: Adopting modular design concept, the sc_module class is used to create security management unit and different security modules. The security management unit processes bus transactions. The processor accesses the control register and status register of the security module library through memory address mapping to obtain the status of the security module. The control data input register is responsible for receiving transactions, and the data output register saves the results of transaction processing. The synchronization between the security module and the security management unit is achieved through an event-driven synchronization mechanism. The security management unit receives processor requests through the blocking transfer callback function of the target socket. The request contains the required data type, status and control information; creates a register mapping table, assigns addresses and corresponding register objects to each register; sets the register access processing function. When there is a register access request, the function will be called to store and read register data and update register status information; calls thread functions, rxpush is responsible for receiving data and storing it in registers, txpull is responsible for reading data from registers and transmitting it to the security module, uses a semaphore mechanism to ensure data synchronization between threads, and waits for data ready notification from the rxpush thread; During the data processing of the security module, the sending thread of the security management unit is called to obtain register information. Based on the obtained control register information, the type of processing currently required to be performed and the required parameters are determined. Based on the obtained input register data, the security algorithms of different security modules are called to process the data. The internal state of the security module is updated according to the processing results. The security management unit stores the data processing results and the updated state information in the corresponding registers by calling the receiving thread.

5. The RISC-V security SoC verification and evaluation method based on a virtual platform according to claim 4, characterized in that: In step 3, the process of dynamic switching of each security module is as follows: The name, type, algorithm and required parameters of each security module are defined in the configuration file. Each security module has independent configuration items to support independent activation and configuration of the module. Enable or disable a security module by setting a flag. When the virtual platform starts the simulation, it will first parse the configuration file and initialize the corresponding security module and security algorithm according to the parameters of the configuration file. Each security module is configured with a corresponding security algorithm according to its function, and all security algorithms are encapsulated through the corresponding transaction interface.

6. The RISC-V security SoC verification and evaluation method based on a virtual platform according to claim 1, characterized in that: The step 4 is specifically as follows: Based on the processor behavior pattern defined in step 1, the security module library defined in step 2, and the transaction-level model of the bus and peripheral modules defined in step 3, the processor, security module library, bus and peripheral modules are divided into actual hardware circuit blocks and gradually converted into the target hardware structure; for the processor module, the instruction set architecture and processor execution process described in high-level language are converted into a specific hardware circuit structure; when the security module library is converted into hardware implementation, the corresponding hardware circuit structure is designed according to different security algorithms and protocols; When the transaction-level model of the bus and peripheral modules is converted into a hardware structure, the bus controller and peripheral interface circuit hardware parts are designed; specific interface and timing requirements are defined for each module, and clock signals, timing paths, synchronous logic and asynchronous logic are defined according to the performance requirements and operating frequency requirements of the verified RISC-V security SoC to ensure that the circuit meets the timing constraints. When defining the interface, the data transmission protocol and signal type between modules are clarified, and communication between modules is realized through signal lines; the hardware resources required for each module are clarified, and the connection relationship between each module and the hardware resources is defined; Call the EDA synthesis tool to perform comprehensive analysis, including logic synthesis, layout and routing, generate the gate-level netlist of the target hardware, and perform power consumption and area analysis on the gate-level netlist of the target hardware, calculate the static power consumption, dynamic power consumption and the total area of ​​the design, and generate power consumption and area reports; then call the EDA timing analysis tool to extract the gate-level netlist of the target hardware and determine the clock path of the generated secure SoC hardware architecture based on the propagation path of the clock signal in the secure SoC hardware architecture; and analyze the entire hardware architecture based on the timing constraints, identify the critical path of the generated secure SoC hardware architecture, and calculate the delay of each critical path and clock path; According to the results of comprehensive analysis and timing analysis by EDA tools, the key indicators of power consumption, timing and area of ​​the generated secure SoC hardware architecture are recorded, including the delay, power consumption distribution and area occupancy information of the critical path and clock path.

7. The RISC-V security SoC verification and evaluation method based on a virtual platform according to claim 1, characterized in that: The step 5 is specifically as follows: According to the key indicator data determined in step 4, the clock and delay mechanism are used to simulate the cycle accuracy and delay characteristics on the actual hardware; for the processor timing model, the sc_clock class is used to define the clock signal, and the time cycle required for each instruction in each stage of the pipeline is clarified. The triggering of signal and state changes is realized through the event-driven mechanism, that is, each instruction will trigger different events in turn to promote the state change of the instruction in each pipeline stage; for the bus timing model, the data transmission delay is simulated through the delay mechanism of transaction-level modeling, the sc_time class is used to control the event time interval, and the transaction sending delay is adjusted according to the local time; for the timing model of the peripheral module and the security module library, the timestamp is used to mark the time from receiving the request to starting the response and the time required for the module to process the request, including data processing and data transmission time within the module; and clock synchronization is achieved between different modules through event transmission. After receiving the signal request, the module will trigger the corresponding event to ensure that each module is executed synchronously at the correct time; Add power consumption and area attributes to the interface of each module; include the module's static power consumption, dynamic power consumption and area information in the defined module structure; during the initialization process of each module, add the corresponding module's static power consumption and area attributes, set the module's state variables to indicate the module's activity status; and monitor changes in the module's state variables and update dynamic power consumption during the clock cycle; when the module completes the transaction, create a state interface inside the module, which includes timing, power consumption and area information. After each transaction, update and record the module's power consumption, area and timing data.

8. The RISC-V security SoC verification and evaluation method based on a virtual platform according to claim 1, characterized in that: In step 6, different security module combinations are confirmed according to the design requirements, and the security module library configuration file settings are adjusted to determine the security module to be enabled. The processor, security module and peripheral module are connected through a transaction-level bus, and the process of building a SoC virtual platform is as follows: According to the performance requirements of the target SoC and the timing, area and power consumption models established in step 5, select different security module combinations, and then modify the flag bits of each security module in the security module library configuration file defined in step 2 to enable or disable different security modules; each security module has its corresponding functions and parameter configurations, and the configuration file is used to control whether the security module is enabled or not; Create the top-level module of the system, which is responsible for the initialization of the entire system, configuring the address space of each module, module instantiation, and establishing the connection relationship between modules; By means of bus port mapping, the addresses of each module are mapped to the transaction-level bus; the target socket interface of each module is bound to the initiating socket interface of the bus; the program simulation is started and the system operation is waited for completion; In the top-level module of the system, the status interface created by each module is called to traverse each module and extract its timing, power consumption and area information. At the end of the simulation, the status information of each module is printed to facilitate the overall performance evaluation of the SoC virtual platform. When the RISC-V processor initiates a transaction request, the bus forwards the request to the peripheral module of the corresponding address through the socket interface. After receiving the request, the peripheral module processes it and returns the response data to the bus through the same socket interface. The bus then forwards the response data to the RISC-V processor to complete the entire transaction process.

9. The RISC-V secure SoC verification and evaluation method based on a virtual platform according to claim 1, characterized in that: The step 7 specifically includes: according to the area model defined in step 5, the area of ​​the designed secure SoC is calculated by weighted summing the areas of the modules of the constructed SoC virtual platform.

10. The RISC-V security SoC verification and evaluation method based on a virtual platform according to claim 1, characterized in that: In step 9, the comprehensive evaluation includes timing, power consumption, and area performance evaluation; Timing evaluation: Analyze the timing data obtained from the simulation operation, compare it with the processing delay and transmission delay in the expected performance indicators, and evaluate whether the timing performance of the virtual platform meets the design requirements; Power consumption evaluation: compare the power consumption data of the simulated operation with the expected power consumption index to determine whether the energy consumption of the virtual platform is within an acceptable range; Area evaluation, based on the total area of ​​the virtual platform obtained from the simulation run, is compared with the expected SoC area to evaluate whether the area occupancy meets the design goals.

Images