CN113807037A - Software and hardware collaborative simulation system supporting SOC design full-process development - Google Patents
Software and hardware collaborative simulation system supporting SOC design full-process development Download PDFInfo
- Publication number
- CN113807037A CN113807037A CN202111189565.5A CN202111189565A CN113807037A CN 113807037 A CN113807037 A CN 113807037A CN 202111189565 A CN202111189565 A CN 202111189565A CN 113807037 A CN113807037 A CN 113807037A
- Authority
- CN
- China
- Prior art keywords
- simulation
- hardware
- software
- model
- result
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000004088 simulation Methods 0.000 title claims abstract description 207
- 238000013461 design Methods 0.000 title claims abstract description 28
- 238000011165 process development Methods 0.000 title claims description 11
- 238000012795 verification Methods 0.000 claims abstract description 70
- 238000000034 method Methods 0.000 claims abstract description 48
- 230000008569 process Effects 0.000 claims abstract description 33
- 238000011161 development Methods 0.000 claims abstract description 31
- 230000005284 excitation Effects 0.000 claims description 42
- 238000012545 processing Methods 0.000 claims description 11
- 230000006870 function Effects 0.000 claims description 10
- 238000007639 printing Methods 0.000 claims description 10
- 230000002093 peripheral effect Effects 0.000 claims description 8
- 239000013589 supplement Substances 0.000 claims description 6
- 230000003542 behavioural effect Effects 0.000 claims description 5
- 238000012360 testing method Methods 0.000 claims description 4
- 238000010276 construction Methods 0.000 claims description 3
- 238000010586 diagram Methods 0.000 description 10
- 238000005516 engineering process Methods 0.000 description 10
- 230000008901 benefit Effects 0.000 description 7
- 230000007547 defect Effects 0.000 description 5
- 238000009825 accumulation Methods 0.000 description 3
- 230000009471 action Effects 0.000 description 3
- 238000006243 chemical reaction Methods 0.000 description 3
- 230000006872 improvement Effects 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 238000013459 approach Methods 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 230000010354 integration Effects 0.000 description 2
- 239000000047 product Substances 0.000 description 2
- 238000002054 transplantation Methods 0.000 description 2
- 230000004075 alteration Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000004927 fusion Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 239000011159 matrix material Substances 0.000 description 1
- 239000002184 metal Substances 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000012384 transportation and delivery Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F30/00—Computer-aided design [CAD]
- G06F30/30—Circuit design
- G06F30/31—Design entry, e.g. editors specifically adapted for circuit design
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2115/00—Details relating to the type of the circuit
- G06F2115/12—Printed circuit boards [PCB] or multi-chip modules [MCM]
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Abstract
The invention discloses a software and hardware collaborative simulation system supporting SOC design full-flow development, which comprises a testbench, a testcase and a Result, wherein the testbench comprises software and hardware, and the testcase comprises software, hardware and UVM. The software and hardware collaborative simulation system supporting the SOC design full-flow development provides a set of universal simulation system supporting the simulation and verification work of the full flow of the SOC, has a simple structure and a simple use method, can effectively avoid errors caused by the personal experience of engineers in the development process of an SOC module level platform, reduces the building time of the module level platform, and realizes the unification of the module level platform and a system level platform.
Description
Technical Field
The invention relates to the technical field of integrated circuits, in particular to a software and hardware collaborative simulation system supporting SOC design full-process development.
Background
With the increasing investment and support of the Integrated Circuit (IC) industry in China, in recent years, Fabless companies are increasing, and although the direction of the manufacture is different, the same development process is followed for all design companies as shown in fig. 1, wherein building a simulation and verification platform is an essential important link. As can be seen from fig. 1, the design of an SOC (system on chip) chip usually includes 9 links, the planning and planning links of the project initial plan are removed, and the process can be divided into two development stages, namely Front end and Back end, wherein almost each stage 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 normal work of the subsequently produced chip can be ensured. With the increasing improvement of product functions, the number of processors and IP (Intellectual Property) integrated on a chip increases, and the complexity of the IP itself increases. If each IP in the chip can be considered as a unit in a combined matrix, the complexity increase of each unit will cause exponential increase of the simulation and verification difficulty for the whole chip, so that the simulation and verification occupy a larger and larger proportion of the whole chip design flow. The workload verified today is already 70% to 80% of the whole SoC development cycle. This is because the integrated development speed of SOC has been significantly improved as IP technology and tools have been developed but there has been no shortcut for the verification work. As the size of the SOC chip is increased, which is a great challenge to the time and labor of the simulation verification work, the ratio of development engineers to verification engineers in a team is usually 1: 3 or even 1: 4. therefore, it has become important to improve the efficiency of chip verification, and it is the key of chip success that a verification system with high power, high efficiency, flexibility and good expandability is provided in the SOC development process.
From the perspective of the consignment, the IC design is to convert the contents of the system scheme of the chip product into RTL (register transfer level) codes, then convert the RTL codes into Netlist (gate level Netlist file), and finally convert the Netlist into a binary gdsii file and send the binary gdsii file to foundation (Foundry), and then the foundation is used to produce the actual chip, and this conversion process is shown in fig. 2. So that professional IC design companies all have their own specialized chip simulation verification team. The team works by setting up corresponding simulation platforms for DUTs (design Under tests) delivered by different links (shown in FIG. 1) in the process and performing simulation verification, ensuring the conversion process shown in FIG. 2 by means of simulation verification as much as possible, ensuring that the problems introduced by each link in the conversion are in a controllable range, and enabling the defects to converge to the standard capable of being taped, however, the simulation verification system platform of the current chip has various problems, the module-level development involves many technologies, different modules use different interfaces and protocols, and since the time spent by each person for verifying the level and the difference of experience of engineers is different, the engineers who take over a lot of time to research the simulation verification platform set up by the previous person often appears, and the work efficiency cannot be effectively improved as if the experience accumulation is left in the previous project, the platform is also a module-level simulation verification platform constructed by using a UVM mode, but the organization structure and the use method of the platform are different, which inevitably brings inconvenience to the transmission of the technology and the use of a successor. Therefore, the workload of building a module-level verification platform in the whole SOC development process cannot be effectively controlled, and the generated labor achievements are difficult to inherit and reuse. In addition, system-level platforms are naturally separated from module-level platforms. The reason is that a system-level software and hardware collaborative simulation platform needs to process related software environments according to a used processor, and finally a software environment without an operating system (bare metal) is built for processing software excitation so as to realize the fusion of software and hardware. Although this approach is the closest simulation approach to the actual chip, it has not been unified with the traditional module-level platform due to the unique structural features of the platform.
Disclosure of Invention
The invention aims to provide a software and hardware collaborative simulation system supporting SOC design full-process development, so as to solve the problem that the simulation and verification system used in the prior art has serious defects of module level and system level and cannot efficiently support the development of an SOC chip. For an SOC project, both the labor input and the engineering time consumption are expected to be effectively controlled, so that overcoming the disadvantages of the above simulation verification system will bring great benefits.
In order to achieve the purpose, the invention provides the following technical scheme: a software and hardware collaborative simulation system supporting SOC design full-flow development comprises a testbench, a testcase and a Result, wherein the testbench comprises software and hardware, the testcase comprises software, hardware and UVM, and the Result comprises wave, log and coverage;
testbench: the Testbench stores some public content used by the simulation and verification system, which is taken charge of by the professional maintainer of the system, and other verification engineers in the team do not need to pay attention. 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 the testbench are jointly constructed into a simulation environment together with a part belonging to a simulation verification system. A difference is that testcase can be freely built incentives by system users. Since testbench is prepared with complete hardware and software environments, the verification engineer has high flexibility, the excitation can be generated in a software and hardware mode, and the part of testbench reserved with UVM is used for flexibly constructing sequence for the verification engineer to supplement the UVM sequence of hardware in testbench. Therefore, three types of excitation of the system can be selected, and a verification engineer can select one type, two types or all types according to needs to construct and realize simulation of various complex scenes;
and (4) Result: the part is used for storing various results generated in simulation, various waveform files generated after the system operates are stored in Wave, mainstream formats such as fsdb and vpd are supported, and the problem that an engineer can conveniently verify the positioning problem by using the familiar waveform files and debug tools is solved. The Log catalog stores the print report generated by the system compiling and simulating stage, and the coverage catalog stores the simulated coverage related file for CDV (coverage driven verification) simulation use. The verification engineer can check the concerned coverage rate type in any mode of using code coverage rate, assertion coverage rate and coverage group, and flexibly adopt various modes to ensure the convergence of verification.
Preferably, the software and hardware co-simulation system supporting the SOC design full-process development includes the following steps:
the method comprises the following steps: the user is required to be prepared for various desired stimuli, such as: placing a stimulus written by using a C code and an assembly code in software, placing a Verilog type code in hardware for stimulus, placing a sequence using UVM in UVM, starting a start command to specify a testcase to be simulated, and operating the system;
step two: the system can automatically judge the type of simulation according to whether the excitation of the software type exists in the excitation or not, and the judgment basis can be divided into two types, namely module-level simulation and system-level simulation, according to the flow of SOC simulation: case 1 when module-level simulation is needed, since the simulation does not require software excitation, when there is no software excitation in the input file of the system judgment step r, the system automatically judges whether module-level simulation or subsystem simulation without a processor is needed. The excitation at this time may be one or both of hardware and UVM as shown in (c) of fig. 5. After the system judges, the third step and the fourth step are automatically skipped to enter the fifth step. Case 2, if the excitation contains software excitation such as C codes and the like in the step (i), executing downwards, and entering the step (iii);
step three: the system recognizes that software excitation needs to be processed, and compiles software code by automatically calling files in software (shown in fig. 5) of testbench to generate binary files for software and hardware co-simulation, and the whole process is shown in fig. 3. This phase can be viewed as the processing phase of software without hardware involvement;
step IV: at this stage, the system has finished processing the software code, and the system will automatically put the binary file compiled by the software into the directory corresponding to the testcase name in the result, which also includes the compiled process file such as assembly file. As shown in fig. 3. At this stage, the system prepares the processed software and hardware to form a system-level simulation environment which can be driven by software excitation;
step five: the system will add the hardware model needed for simulation according to the needs of the user. The alternative model is stored in the model shown in (r) in fig. 5. There are models that can be selected at this step, whether for module level simulation or system level. The only difference is that if the process goes from step two to step five, only the behavioral model of the processor can be selected when the operation of the processor is simulated. The process from the third step to the fourth step does not need to select a behavioral model of the processor, because the process of software simulation and the preparation work of the third step are both performed aiming at the simulation of the processor, and the processing platform from the third step has hardware and software which are needed by the processor simulation and do not need the model of the processor. Whether the peripheral models outside the processor model are module-level simulation or system-level simulation can be selected or not according to the conditions of the peripheral models;
step (c): the system will add the hardware model that the user chooses to add to the hardware environment at this stage. The selected model and the code of the SOC chip are combined to form a whole to be a DUT that can be simulated as shown in fig. 9, all contents of which are called DUT (design under test) and are direct objects of system simulation. Where BFM represents a functional model of a processor, the model1 below may represent a model of any peripheral. Since the hardware part (see the fourth part in fig. 5) in the testbench of the system has good support for various hardware models, the selectable model covers the requirements of the work of each stage of SOC development, and various models such as verilog, systemverilog and the like can be provided for simulation;
step (c): the system will automatically perform compilation operation on the DUT, and this process will also include code rule checking on the hardware environment, and the generated result will have a log directory (as shown in fig. 5 (c)) corresponding to the emulated testcase name under result, which facilitates query of relevant information. Generally, the subsequent operation is not affected by the result without error prompt, so the automatic flow of the system can continue to execute the next operation. If an error occurs in this stage, the system automatically stops subsequent operations, and a user needs to go to a result to check error information in the log, and restart the simulation after the error is solved. If no error occurs, the system will automatically go down to step viii;
step (v): in this stage, the system simulates (simulation) the software and hardware collaborative simulation environment (formed after completing the operation) or the independent hardware simulation environment (formed after completing the operation). The system will select the corresponding simulator (simulator) according to the command inputted by the user in step (i), and also select the front-end simulation or the back-end simulation according to the command. Therefore, the system can complete both module-level simulation and system-level simulation, and can support the simulation requirement on SOC full-flow development;
step ninthly: the stage is used for judging whether the simulation result is normal or not, and the method is mainly used for providing a prompt of related error information through printing information in a log for an engineer to analyze. The means for printing the information can be information printed by hardware through a $ display function or information printed by a systemverilog alert mode, and the printing information of software can be used as supplement in system simulation with software excitation participation. The user can judge the simulation result according to the information preset in the stimulus. The content and result file of the part are stored in result (as shown in fig. 5, c), besides log, the system also provides the user with files of wave and coverage to help analyze the simulation result. The user accurately judges whether the simulation passes through by analyzing the simulation result file in the result, and can return to the step (I) again to carry out the simulation until a correct result is obtained after the problem is positioned by the debug tool;
step (r): this stage represents the end of a single testcase simulation flow, but does not imply the end of a module-level simulation or a system-level simulation, so this is an indispensable stage. In this stage, according to different testcases running in the system, directories with different testcase names are generated in the result directory, and the directory of each testcase contains directories of wave, log and coverage for storing the classification result after simulation. For CDV (coverage driven verification), a single use case generally cannot meet the requirements of code coverage or function coverage, so that a catalog of coverage is specially set to store related simulation results, the coverage can be continuously improved with the increase of testcase simulation scenes, and finally the requirements on function coverage and code coverage are completed.
Preferably, Hardware is a public part of Hardware and comprises support for Hardware excitation written in a traditional verilog language and support for a simulation environment built by UVM methodology. When the emulation needs software or hardware related files, the system can automatically call the related files in software and hardware under testbench.
Preferably, the hardware part of the Testbench includes a model of a general interface and a protocol to be stored in a special model directory, and a UVM subordinate directory is specially arranged under the hardware directory of the Testbench to store related files.
Preferably, the software directory changes, and the previous item not only retains the support of Risc-v but also increases the support of ARM.
Compared with the prior art, the invention has the beneficial effects that: the software and hardware collaborative simulation system supporting the SOC design full-flow development provides a set of universal simulation system supporting the simulation and verification work of the full flow of the SOC, has a simple structure and a simple use method, can effectively avoid errors caused by the personal experience of engineers in the development process of an SOC module level platform, and reduces the time for building the module level platform. The system itself allows for inheritance and multiplexing between items and thus facilitates the accumulation and transfer of technologies. The verification engineer can put main energy and time on the construction incentive during the module-level verification, so that the efficiency is improved, and the quality of simulation verification can be effectively controlled.
The invention is compatible with hardware simulation and hardware model in traditional mode, such as Verilog type model, and simultaneously supports advanced UVM verification methodology and systemverilog model, and can give full play to the advantages of the two. As shown in the fourth diagram of fig. 5, the Model in the testbench stores a traditional hardware Model, and the ENV of various UVMs is stored under the UVM, so that when the system is used, a verification engineer can select the type of the Model according to needs, and the Model is fully considered and supported on the architecture level of the system, thereby greatly facilitating the use of the Model by a user. The invention realizes the unification of two main flow modes in the system simulation verification stage, can realize higher-level excitation by using a software and hardware collaborative simulation technology, and can also exert the advantage of UVM. As shown in fig. 5 (a), in testcase, the verification engineer can freely select the type of incentive to be applied, and building an own incentive file system under different directories will automatically recognize and load the files and form an incentive. Therefore, the defects that the UVM lacks real processor codes and software operation in the aspect of system level verification and cannot use UVM rich sequence as an incentive in the software and hardware co-simulation technology are overcome. The invention realizes the unification of the module-level platform and the system-level platform. A large number of platforms of different formats can no longer appear in one SOC chip project. The system realizes the integration of the module-level platform and the system-level platform through a scientific and reasonable framework, an SOC chip verification engineer can flexibly switch the simulation of the module-level platform and the system-level platform under the same system, the platforms of various different types are not maintained, and the problems possibly brought in by platform environment switching, testcase transplantation and the like are avoided. Effectively improves the working efficiency and reduces the possibility of error
In the invention, the difference problem of the pre-simulation and the post-simulation in the environment setting process is not needed to be considered by a user, and the system has the capability of supporting SOC full-flow development simulation. The software and hardware system simulation system supporting SOC full-flow development provided by the invention has the advantages of simple structure and clear function division, and is convenient for different personnel to use the system.
Drawings
FIG. 1 is a schematic diagram of the development process of the SOC chip according to the present invention;
FIG. 2 is a schematic diagram of the SOC chip development process deliveries change according to the present invention;
FIG. 3 is a schematic diagram of a software and hardware co-simulation system of an SOC chip according to the present invention;
FIG. 4 is a schematic diagram showing a comparison of two system level DUTs in SOC chip development 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 of software structure change in Testbench according to the present invention;
FIG. 7 is a schematic illustration of a simulation of various types of stimulus inputs in accordance with the present invention;
FIG. 8 is a schematic diagram of a simulation process of the system of the present invention;
FIG. 9 is a schematic diagram of the DUT structure of the SOC system with the added hardware model.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
Referring to fig. 1-9, the present invention provides a technical solution: a software and hardware collaborative simulation system supporting SOC design full-flow development comprises a testbench, a testcase and a Result, wherein the testbench comprises software and hardware, the testcase comprises software, hardware and UVM, and the Result comprises wave, log and coverage;
testbench: the Testbench stores some public content used by the simulation and verification system, which is taken charge of by the professional maintainer of the system, and other verification engineers in the team do not need to pay attention. 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 the testbench are jointly constructed into a simulation environment together with a part belonging to a simulation verification system. A difference is that testcase can be freely built incentives by system users. Since testbench is prepared with complete hardware and software environments, the verification engineer has high flexibility, the excitation can be generated in a software and hardware mode, and the part of testbench reserved with UVM is used for flexibly constructing sequence for the verification engineer to supplement the UVM sequence of hardware in testbench. Therefore, three types of excitation of the system can be selected, and a verification engineer can select one type, two types or all types according to needs to construct and realize simulation of various complex scenes;
and (4) Result: the part is used for storing various results generated in simulation, various waveform files generated after the system operates are stored in Wave, mainstream formats such as fsdb and vpd are supported, and the problem that an engineer can conveniently verify the positioning problem by using the familiar waveform files and debug tools is solved. The Log catalog stores the print report generated by the system compiling and simulating stage, and the coverage catalog stores the simulated coverage related file for CDV (coverage driven verification) simulation use. The verification engineer can check the concerned coverage rate type in any mode of using code coverage rate, assertion coverage rate and coverage group, and flexibly adopt various modes to ensure the convergence of verification.
In the invention: hardware is a common part of Hardware and comprises support for Hardware stimulus written in a traditional verilog language and support for a simulation environment built by UVM methodology. When the emulation needs software or hardware related files, the system can automatically call the related files in software and hardware under testbench.
In the invention: the hardware part in the Testbench includes a model of a general interface and a protocol to be stored in a special model directory, and a lower directory specially provided with a UVM (universal video module) is arranged in the hardware directory of the Testbench to store related files.
In the invention: software's directory changes, which not only retains the previous entries' support for Risc-v but also adds support for ARM.
The working principle is as follows: before the software and hardware co-simulation system supporting the SOC design full-flow development is used, the first step is to prepare various required stimuli for a user, such as: placing a stimulus written by C codes and assembly codes in software, placing a Verilog type code stimulus in hardware, placing a sequence using UVM in UVM, starting a starting command to specify testcase needing simulation, and running the system.
Step two, the system automatically judges the simulation type according to whether the excitation of the software type exists in the excitation or not, and the judgment is classified according to whether the excitation of the software type exists in the excitation or not, wherein the process of SOC simulation can be divided into two types of module-level simulation and system-level simulation: case 1 when a module-level simulation is needed, the system automatically determines whether a module-level simulation or a subsystem simulation without a processor is needed when the system determines that there is no software stimulus in the input file of the previous step because the simulation does not require software stimulus. The excitation at this time may be one or both of hardware and UVM as shown in (c) of fig. 5. And after the system judges, the system automatically skips the third step and the fourth step and enters the fifth step. In case 2, if the excitation is judged to contain software excitation such as C code, the software excitation is executed downwards, after the third step, the system identifies that the software excitation needs to be processed, and automatically calls a file in software (shown as (r) in fig. 5) of testbench to compile the software code, so as to generate a binary file which can be used for software and hardware co-simulation, and the whole process is shown in fig. 3. This phase can be viewed as the processing phase of software without hardware involvement;
and step four, after the system finishes the processing of the software codes, the system automatically places the binary files compiled by the software in an entry corresponding to the testcase name in result, wherein the binary files also comprise compiled process files such as assembly files and the like. As shown in fig. 3. At this stage, the system prepares the processed software and hardware to form a system-level simulation environment which can be driven by software excitation; and in the fifth step, the system adds a hardware model required by simulation according to the requirement of a user. The alternative model is stored in the model shown in (r) in fig. 5. There are models that can be selected at this step, whether for module level simulation or system level. The only difference is that if the flow jumps from step two to step five, then only the behavioral level model of the processor can be selected to simulate the operation of the processor. And for the process which goes through the third step, the fourth step and the fifth step, a behavioral model of the processor does not need to be selected, because the process of software simulation and the preparation work of the third step and the fourth step are both carried out aiming at the simulation of the processor, and the processing platform which goes through the third step and the fourth step is provided with hardware and software which are needed by the simulation of the processor, and the model of the processor is not needed any more. Whether the peripheral models outside the processor model are module-level simulation or system-level simulation can be selected or not according to the situation, and the system adds the hardware model selected by the user into the hardware environment in the stage of step six. The selected model and the code of the SOC chip are combined to form a whole to be a DUT that can be simulated as shown in fig. 9, all contents of which are called DUT (design under test) and are direct objects of system simulation. Where BFM represents the functional model of a processor, model1 below may represent the model of any peripheral. Since the hardware part (see the fourth part in fig. 5) in the testbench of the system has good support for various hardware models, the selectable model covers the requirements of the work of each stage of SOC development, and various models such as verilog, systemverilog and the like can be provided for simulation;
the system will automatically perform compilation operation on the DUT, and this process will also include code rule checking on the hardware environment, and the generated result will have a log directory (as shown in fig. 5 (c)) corresponding to the emulated testcase name under result, which facilitates query of relevant information. Generally, the subsequent operation is not affected by the result without error prompt, so the automatic flow of the system can continue to execute the next operation. If an error occurs in this stage, the system automatically stops subsequent operations, and a user needs to go to a result to check error information in the log, and restart the simulation after the error is solved. If no error occurs, the system automatically goes down to step eight, and at this stage, the system simulates (simulation) the previously constructed software and hardware co-simulation environment (formed after completing the operations of step three, four, five, six and seven) or the separate hardware simulation environment (formed after completing the operations of step five, six and seven). The system will select the corresponding simulator (simulator) according to the command inputted by the user in the first step, and also select the front-end simulation (front-end simulation) or the back-end simulation (back-end simulation) according to the command. Therefore, the system can complete both module-level simulation and system-level simulation, and can support the simulation requirement on SOC full-flow development;
and the stage of the ninth step is a stage of judging whether the simulation result is normal, and the method is mainly used for providing a prompt of related error information for an engineer to analyze through printing information in the log. The means for printing the information can be information printed by hardware through a $ display function or information printed by a systemverilog alert mode, and the printing information of software can be used as supplement in system simulation with software excitation participation. The user can judge the simulation result according to the information preset in the stimulus. The content and result file of the part are stored in result (as shown in fig. 5, c), besides log, the system also provides the user with files of wave and coverage to help analyze the simulation result. The user can accurately judge whether the simulation passes through by analyzing the simulation result file in the result, and can re-return to the step for simulation again after positioning the problem through the debug tool until a correct result is obtained, and the stage ten represents the end of a single testcase simulation flow, but does not mean the end of the module-level simulation or the system-level simulation, so that the stage is an indispensable stage. In this stage, according to different testcases running in the system, directories with different testcase names are generated in the result directory, and the directory of each testcase contains directories of wave, log and coverage for storing the classification result after simulation. For CDV (coverage driven verification), a single use case generally cannot meet the requirements of code coverage or function coverage, so that a catalog of coverage is specially set to store related simulation results, the coverage can be continuously improved with the increase of testcase simulation scenes, and finally the requirements on function coverage and code coverage are completed.
In summary, the following steps: the software and hardware collaborative simulation system supporting the SOC design full-flow development provides a set of universal simulation system supporting the simulation and verification work of the full flow of the SOC, has a simple structure and a simple use method, can effectively avoid errors caused by the personal experience of engineers in the development process of an SOC module level platform, and reduces the time for building the module level platform. The system itself allows for inheritance and multiplexing between items and thus facilitates the accumulation and transfer of technologies. The verification engineer can put main energy and time on the construction incentive during the module-level verification, so that the efficiency is improved, and the quality of simulation verification can be effectively controlled.
The invention is compatible with hardware simulation and hardware model in traditional mode, such as Verilog type model, and simultaneously supports advanced UVM verification methodology and systemverilog model, and can give full play to the advantages of the two. As shown in the fourth diagram of fig. 5, the Model in the testbench stores a traditional hardware Model, and the ENV of various UVMs is stored under the UVM, so that when the system is used, a verification engineer can select the type of the Model according to needs, and the Model is fully considered and supported on the architecture level of the system, thereby greatly facilitating the use of the Model by a user. The invention realizes the unification of two main flow modes in the system simulation verification stage, can realize higher-level excitation by using a software and hardware collaborative simulation technology, and can also exert the advantage of UVM. As shown in fig. 5 (a), in testcase, the verification engineer can freely select the type of incentive to be applied, and building an own incentive file system under different directories will automatically recognize and load the files and form an incentive. Therefore, the defects that the UVM lacks real processor codes and software operation in the aspect of system level verification and cannot use UVM rich sequence as an incentive in the software and hardware co-simulation technology are overcome. The invention realizes the unification of the module-level platform and the system-level platform. A large number of platforms of different formats can no longer appear in one SOC chip project. The system realizes the integration of the module-level platform and the system-level platform through a scientific and reasonable framework, an SOC chip verification engineer can flexibly switch the simulation of the module-level platform and the system-level platform under the same system, the platforms of various different types are not maintained, and the problems possibly brought in by platform environment switching, testcase transplantation and the like are avoided. Effectively improves the working efficiency and reduces the possibility of error
In the invention, the difference problem of the pre-simulation and the post-simulation in the environment setting process is not needed to be considered by a user, and the system has the capability of supporting SOC full-flow development simulation. The software and hardware system simulation system supporting SOC full-flow development provided by the invention has the advantages of simple structure and clear function division, and is convenient for different personnel to use the system.
It is noted that, herein, relational terms such as first and second, and the like may be 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. Also, 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 combining computer software programs or protocols with hardware in the prior art, and the computer software programs or the protocols involved in the functional modules are all known in the technology of persons skilled in the art, and are not improvements of the system; the improvement of the system is the interaction relation or the connection relation among all the modules, namely the integral structure of the system is improved, so as to solve the corresponding technical problems to be solved by the system.
Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that changes, modifications, substitutions and alterations can be made in these embodiments without departing from the principles and spirit of the invention, the scope of which is defined in the appended claims and their equivalents.
Claims (5)
1. The utility model provides a support software and hardware collaborative simulation system of SOC design full process development, includes testbench, testcase and Result, its characterized in that: the inside of the testbench comprises software and hardware, the inside of the testcase comprises software, hardware and UVM, and the inside of the Result comprises wave, log and coverage;
testbench: the Testbench stores some public contents used by the simulation and verification system, the contents of the part are responsible for professional maintainers of the system, other verification engineers in a team do not need to pay attention, and the part can be divided into two parts, namely software and hardware according to support of software and hardware, and the two parts are respectively responsible for processing the software environment and the hardware environment in the system;
testcase: the Testcase and the testbench jointly construct a simulation environment with a part belonging to a simulation verification system, and the difference lies in that the Testcase can be freely constructed and excited by a system user, because the testbench has already prepared perfect hardware and software environments, a verification engineer has high flexibility and can generate excitation by fully utilizing software and hardware modes, and the part reserved with UVM in the Testcase gives the verification engineer flexible construction sequence which is used as a supplement to the UVM sequence of the hardware in the testbench, so that the excitation of the system has three types which can be selected, and the verification engineer can select one, two or all types according to needs to construct and realize the simulation of various complex scenes;
and (4) Result: the part is used for storing various results generated in simulation, various waveform files generated after the system runs are stored in Wave, mainstream formats such as fsdb and vpd are supported, a verification engineer can conveniently position problems by using familiar waveform files and debug tools, a Log directory is used for storing printing reports generated in a compiling and simulation stage of the system, files related to coverage rate of the simulation are stored in a coverage rate directory and used for CDV (coverage rate driven verification), the verification engineer can check concerned coverage rate types by using any mode of code coverage rate, assertion coverage rate and coverage rate group, and various modes are flexibly adopted to ensure the convergence of the verification.
2. The software and hardware co-simulation system supporting SOC design full-process development according to claim 1, wherein the invention has the following steps:
the method comprises the following steps: the user is required to be prepared for various desired stimuli, such as: placing a stimulus written by using a C code and an assembly code in software, placing a Verilog type code in hardware for stimulus, placing a sequence using UVM in UVM, starting a start command to specify a testcase to be simulated, and operating the system;
step two: the system can automatically judge the type of simulation according to whether the excitation of the software type exists in the excitation or not, and the judgment basis can be divided into two types, namely module-level simulation and system-level simulation, according to the flow of SOC simulation: case 1 when module-level simulation is needed, since the simulation does not require software excitation, when the input file of the system determination step (i) has no software excitation, the system automatically determines that module-level simulation or subsystem simulation without a processor is needed, as shown in (ii) of fig. 5, the excitation may be one or both of hardware and UVM. After the system judges, the system automatically skips the steps III and IV and enters the step V, and if the situation 2 judges that software excitation such as C codes exists in the excitation, the software excitation is executed downwards and enters the step III;
step three: the system recognizes that software excitation needs to be processed at this time, a file in software (shown as (r) in fig. 5) of testbench is automatically called to compile software codes, so as to generate a binary file which can be used for software and hardware collaborative simulation, the whole process is shown in fig. 3, and the stage can be regarded as that no hardware participates in the processing stage of the software;
step IV: at this stage, the system will prepare the processed software and hardware to form a system-level simulation environment that can be driven by software excitation, as shown in fig. 3;
step five: the system will add the hardware model needed for simulation according to the needs of the user, the optional model is stored in the model shown in (r) in fig. 5, whether the module level simulation or the system level has the model to select at this step, the only difference is that if the flow is transferred from the step two to the step five, the operation of the processor to be simulated can only select the behavioral level model of the processor, for the flow from the third step to the fifth step, the behavior level model of the processor does not need to be selected, because the process of software simulation and the preparation work of the step (c) are all made aiming at the simulation of the processor, the processing platform of the step (c) has the hardware and the software which are needed by the simulation of the processor and does not need the model of the processor any more, whether the peripheral models outside the processor model are module-level simulation or system-level simulation can be selected or not according to the conditions of the peripheral models;
step (c): the system at this stage will add the hardware model selected and added by the user into the hardware environment, so that the selected model and the code of the SOC chip are combined to form a whole to be a DUT that can be simulated as shown in fig. 9, all contents in the drawing are called DUT (design under test) and are direct objects of system simulation, wherein BFM represents a functional model of a processor, and the following model1 can represent any peripheral model, because the hardware part (see, (r) in fig. 5) in the testbench of the system has good support for various hardware models, the selectable model covers the needs of the SOC development work at each stage, and various models such as verilog and systemverilog can be provided for simulation;
step (c): the system can automatically compile the DUT, the process can also comprise code rule check of a hardware environment, a generated result can have a log catalog (shown as the third part of figure 5) corresponding to a simulated testcase name under result, and related information can be conveniently inquired, generally, a result without error prompt does not influence subsequent operation, so that the automatic flow of the system can continuously execute the next operation, if an error occurs at the stage, the system can automatically stop the subsequent operation, a user needs to go to the result to check the error information in the log, the simulation is restarted after the problem is solved, and if no error occurs, the system can automatically go down to the step (III);
step (v): the system simulates (simulation) a software and hardware collaborative simulation environment (formed after operation in the step III) or an independent hardware simulation environment (formed after operation in the step III) which is constructed before in the stage III), selects a corresponding simulator (simulator) according to the command input by the user in the step I, and also selects front-end simulation or back-end simulation according to the command, so that the system can support the simulation requirement on SOC full-process development regardless of module-level simulation or system-level simulation, and regardless of RTL simulation or NETLIST simulation;
step ninthly: the stage is a stage for judging whether the simulation result is normal, mainly providing a prompt of related error information for an engineer to analyze through printing information in log, wherein the information printing means can be information printed by hardware through a $ display function or information printed by a systemverilog alert mode, the printing information of the software can be used as supplement in the system simulation with the participation of the software incentive, the user can judge the simulation result according to the information preset in the incentive, the content and result file of the part are stored in result (as shown in fig. 5, c), besides log, the system also provides files such as wave and coverage for the user to help analyze the simulation result, the user can accurately judge whether the simulation passes through by analyzing the simulation result file in the result, the problem can be positioned by the debug tool, and then the simulation is carried out again in the step I until a correct result is obtained;
step (r): 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 essential stage, see fig. 5, this stage generates directories with different testcase names under a result directory according to different testcases of system operation, and each directory of the testcase includes directories of wave, log, and coverage for storing the simulated classification result.
3. The software and hardware co-simulation system supporting SOC design full-process development according to claim 1, wherein: hardware is a public part of Hardware and comprises support for Hardware excitation written in a traditional verilog language and support for a simulation environment built by UVM methodology. When the emulation needs software or hardware related files, the system can automatically call the related files in software and hardware under testbench.
4. The software and hardware co-simulation system supporting SOC design full-process development according to claim 1, wherein: the hardware part in the Testbench includes a model of a general interface and a protocol and stores the model under a special model directory, and a UVM subordinate directory is specially arranged under the hardware directory of the Testbench and used for storing related files.
5. The software and hardware co-simulation system supporting SOC design full-process development according to claim 1, wherein: the software's directory changes, which not only retains the previous entries' support for Risc-v but also adds support for ARM.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111189565.5A CN113807037B (en) | 2021-10-13 | 2021-10-13 | Software and hardware collaborative simulation system supporting full-flow development of SOC design |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111189565.5A CN113807037B (en) | 2021-10-13 | 2021-10-13 | Software and hardware collaborative simulation system supporting full-flow development of SOC design |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113807037A true CN113807037A (en) | 2021-12-17 |
| CN113807037B CN113807037B (en) | 2023-06-13 |
Family
ID=78897624
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111189565.5A Active CN113807037B (en) | 2021-10-13 | 2021-10-13 | Software and hardware collaborative simulation system supporting full-flow development of SOC design |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113807037B (en) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114117977A (en) * | 2022-01-27 | 2022-03-01 | 广东省新一代通信与网络创新研究院 | Method for automatically verifying processor system scene |
| CN114417768A (en) * | 2022-03-29 | 2022-04-29 | 南京金阵微电子技术有限公司 | Digital-analog hybrid simulation method and system of Ethernet chip |
| CN116719729A (en) * | 2023-06-12 | 2023-09-08 | 南京金阵微电子技术有限公司 | Universal verification platform, universal verification method, medium and electronic equipment |
| WO2024060593A1 (en) * | 2022-09-22 | 2024-03-28 | 济南新语软件科技有限公司 | Distributed simulation verification platform for soc chips and method |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20020152456A1 (en) * | 2001-04-12 | 2002-10-17 | Nightingale Andrew Mark | Software and hardware simulation |
| CN105302950A (en) * | 2015-10-19 | 2016-02-03 | 北京精密机电控制设备研究所 | Software and hardware cooperation based cross-linking simulation test method for programmable logic device |
| CN111950212A (en) * | 2020-08-13 | 2020-11-17 | 湖南进芯电子科技有限公司 | Efficient multi-mode verification platform and method |
-
2021
- 2021-10-13 CN CN202111189565.5A patent/CN113807037B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20020152456A1 (en) * | 2001-04-12 | 2002-10-17 | Nightingale Andrew Mark | Software and hardware simulation |
| CN105302950A (en) * | 2015-10-19 | 2016-02-03 | 北京精密机电控制设备研究所 | Software and hardware cooperation based cross-linking simulation test method for programmable logic device |
| CN111950212A (en) * | 2020-08-13 | 2020-11-17 | 湖南进芯电子科技有限公司 | Efficient multi-mode verification platform and method |
Non-Patent Citations (1)
| Title |
|---|
| 李建成;庄钊文;张亮;: "SOC设计的软硬件协同验证研究" * |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114117977A (en) * | 2022-01-27 | 2022-03-01 | 广东省新一代通信与网络创新研究院 | Method for automatically verifying processor system scene |
| CN114417768A (en) * | 2022-03-29 | 2022-04-29 | 南京金阵微电子技术有限公司 | Digital-analog hybrid simulation method and system of Ethernet chip |
| WO2024060593A1 (en) * | 2022-09-22 | 2024-03-28 | 济南新语软件科技有限公司 | Distributed simulation verification platform for soc chips and method |
| CN116719729A (en) * | 2023-06-12 | 2023-09-08 | 南京金阵微电子技术有限公司 | Universal verification platform, universal verification method, medium and electronic equipment |
| CN116719729B (en) * | 2023-06-12 | 2024-04-09 | 南京金阵微电子技术有限公司 | Universal verification platform, universal verification method, medium and electronic equipment |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113807037B (en) | 2023-06-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN113807037A (en) | Software and hardware collaborative simulation system supporting SOC design full-process development | |
| CN109684681B (en) | High-level verification method using UVM verification platform | |
| CN110865971B (en) | System and method for verifying SOC chip | |
| CN104268310B (en) | The method that UVM verification environment is called using special graphical interface | |
| CN115841089B (en) | System-level chip verification platform and verification method based on UVM | |
| US20080306721A1 (en) | Dynamic-Verification-Based Verification Apparatus Achieving High Verification Performance and Verification Efficiency and the Verification Methodology Using the Same | |
| US5923567A (en) | Method and device for test vector analysis | |
| CN115828839A (en) | System-level verification system and method for SOC (System on chip) | |
| CN104750603A (en) | Multi-core DSP (Digital Signal Processor) software emulator and physical layer software testing method thereof | |
| CN111859834B (en) | UVM-based verification platform development method, system, terminal and storage medium | |
| CN112241347B (en) | Method for realizing SystemC verification and verification platform assembly architecture | |
| CN111782539A (en) | Test and diagnosis integrated development platform based on domestic operating system | |
| US8265918B1 (en) | Simulation and emulation of a circuit design | |
| CN113807041A (en) | Circuit system simulation method and device, electronic equipment and storage medium | |
| CN101083507B (en) | IEEE1149.1 protocol based universal test IP method | |
| CN115587558A (en) | Interface-based verification environment generation method and device, equipment and storage medium | |
| JP2007528553A (en) | DYNAMIC VERIFICATION FOR IMPROVING VERIFICATION PERFORMANCE AND VERIFICATION EFFICIENCY-A verification method based on a basic method and a verification methodology using the same | |
| CN114692539A (en) | Method for realizing parallel verification of SOC (System on chip) chip verification architecture | |
| Bombieri et al. | Hybrid, incremental assertion-based verification for TLM design flows | |
| CN114398852A (en) | SOC development process | |
| CN114282464A (en) | Collaborative simulation method in chip simulation verification and application | |
| CN103017815A (en) | Visual general test system and visual general test method | |
| Bruce et al. | Maintaining consistency between SystemC and RTL system designs | |
| Tang et al. | Research and implementation of an automatic simulation tool | |
| CN112560378B (en) | Be applied to automation platform of integrating complete chip development flow |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20240318 Address after: Room 37, Room 807, Building 2, No. 217 Wujiang Road, Shangcheng District, Hangzhou City, Zhejiang Province, 310000 Patentee after: Qingzhou Microelectronics (Hangzhou) Co.,Ltd. Country or region after: China Address before: 214135 room e1-301, China Sensor Network International Innovation Park, 200 Linghu Avenue, Xinwu District, Wuxi City, Jiangsu Province Patentee before: Xinhe semiconductor technology (Wuxi) Co.,Ltd. Country or region before: China |
|
| TR01 | Transfer of patent right |