Method and system for transmitting parameters between simulator and to-be-tested design module, and electronic equipment

Abstract

The embodiment of the invention discloses a parameter transmission method and system between a simulator and a to-be-tested design module and electronic equipment, relates to the technical field of chip design verification, and can improve the success rate of parameter transmission and the stability of a simulation process. The method comprises the following steps: after a simulator and a to-be-tested design module are started, establishing communication connection between the simulator and the to-be-tested design module; automatically acquiring a command parameter to be transmitted from a pre-configured command parameter exclusive path; wherein the command parameter exclusive path is configured to be a communication path specially used for storing command parameters to be transmitted; and transmitting the command parameter to be transmitted to a design module to be tested.

Description

TECHNICAL FIELD

[0001] The present application relates to the chip design verification technical field, and particularly to a parameter transfer method and system between a simulator and a design under test module and an electronic device. BACKGROUND

[0002] In the field of chip design and verification, a simulator QEMU (Quick Emulator) is often used for system simulation tasks to verify the functions and performance of a design under test (DUT). In the simulation process, QEMU needs to establish stable communication with the DUT to implement device initialization, command reading and writing, and parameter transfer, etc. Among them, the socket mechanism is a common way of communication between the two, which undertakes the basic channel of key information interaction. At the same time, in order to optimize the simulation efficiency, a shared memory space is often used as a shared address between QEMU and DUT to further improve the data interaction speed.

[0003] In the prior art, there are mainly two ways of parameter transfer between QEMU and DUT: one is to transfer parameters before the socket communication connection between the two is established, but this way is affected by the instability of the execution time of DUT and QEMU, and is prone to parameter transfer failure due to unstable connection relationship; the other is to register DUT configuration parameter information directly in QEMU during the compilation of QEMU, that is, during the compilation of QEMU, the parameters to be transferred are modified in QEMU. This way is difficult to modify parameters, and when the state of DUT changes, QEMU needs to be recompiled, which will affect the stability of the simulation process. SUMMARY

[0004] Therefore, the embodiments of the present application provide a parameter transfer method and system between a simulator and a design under test module and an electronic device, which can improve the success rate of parameter transfer and the stability of the simulation process.

[0005] In a first aspect, the embodiments of the present application provide a parameter transfer method between a simulator and a design under test module, comprising: after starting the simulator and the design under test module, establishing a communication connection between the simulator and the design under test module; automatically obtaining command parameters to be transferred from a pre-configured command parameter exclusive path; wherein the command parameter exclusive path is configured as a communication path specially used for storing the command parameters to be transferred; and transmitting the command parameters to be transferred to the design under test module.

[0006] According to a specific implementation manner of the embodiment of the present application, after the command parameter to be transmitted is obtained from the preconfigured command parameter exclusive path, the method further comprises: judging whether the command parameter to be transmitted is successfully obtained from the preconfigured command parameter exclusive path; if the obtaining fails, automatically switching to a standard input and output mode to receive the uploaded command parameter to be transmitted.

[0007] According to a specific implementation manner of the embodiment of the present application, the command parameter to be transmitted comprises: a number of configuration registers of a design-under-test module, a size of each configuration register, a vendor identifier and a device identifier; the command parameter to be transmitted is packed in a string form to form a parameter package and stored to the preconfigured command parameter exclusive path.

[0008] According to a specific implementation manner of the embodiment of the present application, before the simulator and the design-under-test module are started, the method further comprises: storing a start configuration parameter of the simulator and a start configuration parameter of the design-under-test module as independent text files respectively; in the process of starting the simulator, the text files are loaded in a specified order, so that the start configuration parameter of the simulator and the start configuration parameter of the design-under-test module are separated in loading timing from the command parameter to be transmitted.

[0009] According to a specific implementation manner of the embodiment of the present application, the loading of the text files in the specified order comprises: if the text file corresponding to the start configuration parameter of the design-under-test module is loaded with an error or a device communication path has an error, only the text file corresponding to the start configuration parameter of the simulator is loaded.

[0010] According to a specific implementation manner of the embodiment of the present application, in the process of obtaining the command parameter to be transmitted from the preconfigured command parameter exclusive path, the method further comprises: listening to a resource usage state of the simulator and a running state of the design-under-test module; and adjusting the start configuration parameter of the simulator or the design-under-test module according to the listening result.

[0011] According to a specific implementation manner of the embodiment of the present application, the command parameter exclusive path is a command socket path configured based on a Socket mechanism.

[0012] In a second aspect, the embodiment of the present application further provides a parameter transmission system between a simulator and a design-under-test module, comprising: a communication connection establishment unit, configured to establish a communication connection between the simulator and the design-under-test module after the simulator and the design-under-test module are started; a command parameter obtaining unit, configured to automatically obtain a command parameter to be transmitted from a preconfigured command parameter exclusive path; wherein the command parameter exclusive path is configured as a communication path specially used for storing the command parameter to be transmitted; and a parameter transmission unit, configured to transmit the command parameter to be transmitted to the design-under-test module.

[0013] According to a specific implementation manner of the embodiment of the present application, the system further comprises an acquisition judging unit, configured to judge whether the to-be-transferred command parameter is acquired successfully after the command parameter acquisition unit acquires the to-be-transferred command parameter from the pre-configured command parameter exclusive path; a mode switching unit, configured to automatically switch to a standard input and output mode to receive the uploaded to-be-transferred command parameter when the acquisition judging unit judges that the acquisition fails.

[0014] According to a specific implementation manner of the embodiment of the present application, the system further comprises a parameter packaging and storing unit, configured to: package the to-be-transferred command parameter to form a parameter package, the to-be-transferred command parameter comprising the number of configuration registers of the to-be-tested design module, the size of each configuration register, the manufacturer identifier and the device identifier; and store the parameter package in the form of a string to the pre-configured command parameter exclusive path.

[0015] According to a specific implementation manner of the embodiment of the present application, the system further comprises a configuration file storing unit, configured to store the start configuration parameters of the simulator and the start configuration parameters of the to-be-tested design module as independent text files before the simulator and the to-be-tested design module are started; and a configuration file loading unit, configured to load the text files in a specified order during the process of starting the simulator, so that the start configuration parameters of the simulator and the start configuration parameters of the to-be-tested design module are separated in loading sequence from the to-be-transferred command parameter.

[0016] According to a specific implementation manner of the embodiment of the present application, the configuration file loading unit is further configured to: if the text file corresponding to the start configuration parameters of the to-be-tested design module is loaded with errors or the device communication path has errors, only load the text file corresponding to the start configuration parameters of the simulator.

[0017] According to a specific implementation manner of the embodiment of the present application, the system further comprises a state monitoring unit, configured to monitor the resource usage state of the simulator and the running state of the to-be-tested design module during the process in which the command parameter acquisition unit acquires the to-be-transferred command parameter from the pre-configured command parameter exclusive path; and a parameter adjusting unit, configured to adjust the start configuration parameters of the simulator or the to-be-tested design module according to the monitoring result of the state monitoring unit.

[0018] According to a specific implementation manner of the embodiment of the present application, the command parameter exclusive path is a command socket path configured based on a Socket mechanism.

[0019] In a third aspect, an electronic device is provided, and the electronic device comprises a housing, a processor, a memory, a circuit board and a power supply circuit, wherein the circuit board is arranged inside a space enclosed by the housing, the processor and the memory are arranged on the circuit board; the power supply circuit is configured to supply power to each circuit or device of the electronic device; the memory is configured to store executable program codes; and the processor is configured to run a program corresponding to the executable program codes by reading the executable program codes stored in the memory, and execute the parameter transfer method between the simulator and the design under test module according to any one of the first aspect.

[0020] The parameter transfer method, system and electronic device provided by the embodiments of the present application can improve the success rate of parameter transfer and the stability of the simulation process by pre-configuring a command parameter exclusive path, which is specially used to store the command parameters to be transferred, and automatically reading the parameters in the command parameter exclusive path once the parameters are detected after the stable communication connection between the simulator and the design under test module is established, without manual triggering, so as to ensure that the parameter transfer timing matches the running state of the simulator. BRIEF DESCRIPTION OF DRAWINGS

[0021] In order to more clearly illustrate the technical solutions of the embodiments of the present application or part of the prior art, the drawings needed in the embodiments or prior art description will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present application, and those skilled in the art can also obtain other drawings according to these drawings without creative labor.

[0022] Figure 1 The flowchart of the parameter transfer method between the simulator and the design under test module provided by an embodiment of the present application is shown in the figure. Figure 2 The schematic block diagram of the parameter transfer system architecture between the simulator and the design under test module provided by an embodiment of the present application is shown in the figure. Figure 3 The flowchart of the simulator parameter configuration provided by an embodiment of the present application is shown in the figure. Figure 4 The complete flowchart of the QEMU and the DUT establishing a communication connection and maintaining the stability of the simulation provided by an embodiment of the present application is shown in the figure. Figure 5 The simulation flowchart of the parameter transfer method between the simulator and the design under test module provided by an embodiment of the present application is shown in the figure. Figure 6 The schematic block diagram of the parameter transfer system architecture between the simulator and the design under test module provided by an embodiment of the present application is shown in the figure. Figure 7An electronic device structure schematic block diagram provided by an embodiment of the present application is shown. DETAILED DESCRIPTION

[0023] The embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0024] It should be clear that the described embodiments are only some of the embodiments of the present application, not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative labor are within the scope of protection of the present application.

[0025] In order for those skilled in the art to better understand the technical concepts, implementation schemes and beneficial effects of the embodiments of the present application, specific embodiments are described in detail below.

[0026] In the field of chip design and verification, a generic emulator is widely used as an efficient simulation tool for systematic verification of the function and performance of a design under test (DUT). In a typical simulation process, QEMU (a specific emulator) and the DUT establish communication through a specific communication mechanism to implement core operations such as device initialization, command interaction and parameter transfer.

[0027] However, how QEMU accurately and stably obtains key parameter information of the DUT, such as register configuration information, is a core problem that needs to be solved in the simulation process. In related technologies, parameter transfer mainly relies on two ways.

[0028] One is to transfer parameters before the socket communication connection between the two is established, but this way is affected by the instability of the execution time of the DUT and QEMU, and is prone to parameter transfer failure due to unstable connection relationship; for example, QEMU may have completed initialization and is waiting for parameters, while the DUT has not yet prepared to send parameters due to internal logic processing delay, or the DUT sends parameters while QEMU is in a resource occupation peak and cannot receive, which is a time asynchronization that will cause the connection relationship between the two to be unstable, directly leading to parameter transfer failure.

[0029] The other is to register the DUT configuration parameter information directly in QEMU during the compilation of QEMU, that is, during the compilation of QEMU, the parameters to be transferred are modified in QEMU, which makes parameter modification difficult, and when the DUT state changes, QEMU needs to be recompiled, which will affect the stability and simulation efficiency of the simulation process.

[0030] Therefore, the two methods above can realize parameter transmission to a certain extent, but still have some problems. On the one hand, the thread execution time uncertainty of QEMU and DUT cannot guarantee the rationality of parameter transmission, and when the application task execution is wrong, the task cannot be sent to the DUT side, thereby increasing the debugging time. On the other hand, the parameter transmission is mixed with the start parameters and device interaction commands, and lacks a clear separation mechanism, thereby causing difficulty in system maintenance and upgrading.

[0031] With reference to Figure 1 and Figure 2 , the embodiment of the present application provides a parameter transmission method between a simulator and a design module to be tested, comprising: S110, after starting the simulator and the design module to be tested, establishing a communication connection between the simulator and the design module to be tested; S120, automatically obtaining command parameters to be transmitted from a pre-configured command parameter exclusive path; wherein the command parameter exclusive path is configured as a communication path specially used for storing the command parameters to be transmitted; S130, transmitting the command parameters to be transmitted to the design module to be tested.

[0032] Wherein, the running and data transmission of the QEMU simulator and the DUT depend on the host memory (Host Memory), after starting the simulator QEMU and the design module to be tested, a communication connection can be established through the socket mechanism based on the TCP / IP standard, and after the initialization of both sides is completed and it is confirmed that it is stable, the subsequent parameter transmission is automatically performed.

[0033] It can be understood that the parameter transmission often shares the communication channel with the communication tasks such as device interaction and / or memory data reading and writing, so that the execution time uncertainty is easily affected by the intensified resource competition. With reference to Figure 2 In the embodiment of the present application, the command parameter exclusive path specially used for storing the communication path of the command parameters to be transmitted is pre-configured, after the QEMU is successfully started, the internal process listens to the command parameter exclusive path, after the stable communication connection between the QEMU and the DUT is established, once the parameter package exists in the command parameter exclusive path is detected, it is automatically read without manual triggering, the parameter transmission opportunity is matched with the running state of the QEMU, thereby the success rate of the parameter transmission and the stability of the simulation process can be improved.

[0034] In some embodiments, the command parameter exclusive path is a command socket path configured based on the socket mechanism. Figure 2The command parameter dedicated path, i.e., a command socket path, is specifically indicated, which separates the parameter transmission path from the device communication path and the memory communication path. Since the parameter transmission path is independent of the device communication path and the memory communication path, resource conflicts are reduced. At the same time, since the command parameter dedicated path is configured, the command parameters to be transmitted can be automatically obtained after the communication connection is established between the simulator and the design-under-test module without manual intervention, which avoids transmission failure caused by manual operation or timing misalignment. Thus, the parameter transmission stability problem caused by unstable execution time in the prior art is solved, and the command parameters can be reliably transmitted to the DUT after the communication connection is stable, thereby improving the stability and simulation efficiency of the simulation process.

[0035] In addition, when parameter transmission errors occur in the QEMU environment or inside the DUT, parameter transmission errors are prone to occur due to the lack of effective detection tools in the QEMU environment or inside the DUT. After the parameter transmission fails, the simulation task is often directly terminated, which increases the debugging time and reduces the simulation efficiency.

[0036] Specifically, after obtaining the command parameters to be transmitted from the pre-configured command parameter dedicated path, the method further includes: determining whether the command parameters to be transmitted are successfully obtained from the pre-configured command parameter dedicated path; and if the obtaining fails, automatically switching to a standard input / output mode (STDIO mode) to receive the uploaded command parameters to be transmitted.

[0037] Exemplarily, when the host (a physical host running the QEMU simulator and the design-under-test module) network fluctuates to cause the command parameter dedicated path to be temporarily unavailable, the QEMU automatically switches to the STDIO mode and prompts the user to manually input the parameters through internal listening logic after determining that the obtaining fails. In this embodiment, the fault-tolerant capability is provided through the dual-parameter transmission mechanism, so that the parameter transmission can still be completed through the standby mode when the automatic obtaining through the command parameter dedicated path abnormally fails, which reduces the simulation interruption caused by single failure and is beneficial to improve the simulation stability.

[0038] In the parameter passing process, if the parameters are independently passed, logical confusion may easily occur, such as mismatching of parameter front and back relationship, and the problem that modification needs to recompile QEMU. In some embodiments, the command parameters to be passed include the number of configuration registers of the design-under-test module, the size of each configuration register, the vendor identification, and the device identification; the command parameters to be passed are packaged in the form of a string to form a parameter package, and are stored to the pre-configured command parameter exclusive path, so as to automatically obtain the command parameters to be passed from the command parameter exclusive path after the communication connection between the simulator and the design-under-test module is stable.

[0039] For example, the command parameters to be passed include DUT basic information, which can be packaged in the form of a string, and written to the command parameter exclusive path through an NC (net cat, a parameter passing command) command. By integrating the DUT basic information into a whole, logical errors caused by discrete passing are avoided; at the same time, when the configuration of the DUT needs to be modified, only the corresponding field in the string needs to be adjusted, without the need to modify the QEMU source code, so as to adapt to the demand for dynamic adjustment of parameters in the simulation process.

[0040] In some related technologies, the startup configuration parameters of QEMU and the DUT and the command parameters passed at runtime are generally mixed for storage or processing. For example, some schemes contain both the initialization parameters at startup and the dynamic configuration parameters at runtime in the startup script, or the two types of parameters are integrated into the simulator source code through a hard-coded way in the compilation phase, so that the startup parameters and the runtime parameters are interwoven in the storage and loading logic. When the parameters need to be modified, whether it is the initialization configuration in the startup phase or the dynamic adjustment at runtime, it needs to be operated in the same script or source code, which easily leads to confusion in parameter management and is not easy to modify.

[0041] Therefore, in some embodiments of the present application, before the simulator and the design-under-test module are started, the method further includes: storing the startup configuration parameters of the simulator and the startup configuration parameters of the design-under-test module as independent text files; and in the process of starting the simulator, loading the text files in a specified order, so that the startup configuration parameters of the simulator and the startup configuration parameters of the design-under-test module are separated from the command parameters to be passed in the loading timing.

[0042] Reference Figure 3In particular, the start configuration parameters of the simulator, such as memory allocation size, core number setting, etc., are stored in the start configuration file of QEMU, and the start configuration parameters of the design under test module, such as initial baud rate, hardware interface type, etc., are stored in the start configuration file of the DUT. Since the parameters are stored in separate files, there is no need to process complex logic of mixed parameters when parsing, and parsing errors caused by too many parameters in a single file and mixed formats are avoided. When loading, the order of the simulator configuration and the design under test module configuration is executed in sequence, so that the start parameters and the runtime command parameters are completely separated in time sequence, and the start parameters are fixed after being loaded, and the modification of the runtime command parameters does not affect the start configuration parameters. Therefore, when the parameters need to be adjusted, only the corresponding text file needs to be modified, reducing the maintenance complexity.

[0043] When the start configuration parameters of the design under test module have a loading error or a device communication path error, the entire simulation start process is usually interrupted, and it is difficult to distinguish whether the error is caused by the simulator itself or the design under test module. In some embodiments, the loading of the text files in the specified order comprises: if the text file corresponding to the start configuration parameters of the design under test module has a loading error or a device communication path error, only the text file corresponding to the start configuration parameters of the simulator is loaded.

[0044] For example, if the device socket path for device interaction cannot be created due to insufficient file operation permissions, the design under test module configuration file will be automatically skipped, and only the start configuration file of QEMU is loaded and the simulator is started. At this time, if the simulator can be started normally, it indicates that the simulator configuration is correct, and the fault can be locked in the configuration file of the design under test module or the device communication path. If the simulator fails to start, it can be determined that the problem is in the start parameters of the simulator. In this way, by isolating the loading results to distinguish the fault source, the problem of difficult fault range locking caused by stopping everything once an error occurs can be avoided, and the fault source can be easily located.

[0045] For resource configuration in the simulation process, the resource parameters of the simulator and the design under test module are mostly static configurations, that is, they are set at the start and generally do not need to be adjusted. However, during the simulation process, the actual load may change, and the previous configuration needs to be adjusted accordingly. However, this static configuration method is difficult to adapt to the dynamic change of resource demand in the simulation process.

[0046] To optimize resource allocation to adapt to dynamic simulation requirements, as shown in Figure 5 In some embodiments, in the process of obtaining the command parameters to be transmitted from the pre-configured command parameter exclusive path, the method further comprises: listening to the resource usage state of the simulator and the running state of the design under test module; and adjusting the start configuration parameters of the simulator or the design under test module according to the listening result.

[0047] Specifically, real-time monitoring can be achieved through a monitoring mode, continuously collecting information such as the simulator's CPU utilization, memory usage, and the register read / write frequency of the design under test (DUT). When the simulator's CPU utilization is consistently too high, its startup configuration parameters are adjusted, such as increasing the number of cores to reduce the load on individual cores. If the DUT experiences delays due to frequent memory accesses, the caching parameters in its configuration file are modified. In this embodiment, because resource configuration can be dynamically adjusted according to real-time status, the problems of resource waste due to excess resources or lag due to insufficient resources under static configuration are avoided, thereby improving the overall efficiency of the simulation process.

[0048] Therefore, as an optional embodiment, adjusting the configuration parameters of the simulator or the design under test (DUT) module based on the monitoring results includes: increasing the CPU resource allocation if the CPU utilization rate of the simulator exceeds a threshold; adjusting the memory size if the memory capacity of the simulator does not match the requirements; and optimizing the internal design logic of the DUT module to adapt to Single Instruction Multiple Data (SIMD) or adding a multi-threading mechanism if the memory access frequency of the DUT module is too high. Optimizing the internal design logic of the DUT module includes reasonably adding compiler optimization instructions to maximize the overall simulation performance.

[0049] To aid in understanding the technical solution and effects of one embodiment of this application, the following is combined with... Figures 2 to 5 The following is a detailed explanation: In chip design simulation scenarios, the efficiency and stability of parameter transfer between the QEMU simulator and the DUT directly affect the reliability of the simulation results. The following is a detailed explanation of the process from setting up startup configuration parameters to running the simulation.

[0050] See Figure 3 As shown, before QEMU and DUT start, the system processes their startup configuration parameters. Specifically, after starting the QEMU configuration process, the system first loads QEMU's own configuration file, and then determines whether to enable DUT configuration. QEMU startup parameters, such as memory allocation and core count settings, are stored in a separate QEMU configuration file, while DUT startup parameters are stored in the DUT configuration file. This separate storage avoids parsing conflicts caused by mixed parameters. See below for further details. Figure 3If the DUT configuration file is not enabled to be loaded, the whole process only needs to load the selected file system and monitor configuration method, which is only the necessary step of QEMU startup; otherwise (i.e. the DUT configuration file is enabled), the behavior of the memory communication path, the behavior of the device communication path and the behavior of the command parameter exclusive path need to be monitored as a whole, and the final purpose is to load the DUT configuration file and the monitoring behavior directly into the whole simulation, and the behavior of the command parameter exclusive path is only loaded after the DUT runs.

[0051] After the configuration is completed, the system activates three parallel channels at this time, the device socket path for device interaction, the memory socket path for memory sharing, and the command socket path for command parameter transmission, i.e. the command parameter exclusive path. Figure 4 For the complete flowchart of establishing a communication connection between QEMU and DUT and maintaining the stability of the simulation, see Figure 2 and Figure 4 , After executing the start communication connection command, the DUT startup process is triggered. Before formal interaction, the runtime parameters including the command parameters to be transmitted are pre-transmitted to the specified command socket path through external instructions such as NC commands, for realizing automatic transmission of command parameters.

[0052] After the DUT starts, quantum time assertion verification is performed. Quantum time is a core parameter of DUT running, for example, time step configuration of hardware logic; if it is detected that the configuration exceeds the support range of hardware logic, such as time step configuration being too small to cause timing conflict, i.e. quantum time assertion error is detected, the system will actively exit the current connection process, correct the quantum time parameter through external instructions, and specifically, a reasonable time step can be reset, and after adjustment, the process returns to the start communication connection link to perform the restart process. Through cyclic verification and adjustment, the legality of the core running parameter of DUT can be ensured, and simulation failure caused by basic configuration error can be avoided.

[0053] If the quantum time verification passes, i.e. the quantum time assertion is correct, the process enters the memory socket path connection stage, verifies the communication channel of DUT and memory, i.e. judges whether the memory assertion is incorrect, which can specifically include: checking the memory mapping position, space size and socket internal mechanism to ensure that DUT can normally read and write memory resources.

[0054] If the connection fails due to some of the above reasons, i.e. the memory assertion is incorrect, the DUT under test module connection will be exited, and the DUT will be triggered for checking, mainly to check whether there are problems in DUT memory space allocation, access permission, etc.

[0055] If the connection is successful, the DUT internal assertion check is continued to verify whether the DUT hardware logic, such as register read-write timing, hardware interface state and the like, has design defects. If the DUT internal assertion error is detected, the exit of the design under test module is triggered, and the DUT is checked to quickly locate the DUT hardware exception by isolating the abnormal point.

[0056] If the DUT internal assertion check has no error, that is, the DUT hardware check is passed, the emulator QEMU loading process is started. When QEMU is started, the self-assertion error is detected, including memory allocation out of limit and CPU core number configuration conflict. If there is an error, the DUT thread is directly ended to avoid invalid thread occupying system resources; and the QEMU is ended to trigger the QEMU check, which can quickly locate whether the QEMU startup parameter and environment dependency has configuration problem by forcibly cleaning up residual resources.

[0057] If the QEMU is started normally, the self-configuration file and the DUT configuration file will be loaded in turn to complete the basic environment initialization. Subsequently, the QEMU will establish a communication connection with the DUT device command socket to verify whether the DUT configuration space supports parameter writing, that is, the QEMU socket assertion is verified again. If it is correct, that is, the DUT internal configuration space can receive the QEMU parameter configuration, the connection between QEMU and DUT is normal.

[0058] If the QEMU socket assertion is verified again, that is, the connection fails, the DUT and QEMU threads will be ended (Kill) to trigger the DUT check and the QEMU check respectively to locate the reason for the socket connection failure.

[0059] After the communication channel is established and the connection between QEMU and DUT is normal, the device command socket connection stage is entered. QEMU automatically acquires the runtime parameters to be transmitted from the command socket path. If the parameter acquisition fails due to some reasons, the system will implicitly switch to the standard input-output mode to allow manual input of parameters.

[0060] After the parameter transmission is completed, the device command socket assertion check is performed. If the parameter format error, integrity exception and the like are detected, the process will trigger the monitoring switch to record the error log, collect the running state of QEMU and DUT, assist in locating hidden problems, and then end the connection to release all socket resources and thread resources.

[0061] Referring to Figure 5After the communication connection between QEMU and the DUT is established and the parameters are automatically transmitted to QEMU through the command socket path, QEMU performs simulation testing and verification on the performance or running behavior of the DUT through an application, and an embodiment of the simulation testing and verification process is as follows: the test instruction is sent to QEMU through the upper application, the test instruction can be set according to the performance evaluation index of the DUT, so as to trigger the cooperative simulation of QEMU and the DUT.

[0062] During the testing process, if the node information of the DUT needs to be debugged, it can be realized in two ways: one is that the hardware logic behavior of the DUT in the running process triggers the value change dump (VCD) function, the running state of the DUT is captured and converted into a VCD format record file, the VCD format file is used to record the change track of the key signal in the running process of the DUT, so as to trace the execution details of the hardware logic; the other is to mount the DUT process by means of the GDB debugger, to real-time view the register value, memory data and the like, and to quickly locate the parameter configuration error or logic defect in the software layer. Through these debugging means, the bottom running information of the DUT and the test demand of the application program can be combined, so as to judge whether the whole software and hardware architecture matches the design expectation.

[0063] In order to ensure the controllability and optimization space of the simulation process, the monitor mode of QEMU is reserved. This mode can real-time monitor two types of key states: one is the behavior performance of the DUT, such as the register read-write frequency, the access times of the BAR space, the response delay of the hardware interface and the like; the other is the configuration parameters of QEMU, such as the CPU core number, the memory allocation size, the cache strategy and the like. Based on these monitoring data, the simulation scheme can be adjusted in a targeted manner, specifically, if the memory access efficiency of the DUT is found to be too low, the internal design of the DUT can be modified, such as optimizing the cache structure or adding a multi-thread mechanism; if the CPU resource occupation of QEMU is too high, the load can be balanced by adjusting its configuration file, so that the simulation is more efficient and tends to the expected result.

[0064] In the embodiment, for the dynamic adjustment of the DUT behavior mode, it is not necessary to recompile QEMU or restart the simulation process, but only to transmit new parameters through the command socket path, so that the DUT can quickly adapt to the change of the test scene, which not only avoids the process interruption in the traditional static configuration, but also ensures the stability of the whole simulation platform when facing different test demands, and at the same time, maximizes the portability, that is, when the hardware design or test target of the DUT changes, only the command parameters to be transmitted need to be updated through the command socket path, so that the simulation environment can be quickly adapted.

[0065] It should be noted that the parameter transmission method between the simulator and the design-under-test module provided by each of the above embodiments can be solidified in a manufactured entity hardware device in the form of software or a program, and when the software or program is run, the above method process can be reproduced.

[0066] Referring to Figure 6 The embodiment of the application further provides a parameter transmission system between a simulator and a design-under-test module, comprising: A communication connection establishment unit 210 is configured to establish a communication connection between the simulator and the design-under-test module after the simulator and the design-under-test module are started; A command parameter acquisition unit 220 is configured to automatically acquire the command parameters to be transmitted from a pre-configured command parameter exclusive path; wherein the command parameter exclusive path is configured as a communication path specially used for storing the command parameters to be transmitted; A parameter transmission unit 230 is configured to transmit the command parameters to be transmitted to the design-under-test module.

[0067] In some embodiments, the command parameter exclusive path is a command socket path configured based on a Socket mechanism.

[0068] In some embodiments, the system further comprises an acquisition judgment unit configured to judge whether the command parameters to be transmitted are successfully acquired after the command parameter acquisition unit acquires the command parameters to be transmitted from the pre-configured command parameter exclusive path; A mode switching unit is configured to automatically switch to a standard input and output mode to receive the uploaded command parameters to be transmitted when the acquisition judgment unit determines that the acquisition fails.

[0069] In some embodiments, the system further comprises a parameter packaging and storage unit configured to: pack the command parameters to be transmitted in the form of a string to form a parameter package; the command parameters to be transmitted comprise the number of configuration registers of the design-under-test module, the size of each configuration register, the manufacturer identification and the device identification; and store the parameter package to the pre-configured command parameter exclusive path.

[0070] In some embodiments, the system further comprises a configuration file storage unit configured to store the startup configuration parameters of the simulator and the startup configuration parameters of the design-under-test module as independent text files before the simulator and the design-under-test module are started; A configuration file loading unit is configured to load the text files in a specified order during the process of starting the simulator, so that the startup configuration parameters of the simulator and the startup configuration parameters of the design-under-test module are separated from the command parameters to be transmitted in the loading sequence.

[0071] In some embodiments, the configuration file loading unit is further configured to: if the text file corresponding to the startup configuration parameters of the design module under test is loaded incorrectly or the device communication path is incorrect, then only the text file corresponding to the startup configuration parameters of the simulator is loaded.

[0072] In some embodiments, the system further includes: a status monitoring unit, used to monitor the resource usage status of the simulator and the running status of the design module under test during the process of the command parameter acquisition unit acquiring the command parameters to be transmitted from a pre-configured command parameter dedicated path; The parameter adjustment unit is used to adjust the startup configuration parameters of the simulator or the design under test module based on the monitoring results of the status monitoring unit.

[0073] It should be noted that the parameter transfer system between the simulator and the design module under test provided in the various embodiments of this application has the same technical concept and specific technical features as the aforementioned method embodiments. Their implementation principles and technical effects can be referred to each other, so they will not be described again.

[0074] This application also provides an electronic device, such as... Figure 7 As shown, the electronic device provided in the embodiments of the present invention may include: a housing 51, a processor 52, a memory 53, a circuit board 54, and a power supply circuit 55, wherein the circuit board 54 is disposed inside the space enclosed by the housing 51, and the processor 52 and the memory 53 are disposed on the circuit board 54; the power supply circuit 55 is used to supply power to various circuits or devices of the above-mentioned electronic device; the memory 53 is used to store executable program code; the processor 52 runs a program corresponding to the executable program code by reading the executable program code stored in the memory 53, for executing the parameter transfer method between the simulator and the design under test module provided in any of the foregoing embodiments.

[0075] For details on the specific execution process of the above steps by the processor 52 and the steps further executed by the processor 52 by running executable program code, please refer to the description of the foregoing embodiments, which will not be repeated here.

[0076] It should be noted that, in the present document, the schemes described between the various embodiments have different focuses, but the various embodiments have certain mutual relations, and the various embodiments can be mutually referred to when understanding the schemes of the present application. In addition, relationship terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between the entities or operations. Moreover, the terms "include", "contain" or any other variants thereof are intended to cover non-exclusive inclusion, so that the process, method, article or measurement control unit including a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such process, method, article or measurement control unit. Without more limitations, the element defined by the statement "including a" does not exclude the presence of other identical elements in the process, method, article or measurement control unit including the element.

[0077] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any skilled person in the art can easily think of changes or replacements within the technical scope disclosed by the present application, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A method for parameter transfer between a simulator and a design-under-test module, characterized in that, The method comprises the steps of: After starting the simulator and the design-under-test module, a communication connection between the simulator and the design-under-test module is established; The command parameters to be transmitted are automatically obtained from a pre-configured command parameter exclusive path, wherein the command parameter exclusive path is configured as a communication path specially used for storing the command parameters to be transmitted; The command parameters to be transmitted are transmitted to the design-under-test module.

2. The method of claim 1, wherein, After obtaining the command parameters to be transmitted from the pre-configured command parameter exclusive path, the method further comprises the step of judging whether the command parameters to be transmitted are successfully obtained from the pre-configured command parameter exclusive path; If the obtaining fails, the standard input and output mode is automatically switched to receive the uploaded command parameters to be transmitted.

3. The method of claim 1, wherein, The command parameters to be transmitted comprise the number of configuration registers of the design-under-test module, the size of each configuration register, the manufacturer identification and the device identification. The command parameters to be transmitted are packaged in the form of a string to form a parameter package, and are stored in the pre-configured command parameter exclusive path.

4. The method of claim 1, wherein, Before starting the simulator and the design-under-test module, the starting configuration parameters of the simulator and the starting configuration parameters of the design-under-test module are respectively stored as independent text files; During the starting of the simulator, the text files are loaded in a specified order, so that the starting configuration parameters of the simulator and the starting configuration parameters of the design-under-test module are separated from the command parameters to be transmitted in the loading sequence.

5. The method of claim 4, wherein, The loading of the text files in the specified order comprises the step of loading only the text file corresponding to the starting configuration parameters of the simulator if the text file corresponding to the starting configuration parameters of the design-under-test module is loaded incorrectly or an error occurs in the device communication path.

6. The method of claim 1, wherein, During the obtaining of the command parameters to be transmitted from the pre-configured command parameter exclusive path, the method further comprises the steps of: The resource usage state of the simulator and the running state of the design-under-test module are listened to; The starting configuration parameters of the simulator or the design-under-test module are adjusted according to the listening result.

7. The method of claim 1, wherein, The command parameter exclusive path is a command socket path configured based on a Socket mechanism.

8. A system for transferring parameters between a simulator and a design under test module, comprising: The method comprises the steps of: A communication connection establishment unit is configured to establish a communication connection between the simulator and the design-under-test module after starting the simulator and the design-under-test module; A command parameter obtaining unit is configured to automatically obtain the command parameters to be transmitted from a pre-configured command parameter exclusive path, wherein the command parameter exclusive path is configured as a communication path specially used for storing the command parameters to be transmitted; A parameter transmission unit is configured to transmit the command parameters to be transmitted to the design-under-test module.

9. The system of claim 8, wherein, The method further comprises the steps of: An obtaining and judging unit is configured to judge whether the command parameters to be transmitted are successfully obtained after the command parameter obtaining unit obtains the command parameters to be transmitted from the pre-configured command parameter exclusive path; A mode switching unit is configured to automatically switch to the standard input and output mode to receive the uploaded command parameters to be transmitted when the obtaining and judging unit judges that the obtaining fails.

10. The system of claim 8, wherein, The method further comprises the steps of: A parameter packaging and storing unit is configured to: Packaging the command parameters to be transmitted in the form of a string to form a parameter package; the command parameters to be transmitted include the number of configuration registers of the design-under-test module, the size of each configuration register, the vendor identification and the device identification; Storing the parameter package to the pre-configured command parameter dedicated path.

11. The system of claim 8, wherein, Further comprising: A configuration file storage unit, configured to store the start configuration parameters of the simulator and the start configuration parameters of the design-under-test module as independent text files before the simulator and the design-under-test module are started; A configuration file loading unit, configured to load the text files in a specified order during the start of the simulator, so that the start configuration parameters of the simulator and the start configuration parameters of the design-under-test module are separated in the loading sequence from the command parameters to be transmitted.

12. The system of claim 11, wherein, The configuration file loading unit is further configured to: if the text file corresponding to the start configuration parameters of the design-under-test module is loaded incorrectly or an error occurs in the device communication path, only load the text file corresponding to the start configuration parameters of the simulator.

13. The system of claim 8, wherein, Further comprising: A state monitoring unit, configured to monitor the resource usage state of the simulator and the running state of the design-under-test module during the process in which the command parameter acquisition unit acquires the command parameters to be transmitted from the pre-configured command parameter dedicated path; A parameter adjustment unit, configured to adjust the start configuration parameters of the simulator or the design-under-test module according to the monitoring result of the state monitoring unit.

14. The system of claim 8, wherein, The command parameter dedicated path is a command socket path configured based on a Socket mechanism.

15. An electronic device, comprising: A shell, a processor, a memory, a circuit board and a power supply circuit, wherein the circuit board is arranged inside a space enclosed by the shell, and the processor and the memory are arranged on the circuit board; the power supply circuit is configured to supply power to each circuit or device of the electronic device; the memory is configured to store executable program codes; and the processor is configured to run programs corresponding to the executable program codes by reading the executable program codes stored in the memory, and execute the parameter transmission method between the simulator and the design-under-test module according to any one of the preceding claims.

Images