CN113807037B

CN113807037B - Software and hardware collaborative simulation system supporting full-flow development of SOC design

Info

Publication number: CN113807037B
Application number: CN202111189565.5A
Authority: CN
Inventors: 李宗昂
Original assignee: Xinhe Semiconductor Technology Wuxi Co Ltd
Current assignee: Qingzhou Microelectronics Hangzhou Co ltd
Priority date: 2021-10-13
Filing date: 2021-10-13
Publication date: 2023-06-13
Anticipated expiration: 2041-10-13
Also published as: CN113807037A

Abstract

The invention discloses a software and hardware collaborative simulation system supporting full-flow development of SOC design, which comprises a testbench, a testcase and a Result, wherein the testbench comprises software and hardware inside, and software, hardware and UVM inside the testcase. The software and hardware collaborative simulation system supporting the whole flow development of the SOC design provides a set of general simulation system for supporting the whole flow simulation and verification work of the SOC, has a simple structure and a use method, can effectively avoid errors caused by the problem of personal experience of engineers in the development process of the SOC module stage platform, shortens the time for constructing the module stage platform, and realizes the unification of the module stage and the system stage platform.

Description

Software and hardware collaborative simulation system supporting full-flow development of SOC design

Technical Field

The invention relates to the technical field of integrated circuits, in particular to a software and hardware collaborative simulation system supporting full-flow development of an SOC design.

Background

With the increasing national investment and support of the Integrated Circuit (IC) industry, fabless companies have increased in recent years, and although the direction of doing so is not the same, the same development flow is followed for all design companies, as shown in fig. 1, wherein building a simulation and verification platform is an essential important link. It can be seen from fig. 1 that the design of an SOC (system on a chip) chip generally includes 9 links, the links of planning and planning a project-initiated scheme are removed, and the flow can be divided into two development phases, namely Front end and Back end, wherein almost every phase is accompanied by the need for simulation and verification. The quality of the design of the control chip with complex control can be controlled only by the existence of the simulation verification link, so that the defects introduced in the design can be controlled to the maximum extent, and the chips produced subsequently can work normally. With the increasing rise in product functionality, the number of processors and IP (Intellectual Property, transliterated as intellectual property) integrated on a chip, in integrated circuit design, IP core refers to a verified, reusable integrated circuit design module with some exact functionality, and the complexity of IP itself is increasing. If the IPs in a chip can be considered as units in a combined matrix, the complexity increase of each unit will cause an exponential increase in simulation and verification difficulty for the entire chip, so that the simulation and verification are more and more proportional to the entire chip design flow. The workload of current verification already accounts for 70% to 80% of the whole SoC development period. This is because the integrated development speed of SOC has been significantly improved with the development of IP technology and tools but there has been no shortcut to the verification work. As SOC chip scale increases, which is a great challenge for both time and labor of simulation verification work, the ratio of development engineers and verification engineers in a team is typically up to 1:3 or even 1:4. therefore, improving the efficiency of chip verification has become critical, and the SOC development process has a powerful, efficient, flexible and scalable verification system as the key for chip success.

From the delivery point of view, the IC design is to convert the content of the chip product system scheme into RTL (register transfer level) codes, then convert the RTL codes into Netlist (gate level Netlist file), finally convert Netlist into binary GDSII file and deliver it to Foundry (Foundry), and the Foundry Foundry produces the actual chip, and the conversion flow is shown in FIG. 2. So that today professional IC design companies all have their own specialized chip simulation verification team. The team work is to construct corresponding simulation platforms for DUT (Design Under Test) delivered by different links (shown in fig. 1) in the process and perform simulation verification, the conversion process shown in fig. 2 is guaranteed by the simulation verification means as much as possible, the problems introduced by the links in the conversion process are ensured to be in a controllable range, so that defects are converged to standards capable of streaming, however, various problems exist in the simulation verification system platform of the current chip, the technology related to module-level development is many, different interfaces and protocols are used for different modules, because the level and experience difference of verification engineers are different, the time spent by each person is different, a great amount of time spent by the catcher engineer on researching the simulation verification platform constructed by the former person often appears, experience accumulation is left but the work efficiency is not effectively improved as the former project is like, and the module-level simulation verification platform constructed by using the UVM mode is different in organization structure and using method of the platform, so that inconvenience is brought to the transmission of the technology and the use of the subsequent person. Therefore, the workload of building a module-level verification platform in the whole SOC development flow can not be effectively controlled, and the produced labor results are difficult to inherit and reuse. In addition, the system-level platform always has a natural gap with the module-level platform. The reason is that the system-level software and hardware co-simulation platform needs to process related software environments according to the used processor, and finally a software environment without an operating system (bare metal) is built for processing software excitation so as to realize the integration of software and hardware. Although this approach is a simulation approach closest to the actual chip, it has not been unified due to the unique structural features of the platform and the traditional module level platform.

Disclosure of Invention

The invention aims to provide a software and hardware collaborative simulation system supporting the full-flow development of an SOC design, so as to solve the problem that the simulation and verification system used in the current engineering in the background technology has serious defects at the module level and the system level and cannot efficiently support the development of the SOC chip. However, for an SOC project, it is desirable to effectively control both the human effort and the engineering time consumption, so overcoming the shortcomings of the above simulation verification system would have to bring great benefit.

In order to achieve the above purpose, the present invention provides the following technical solutions: the software and hardware collaborative simulation system supporting the full-flow development of the SOC design comprises a testbench, a testcase and a Result, wherein the testcase comprises a software and a hardware in the testcase, the testcase comprises a software, hardware and a UVM in the testcase, and the Result comprises a wave, a log and a coverage in the testcase;

testbench: the Testbench stores some common content used by the simulation and verification system, which is responsible for the full-time maintenance staff of the system, and other verification engineers in the team need not pay attention to. The part can be divided into two parts according to the support of software and hardware, namely software and hardware which are respectively responsible for processing the software environment and the hardware environment in the system;

testcase: the Testcase and testbench are co-constructed with a portion of a simulation verification system to create a simulation environment. Except that testcase can be freely built by the system user to incentives. Since testbench is ready for perfect hardware and software environments, the verification engineer has high flexibility, and can generate incentives by fully utilizing software and hardware, and the part of testcase reserved with UVM flexibly constructs sequences for the verification engineer as a supplement to the UVM sequences of hardware in testbench. Three types of excitation of the system are selectable, and a verification engineer can decide to select one, two or all types according to the needs to construct and realize simulation of various complex scenes;

result: the part is used for storing various results generated in simulation, various waveform files generated after the system is operated are stored in Wave, formats of fdb, vpd and the like of the main stream are supported, and the problem that an engineer is conveniently verified to position by using the familiar waveform files and debug tools is solved. The Log catalog storage system compiles a print report generated in the simulation stage, and the coverage catalog stores a coverage rate-related file of the simulation for CDV (coverage rate driven verification) simulation. The verification engineer can check the coverage type concerned by using any mode of code coverage, assertion coverage and coverage group, and flexibly adopts various modes to ensure the convergence of verification.

Preferably, the software and hardware co-simulation system supporting the whole flow development of the SOC design comprises the following steps:

step (1): the user is required to be ready for various required stimuli, such as: placing excitation written by using C codes and assembly codes in software, placing Verilog type code excitation in hardware, placing sequence using UVM in UVM, then starting a start command to specify testcase to be simulated, and running the system;

step (2): the system can automatically judge the simulation types according to whether software-type excitation exists in the excitation or not, wherein the simulation types can be classified into two types of module-level simulation and system-level simulation according to the SOC simulation flow: case 1 when a module level simulation is required, since the simulation does not require software excitation, when the system determines that the input file of step (1) has no software excitation, the system automatically determines that the module level simulation or the subsystem simulation without the processor is required. The stimulus at this time as shown in (2) of fig. 5 may be one or both of hardware and UVM. And (5) automatically skipping the steps (3) and (4) after the system judges and entering the step (5). In case 2, if the step (1) judges that the stimulus contains software stimulus such as C code, the stimulus is executed downwards, and the step (3) is entered;

step (3): the system recognizes that software excitation is required, and automatically invokes a file in software (shown as (1) in fig. 5) of testbench to compile a software code, so as to generate a binary file which can be used for co-simulation of software and hardware, and the whole process is shown as shown in fig. 3. This stage can be seen as the processing stage of software without hardware involvement;

step (4): at this stage, the system has completed processing the software code, and the system will automatically place the binary files compiled by the software under the directory corresponding to the testcase name in result, where the compiled process files, such as assembly files, will also be included. As shown in fig. 3. The system prepares the processed software and hardware to form a set of system-level simulation environment which can be driven by using software excitation;

step (5): the system can add a hardware model required by simulation according to the needs of a user. An alternative model is stored in the model shown in FIG. 5 (4). The model can be selected at this step, whether at the module level or at the system level. The only difference is that if the flow is to jump from step (2) to step (5), only the behavior-level model of the processor can be selected if the operation of the processor is to be emulated. While the process from step (3) (4) to step (5) is a behavioral model of the processor, because the software simulation process and the preparation work of step (3) (4) are both performed for the simulation of the processor, the hardware and software required for the simulation of the processor are already provided in the processing platform from step (3) (4) and the model of the processor is not required. The peripheral models except the processor model, whether the module-level simulation or the system-level simulation, can be selected or not according to the situation;

step (6): the system will add the user selected added hardware model to the hardware environment at this stage. The DUT that combines the selected model and the code of the SOC chip into one whole that can be emulated is shown in FIG. 9, all of which are referred to as DUT (design under test), which is a direct object of the system emulation. Where BFM represents a functional model of a processor, the following model1 may represent a model of any peripheral device. Because the hardware part (see (4) of fig. 5) in the testbench of the system has good support for various hardware models, the optional models cover the requirement of the SOC for working at each stage of development, and various models such as verilog, systemverilog and the like can be provided for simulation;

step (7): the system will automatically compile the DUT, and the process will also include code rule checking for the hardware environment, and the generated result will have log directory (shown in fig. 5 (3)) corresponding to the emulated testcase name under result, which is convenient for querying relevant information. Generally, the result of no error prompt does not affect the subsequent operation, so the automatic flow of the system can continue to execute the next operation. If errors occur at this stage, the system automatically stops subsequent operations, and the user needs to check the error information in log in result, and restart simulation after solving the problem. Automatically proceeding down to step (8) if there is no error occurrence system;

step (8): the system will simulate (simulation) the software and hardware co-simulation environment constructed before (formed after completing the operations of steps (3) (4) (5) (6) (7)) or the separate hardware simulation environment (formed after completing the operations of steps (5) (6) (7)). The system selects a corresponding simulator (simulator) according to the command input by the user in the step (1), and also selects to perform front-end simulation or back-end simulation according to the command. Therefore, whether the simulation is module-level simulation or system-level simulation, whether the simulation is RTL simulation or NETLIST simulation can be completed, and the system supports the simulation requirement for the full-flow development of the SOC;

step (9): the stage is a stage for judging whether the simulation result is normal or not, and mainly means to give a prompt of relevant error information for an engineer to analyze through printing information in log. The means for printing information can be information of information printed by hardware through a $display function or information printed by a systemverilog assert mode, and the printing information of software can be used as supplement in system simulation with participation of software excitation. The user can judge the simulation result according to the preset information in the excitation. The content and result files of this section are stored in result (as shown in fig. 5 (3)), and the system provides the user with wave and coverage files to help analyze simulation results in addition to log. The user accurately judges whether the simulation passes through analysis of the simulation result file in the result, and returns to the step (1) again to perform the simulation again until a correct result is obtained after the problem is located by the debug tool;

step (c): this stage represents the end of a single testcase simulation flow, but does not mean the end of a module level simulation or a system level simulation, so this is an indispensable stage. Referring to fig. 5 (3), at this stage, according to the different testcases of the system operation, different testcase names of the catalogues are generated under the result catalogue, and each testcase catalog contains the catalogues of wave, log and coverage for storing the classification result after simulation. For CDV (coverage driven verification), the separate use case generally cannot meet the requirements of code coverage or function coverage (function coverage), so that the simulation results related to directory storage of coverage are specially set, coverage can be continuously improved along with the increase of testcase simulation scenes, and finally the requirements of the function coverage and the code coverage are finished.

Preferably, the Hardware is a common part of Hardware that includes support for Hardware incentives written in traditional verilog language, as well as support for simulation environments built by UVM methodology. When the simulation requires software or hardware related files, the system automatically invokes the related files in software and hardware under testbench.

Preferably, the hardware part in the Testbench stores the model of the universal interface and protocol under a special model directory, and the hardware directory of the Testbench is specially provided with a lower-level directory of UVM for storing related files.

Preferably, the directory of software changes, which not only retains the support of Risc-v for the previous item, but also increases support for ARM.

Compared with the prior art, the invention has the beneficial effects that: the software and hardware collaborative simulation system supporting the whole flow development of the SOC design provides a set of general simulation system for supporting the whole flow simulation and verification work of the SOC, has a simple structure and a use method, can effectively avoid errors caused by the problem of personal experience of engineers in the development process of the SOC module stage platform, and shortens the time for constructing the module stage platform. The system itself allows for inheritance and multiplexing between items and thus facilitates the accumulation and delivery of technology. The verification engineer can put major effort and time on top of the build stimulus during module level verification, both improving efficiency and effectively controlling the quality of the simulation verification.

The invention is compatible with the hardware simulation and hardware model of the traditional mode, such as a Verilog model, and also supports advanced UVM verification methodologies, systems Verilog and other models, and can fully exert the advantages of the two. As shown in (4) of FIG. 5, the Model in testbench stores traditional hardware models, and the ENVs of various UVM are stored under the UVM, so that the verification engineer can select the Model types according to the needs when using the system, and the Model is fully considered and supported in the architecture level of the system, thereby greatly facilitating the use of the Model by users. The invention realizes unification of two main flow modes in the system simulation verification stage, not only can realize higher-level excitation by using a software and hardware collaborative simulation technology, but also can exert the advantage of UVM. As shown in FIG. 5 (2), verifying that engineers are free to choose the type of stimulus that needs to be applied among testcases, building their own stimulus file system under different directories will automatically recognize and load these files and form the stimulus. Thus, the method overcomes the defect that UVM lacks real processor codes and software operations in system level verification, and overcomes the defect that UVM rich sequences cannot be used as excitation in software and hardware co-simulation technology. The invention realizes the unification of the module level platform and the system level platform. A large number of differently formed platforms are no longer present in one SOC chip project. The system realizes the integration of the module level and the system level platform through a scientific and reasonable architecture, and an SOC chip verification engineer can flexibly switch the module level and the system level simulation under the same set of system without maintaining various different types of platforms, thereby avoiding the problems of possible bringing in of platform environment switching, testcase transplanting and the like. Effectively improves the working efficiency and reduces the possibility of error

In the use of the invention, the user is not required to consider the difference problem of the front simulation and the rear simulation in the environment setting, and the system has the capability of supporting the full-flow development simulation of the SOC. The software and hardware system simulation system supporting the full-flow development of the SOC has the advantages of simple structure and clear function division, and is convenient for different people to use.

Drawings

FIG. 1 is a schematic diagram of a development flow of an SOC chip according to the present invention;

FIG. 2 is a schematic diagram of the development flow of the SOC chip of the present invention;

FIG. 3 is a schematic diagram of a system for collaborative simulation of SOC chip software and hardware according to the present invention;

FIG. 4 is a schematic diagram of two system level DUTs in the development of a SOC chip according to the present invention;

FIG. 5 is a schematic diagram of a system architecture according to the present invention;

FIG. 6 is a schematic diagram showing the structural change of software in the Testbench of the present invention;

FIG. 7 is a schematic representation of a simulation of various types of stimulus inputs of the present invention;

FIG. 8 is a schematic diagram of a system simulation flow of the present invention;

FIG. 9 is a schematic diagram of the structure of a DUT of a SOC system with the addition of a hardware model according to the present invention.

Detailed Description

The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.

Referring to fig. 1-9, the present invention provides a technical solution: the software and hardware collaborative simulation system supporting the full-flow development of the SOC design comprises a testbench, a testcase and a Result, wherein the testcase comprises software and hardware inside, the testcase comprises software, hardware and UVM inside, and the Result comprises wave, log and coverage inside;

In the invention, the following components are added: hardware is a common part of Hardware that includes support for Hardware incentives written in the traditional verilog language, as well as support for simulation environments built by UVM methodologies. When the simulation requires software or hardware related files, the system automatically invokes the related files in software and hardware under testbench.

In the invention, the following components are added: the hardware part in the Testbench stores the model of the universal interface and protocol in a special model directory, and a lower-level directory specially provided with UVM (UVM) is used for storing related files in the hardware directory of the Testbench.

In the invention, the following components are added: the directory of software changes, which not only retains the support of Risc-v for the previous item, but also increases support for ARM.

Working principle: before the software and hardware collaborative simulation system supporting the whole flow development of the SOC design is used, step one is to prepare various required excitation for a user, such as: the stimulus written by the C code and the assembly code is placed in software, the Verilog type code stimulus is placed in hardware, the sequence using UVM is placed in UVM, and then a start command is started to specify testcase needing simulation, so that the system is operated.

Step two, the system automatically judges the simulation type, the judgment basis is to classify according to whether the excitation of the software type exists in the excitation, and the simulation is classified into two types of module-level simulation and system-level simulation according to the SOC simulation flow: case 1 when a module level simulation is required, since the simulation does not require software excitation, when the system judges that the input file of the previous step has no software excitation, the system automatically judges that the module level simulation or the subsystem simulation without a processor is required. The stimulus at this time as shown in (2) of fig. 5 may be one or both of hardware and UVM. And after the system judges, the system automatically skips the third step and the fourth step and enters the fifth step. If the step I judges that the stimulus contains software stimulus such as C code, the condition 2 is executed downwards, after entering the step III, the system recognizes that the software stimulus needs to be processed at the moment, and automatically invokes the file in the software (shown as (1) in fig. 5) of testbench to compile the software code, so as to generate a binary file which can be used for the collaborative simulation of software and hardware, and the whole process is shown as fig. 3. This stage can be seen as the processing stage of software without hardware involvement;

step four, the system completes the processing of the software codes, and the system automatically puts the binary files compiled by the software under the directory corresponding to the testcase name in result, wherein the compiled process files such as assembly files and the like are also included. As shown in fig. 3. The system prepares the processed software and hardware to form a set of system-level simulation environment which can be driven by using software excitation; and step five, the system adds a hardware model required by simulation according to the requirement of a user. An alternative model is stored in the model shown in FIG. 5 (4). The model can be selected at this step, whether at the module level or at the system level. The only difference is that if the flow is to jump from step two to step five, then the operation of the processor is to be simulated only the behavior-level model of the processor is selected. The process from step three, four to five is to select the behavior level model of the processor, because the process of the software simulation and the preparation work of step three, four are all carried out for the simulation of the processor, and the process platform passing through step three, four is provided with the model that the hardware and the software required by the simulation of the processor are not needed any more. For the peripheral models except the processor model, whether the module level simulation or the system level simulation can be selected or not according to the situation, the system can add the hardware model selected and added by the user to the hardware environment in the sixth stage. The DUT that combines the selected model and the code of the SOC chip into one whole that can be emulated is shown in FIG. 9, all of which are referred to as DUT (design under test), which is a direct object of the system emulation. Where BFM represents a functional model of a processor, the following model1 may represent a model of any peripheral device. Because the hardware part (see (4) of fig. 5) in the testbench of the system has good support for various hardware models, the optional models cover the requirement of the SOC for working at each stage of development, and various models such as verilog, systemverilog and the like can be provided for simulation;

the system will automatically compile the DUT, and the process will also include code rule checking for the hardware environment, and the generated result will have log directory (shown in fig. 5 (3)) corresponding to the emulated testcase name under result, which is convenient for querying relevant information. Generally, the result of no error prompt does not affect the subsequent operation, so the automatic flow of the system can continue to execute the next operation. If errors occur at this stage, the system automatically stops subsequent operations, and the user needs to check the error information in log in result, and restart simulation after solving the problem. If no error generating system automatically goes down to step eight, the system will simulate the software and hardware co-simulation environment constructed before (formed after completing steps three, four, five, six and seven operations) or the single hardware simulation environment (formed after completing steps five, six and seven operations) at this stage. The system selects a corresponding simulator (simulator) according to the command input by the user in the step one, and also selects to perform front-end simulation or back-end simulation according to the command. Therefore, whether the simulation is module-level simulation or system-level simulation, whether the simulation is RTL simulation or NETLIST simulation can be completed, and the system supports the simulation requirement for the full-flow development of the SOC;

step nine, the stage of judging whether the simulation result is normal or not, mainly means to give a prompt of relevant error information for engineers to analyze through the printed information in log. The means for printing information can be information of information printed by hardware through a $display function or information printed by a systemverilog assert mode, and the printing information of software can be used as supplement in system simulation with participation of software excitation. The user can judge the simulation result according to the preset information in the excitation. The content and result files of this section are stored in result (as shown in fig. 5 (3)), and the system provides the user with wave and coverage files to help analyze simulation results in addition to log. The user accurately judges whether the simulation passes through the analysis of the simulation result file in the result, and can return to the step again and again to simulate until the correct result is obtained after the problem is located by the debug tool, and the step ten represents the end of the single testcase simulation flow, but does not represent the end of the module level simulation or the system level simulation, so that the simulation is an indispensable stage. Referring to fig. 5 (3), at this stage, according to the different testcases of the system operation, different testcase names of the catalogues are generated under the result catalogue, and each testcase catalog contains the catalogues of wave, log and coverage for storing the classification result after simulation. For CDV (coverage driven verification), the separate use case generally cannot meet the requirements of code coverage or function coverage (function coverage), so that the simulation results related to directory storage of coverage are specially set, coverage can be continuously improved along with the increase of testcase simulation scenes, and finally the requirements of the function coverage and the code coverage are finished.

To sum up: the software and hardware collaborative simulation system supporting the whole flow development of the SOC design provides a set of general simulation system for supporting the whole flow simulation and verification work of the SOC, has a simple structure and a use method, can effectively avoid errors caused by the problem of personal experience of engineers in the development process of the SOC module stage platform, and shortens the time for constructing the module stage platform. The system itself allows for inheritance and multiplexing between items and thus facilitates the accumulation and delivery of technology. The verification engineer can put major effort and time on top of the build stimulus during module level verification, both improving efficiency and effectively controlling the quality of the simulation verification.

It is noted that relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus.

The related modules involved in the system are all hardware system modules or functional modules in the prior art combining computer software programs or protocols with hardware, and the computer software programs or protocols involved in the functional modules are all known technologies for those skilled in the art and are not improvements of the system; the system is improved in interaction relation or connection relation among the modules, namely, the overall structure of the system is improved, so that the corresponding technical problems to be solved by the system are solved.

Although embodiments of the present invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made therein without departing from the principles and spirit of the invention, the scope of which is defined in the appended claims and their equivalents.

Claims

1. A software and hardware collaborative simulation system supporting full-flow development of SOC design comprises a Testbench module, a Testcase module and a Result module, and is characterized in that: the inside of the Testbench module comprises a software module and a hardware module, the inside of the Testcase module comprises a software module, a hardware module and a UVM module, and the inside of the Result module comprises a wave module, a log module and a coverage module;

testbench module: the Testbench module stores some public contents used by the collaborative simulation system, the part of the public contents are responsible for full-time maintenance personnel of the collaborative simulation system, other verification engineers in a team do not need to pay attention, and the part of the public contents is divided into a software module and a hardware module according to the support of software and hardware and is respectively responsible for processing software environments and hardware environments in the system;

testcase module: the Testcase module and the Testcase module are constructed together to form a simulation environment with a part belonging to a collaborative simulation system, and the difference is that the Testcase module can be freely constructed and stimulated by a system user, as the Testcase module is ready for perfect hardware module and software module environment, a verification engineer has very high flexibility, and can fully utilize software and hardware to generate the stimulation, and the part of the Testcase module reserved with the UVM module can flexibly construct sequences for the verification engineer as the supplement of the UVM sequences of the hardware module in the Testcase module, the stimulation of the system is three types of options, and the verification engineer can decide to select one, two or all types of options according to the needs to construct and realize the simulation of various complex scenes;

result module: the module is used for storing various results generated in simulation, various waveform files generated after the system is operated are stored in the Wave module, the fsdb and vpd formats of the main stream are supported, a verification engineer can conveniently utilize the familiar waveform files and debug tool positioning problems, a log module catalog storage system compiles a printing report generated in a simulation stage, a coverage rate-related file of the coverage rate storage simulation of the coverage module catalog is used for CDV simulation, the verification engineer can check the type of the coverage rate concerned by using any mode of code coverage rate, assertion coverage rate and coverage group, and convergence of verification is flexibly ensured by adopting various modes.

2. The method for implementing the software and hardware co-simulation system supporting full-process development of the SOC design according to claim 1, wherein the method comprises the following steps:

step (1): the method comprises the steps that a user is required to prepare various required incentives, incentives written by using C codes and assembly codes are placed in a software module, verilog type code incentives are placed in a hardware module, sequences using UVM modules are placed in a UVM module, then a start command is started to specify a Testcase module to be simulated, and the system is operated;

step (2): the system can automatically judge the simulation type, and the judgment basis is whether the excitation is of a software type or not, and the simulation flow can be divided into two types of module-level simulation and system-level simulation according to the SOC simulation flow: when the module-level simulation is needed, as the simulation is not needed to be excited by software, when the system judges that the input file in the step (1) is not excited by software, the system automatically judges that the module-level simulation or the subsystem simulation without a processor is needed to be carried out, and the excitation at the moment can be one or two of a hardware module and a UVM module; after the system judges, the steps (3) and (4) are automatically skipped to enter the step (5); if the step (1) judges that the stimulus contains the C code software stimulus, the stimulus is executed downwards, and the step (3) is entered;

step (3): the system recognizes that the software excitation is required to be processed at the moment, and automatically invokes a file in a software module of the Testbench module to compile a software code to generate a binary file which can be used for software and hardware collaborative simulation, wherein the stage can be regarded as a processing stage of the software module without hardware participation;

step (4): the system has completed the processing of the software code, the system will automatically put the binary files compiled by the software under the catalog corresponding to the name of the Testcase module in the Result module, including the compiled process files, the system will prepare the processed software and hardware to form a set of system-level simulation environment which can be driven by the software excitation;

step (5): the system can add a hardware model required by simulation according to the needs of a user, whether the module-level simulation or the system-level simulation is provided with the model, if the process jumps from the step (2) to the step (5), the operation of the simulation processor can only select the behavior-level model of the processor, and for the process from the step (3) and the step (4) to the step (5), the behavior-level model of the processor is not required to be selected, because the software simulation process and the preparation work of the step (3) and the step (4) are both performed for the simulation of the processor, and the processing platform from the step (3) and the step (4) is provided with the hardware and the software required by the simulation of the processor, so that the model of the processor is not required; the peripheral models except the processor model, whether the peripheral models are module-level simulation or system-level simulation, can be selected or not according to the conditions of the peripheral models;

step (6): the system will add the hardware model selected by the user to the hardware environment, so that the selected model and the code of the SOC chip are combined to form a DUT which can be simulated integrally; because the hardware module part in the test module of the system has good support for various hardware models, the optional model covers the requirement of the SOC for working at each stage of development, and various models of verilog and systemverilog can be provided for simulation;

step (7): the system can automatically compile the DUT, the process also comprises code rule inspection of the hardware environment, and the generated Result can be stored in a log module directory of the corresponding simulated Testcase module name under the Result module, so that the related information can be conveniently inquired; the result of no error prompt does not influence the subsequent operation, so the automatic flow can continue to execute the next operation; if errors occur at the stage, the system automatically stops subsequent operation, a user needs to go to a Result module to check error information in a log module, simulation is restarted after the error information is solved, and if no error occurs, the system automatically goes down to the step (8);

step (8): the system simulates the software and hardware collaborative simulation environment or the independent hardware simulation environment constructed before in this stage, the system selects the corresponding simulator according to the command input by the user in the step (1), and also selects to perform the front simulation or the back simulation according to the command, so that the system can complete the module-level simulation or the system-level simulation, and the RTL simulation or the NETLIST simulation, and therefore, the system supports the simulation requirement for the whole-flow development of the SOC;

step (9): the stage is a stage of judging whether the simulation result is normal or not, and prompts of relevant error information are given through printing information in the log module for engineers to analyze; the printing information can be information printed by hardware through a $display function or information printed by a systemverilog assert mode, the printing information of software can be used as supplement in system simulation with participation of software excitation, a user can judge a simulation Result according to preset information in the excitation, the content and the Result file of the part are stored in a Result module, the system provides wave and coverage files for the user except the log module to help the user analyze the simulation Result, the user accurately judges whether the simulation passes through the analysis of the simulation Result file in the Result module, and returns to the step (1) again through the debug tool positioning problem until the correct Result is obtained;

step (c): the step represents the end of the simulation flow of a single Testcase module, but does not mean the end of the module level simulation or the system level simulation, the step generates different catalogues of the Testcase module names under the Result module catalogues according to different Testcase modules operated by the system, each catalogue of the Testcase modules comprises a catalogue of each wave module, each log module and each coverage module for storing the classification Result after the simulation, and the requirement of code coverage or function coverage function coverage cannot be met by a single use case for coverage-driven verification CDV, so that the simulation Result related to the catalogue storage of coverage is set, the coverage can be continuously improved along with the increase of Testcase module simulation scenes, and the requirements of the function coverage and the code coverage are finally finished.

3. The software and hardware co-simulation system supporting full-process development of an SOC design of claim 1, wherein: the hardware module is a common part of hardware, comprises support for hardware excitation written in a traditional verilog language, also comprises support for a simulation environment built by a UVM methodology, and when software or hardware related files are needed for simulation, the system can automatically call the related files in the software module and the hardware module under the Testbench module.

4. The software and hardware co-simulation system supporting full-process development of an SOC design of claim 1, wherein: the hardware module part in the Testbench module stores the model of the universal interface and protocol under a special model directory, and the hardware module directory of the Testbench module is specially provided with a lower-level directory of the UVM module for storing related files.

5. The software and hardware co-simulation system supporting full-process development of an SOC design of claim 1, wherein: the directory of the software module changes, which not only retains the support of Risc-v for the previous item, but also increases support for ARM.