CN117150987A - Initial value configuration method for register model - Google Patents
Initial value configuration method for register model Download PDFInfo
- Publication number
- CN117150987A CN117150987A CN202311416850.5A CN202311416850A CN117150987A CN 117150987 A CN117150987 A CN 117150987A CN 202311416850 A CN202311416850 A CN 202311416850A CN 117150987 A CN117150987 A CN 117150987A
- Authority
- CN
- China
- Prior art keywords
- register
- name
- field
- function
- variable
- 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
- 238000000034 method Methods 0.000 title claims abstract description 29
- 238000012360 testing method Methods 0.000 claims abstract description 69
- 238000004806 packaging method and process Methods 0.000 claims abstract description 8
- 238000012546 transfer Methods 0.000 claims abstract description 8
- 230000003068 static effect Effects 0.000 claims description 18
- 238000012795 verification Methods 0.000 claims description 9
- 238000004088 simulation Methods 0.000 abstract description 7
- 238000004377 microelectronic Methods 0.000 abstract description 2
- 230000006870 function Effects 0.000 description 48
- 238000013461 design Methods 0.000 description 7
- 101100117775 Arabidopsis thaliana DUT gene Proteins 0.000 description 4
- 101150091805 DUT1 gene Proteins 0.000 description 4
- 101100444142 Neurospora crassa (strain ATCC 24698 / 74-OR23-1A / CBS 708.71 / DSM 1257 / FGSC 987) dut-1 gene Proteins 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 210000001503 joint Anatomy 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F30/00—Computer-aided design [CAD]
- G06F30/30—Circuit design
- G06F30/32—Circuit design at the digital level
- G06F30/33—Design verification, e.g. functional simulation or model checking
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Evolutionary Computation (AREA)
- Geometry (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Test And Diagnosis Of Digital Computers (AREA)
Abstract
The invention discloses a register model initial value configuration method, which belongs to the technical field of microelectronics and comprises the steps of identifying a register abstract layer file of a register form generation standard; generating a register model by using a ralgen command according to a register abstraction layer file; resolving the register abstraction layer file; identifying whether a register or field is a reserved field; generating a parameter configuration file for a domain segment which is not a reserved domain and has the attribute of being readable and writable or only; adding a set_cfg function in the register model, and calling the set function in the register model inside the set_cfg function; calling a set_cfg function, and configuring expected values of a register model according to transfer parameters when the test case is executed; and calling a packaging function to configure the initial value of the register model. The initial value configuration method of the register model saves simulation time and reduces redundancy of codes.
Description
Technical Field
The invention relates to the technical field of microelectronics, in particular to a register model initial value configuration method.
Background
With the continuous development of integrated circuit technology, the scale and the functional complexity of hardware design are also increasing, more and more functional modules are integrated on the same integrated circuit, and the behavior of each functional module is often configured with a hook corresponding to the register of the module. Under the use of UVM-based register models, it has become relatively simple for a verifier to configure registers. In general, there are several methods of operating a register model: read operation (the act of reading a register and its fields), write operation (the act of writing a register and its fields), peek operation (the act of reading a signal, register or memory value in an emulation environment), poek operation (the act of writing a signal, register or memory value in an emulation environment), get operation (the act of obtaining the current value or specific property of a register or register field), set operation (the act of setting the value or specific property of a register or register field), update operation (the act of updating a register or register field value), and random operation (the act of randomly generating and setting the field value in a register model).
The current common configuration mode is to repeatedly call write operation in a register model in a test environment to realize the configuration of registers, but if the number of registers used in a functional module is large, the registers are configured in the environment or in a specific test case, and a verifier can repeatedly work in a large amount during coding, so that excessive workload and overlong simulation time are caused; and because the attribute of some register inner domain segments is not of a single type, read-write domain segments, read-only write domain segments, write-clear domain segments and the like can be mixed, which can cause difficulties for register configuration.
Disclosure of Invention
The invention aims to provide a register model initial value configuration method.
In order to achieve the above purpose, the technical scheme of the invention is as follows:
a register model initial value configuration method comprises,
step S1, building a UVM verification environment;
s2, recognizing a register form based on the Python script, and generating a standard register abstract layer file;
s3, generating a register model by using a ralgen command according to a register abstraction layer file;
s4, analyzing a register abstract layer file, a module name, a register name and a field name by using a Python script, and storing the attribute, the bit width and the default value of each field;
s5, identifying whether a register or a field is a reserved field or not by using a Python script;
step S6, generating a parameter configuration file plus_aaa_ral for the domain segment which is not a reserved domain and has the attribute of being readable and writable or only, wherein each domain segment which is not a reserved domain and has the attribute of being readable and writable or only corresponds to a variable, and the parameter configuration file plus_aaa_ral contains a statement of each variable;
step S7, adding a set_cfg () function in the register model, and calling the set function in the register model from the inside of the set_cfg () function;
step S8, in the test case, each variable in the parameter configuration file plus_aaa_ral is assigned through a transfer parameter, and the value assigned to each variable is configured into the expected value of the register corresponding to each variable through a set_cfg () function;
and S9, calling a packaging function in the configuration stage of the test environment, wherein the packaging function comprises an update function, the update function checks whether the expected value is consistent with the mirror value, if not, the expected value is written into the tested device, and the mirror value is updated to be the same as the expected value.
In a specific embodiment, in the step S6, the declaration format of the variable is static bit [ width-1:0] block_name_reg_name_field_name, which indicates that the variable belongs to the field field_name of the register reg_name of the block_name, and the width of bits required for the variable is represented by the static variable.
Further, the set function operates on the expected value of the register model as follows
Block_name_reg_name_field_name set (plus_aaa_ral:: block_name_reg_name_field_name), a field field_name representing the register reg_name of the block_name in the parameter configuration file plus_aaa_ral is configured into the corresponding field of the corresponding register of the corresponding module in the register model.
In another embodiment, when a single device under test is configured, the declaration format of the variables in the parameter configuration file plus_aaa_ral is static bit [ width-1:0] block_name_reg_name_field_name [ M ], where M represents the array depth.
Further, when configuring N devices under test, i.e. 1 st device under test to N th device under test, the declaration format of the variable in the parameter configuration file plus_aaa_ral is static bit [ width-1:0] block_name_reg_name_field_name [ M ] [ N ].
Further, the set_cfg () function in step S7 is declared as set_cfg (int_id), and if the parameter inst_id in the set_cfg (int_id) function is equal to n-1, the set function operates on the expected value of the register model as follows
block_name. Reg_name. Field_name. Set (plus_aaa_ral: the method comprises the steps of configuring a field field_name of a register reg_name of a module block_name in a parameter configuration file plus_aaa_ral to a corresponding field of a corresponding register of an n-th tested device corresponding module in a register model, wherein the value range of n is 0-N-1.
Further, when configuring the N devices under test, i.e. the 1 st device under test to the N device under test, a set_cfg (N-1) function is called, and the value assigned to each variable is configured to the expected value of the register corresponding to each variable in the N device under test.
Optionally, the assignment of the same type of parameter is placed in a common parameter profile plus_aaa_ral, which can be parsed by different test cases.
The initial value configuration method of the register model has the beneficial effects that based on the characteristics of the set function and the update function in the register model, the initial value configuration method can only configure the register with changed values through the transfer parameters, and compared with the traditional write operation, the initial value configuration method can achieve the purpose of saving simulation time; on the basis, all the domain segments supporting writing are subjected to parameter declaration according to the module name, the register name and the field name, random values or fixed values are assigned to the parameters in the test cases, the same kind of parameter assignment can be placed in a common configuration file, and different test cases can analyze the common configuration file, so that redundancy of codes is reduced.
In order to make the above features and advantages of the present invention more comprehensible, embodiments accompanied with figures are described in detail below.
Drawings
FIG. 1 is a flow chart of a method for configuring initial values of a register model according to the present invention.
Detailed Description
In order to make the purpose and technical solutions of the embodiments of the present invention more clear, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. It will be apparent that the described embodiments are some, but not all, embodiments of the invention. All other embodiments, which can be made by a person skilled in the art without creative efforts, based on the described embodiments of the present invention fall within the protection scope of the present invention.
FIG. 1 is a flow chart of a method for configuring initial values of a register model according to the present invention. As shown in FIG. 1, a register model initial value configuration method of the present invention comprises the following steps.
And S1, building a UVM verification environment.
Step S2, a register form is identified based on the Python script, and a standard register abstraction layer file (Register Abstraction Layer File, RALF) is generated.
More specifically, a Register form is a file describing a set of registers whose contents include the name, address, default values, bit width, attributes, etc. corresponding to each Register (Register) in the device under test (Device Under Test, DUT).
In particular embodiments, the register form may be a file of any form.
More specifically, the register abstraction layer file is a register file format recognizable by the ralgen command for describing the register model.
And step S3, generating a register model by using a ralgen command according to the register abstraction layer file.
More specifically, the ralgen command is a command line tool of the universal verification methodology (Universal Verification Methodology, UVM) for automatically generating register abstraction layer (Register Abstraction Layer, RAL) code. The register abstraction layer is used to describe a register model, including registers, register fields, register groups, etc., to facilitate register verification by a verification engineer. The ralgen command can automatically generate corresponding SystemVerilog codes based on the register abstraction layer file, and the corresponding SystemVerilog codes are used for constructing the register abstraction layer.
More specifically, the register model describes the set of registers, the manner of data transfer, and the flow of instruction execution in a computer.
Step S4, analyzing the Register abstract layer file by using the Python script, analyzing the module (Block) name, the Register name and the Field (Field) name, and storing the attribute, the bit width and the default value of each Field (Field).
More specifically, in a Register abstraction layer file, modules (blocks), registers (registers), and fields (fields) are typically used to identify hierarchies in the Register model.
Modules (blocks) are typically used to identify a logical module, set of modules, or functional unit, and a module (Block) may contain Registers and associated Fields.
Registers (registers) are used to identify a Register, which typically corresponds to an actual Register in a hardware design, and each Register may contain one or more fields. Register (Register) names are generally capable of clearly expressing the purpose and meaning of a Register.
Fields (fields) are used to identify fields in a register, i.e., bit fields in a register, each Field representing a set of bits in a register and having a particular meaning and purpose. The Field (Field) name generally describes the function and function of a Field.
Further, the bit width (width) of the Field (Field) indicates the number of bits occupied by the Field, which may be a single bit or a range of consecutive bits.
Further, a default value of a Field (Field) indicates an initial state when explicit writing is not performed.
Further, the attributes of the Field (Field) include readable and writable (rw), write-only (wo), and the like.
In step S5, whether a Register (Register) or a Field (Field) is a reserved Field is recognized by the Python script, and a Field section other than the reserved Field is a Field section that can be configured.
Step S6, generating a parameter configuration file plus_aaa_ral for the domain segment which is not a reserved domain and has the attribute of being readable and writable or only, wherein each domain segment which is not a reserved domain and has the attribute of being readable and writable or only corresponds to a variable, and the parameter configuration file plus_aaa_ral contains a statement on each variable and uses the bit width (width) of a Field (Field) when the statement is made; the default value of the load Field (Field) registers the variable.
In one embodiment, the declaration format of the variable is static bit [ width-1:0] block_name_reg_name_field_name, which indicates that the variable belongs to the field field_name of the register reg_name of the block_name, the bit width required by the variable is width, and static indicates that the variable is a static variable.
More specifically, a reserved field is a register field for reserving future uses or undefined functions. Reserved fields are typically used for reserved bits in a register design that are not used in the current version of the design, but may be assigned new functions or attributes in future design versions.
Step S7, adding a set_cfg () function in the register model, wherein the set_cfg () function internally calls the set function in the register model.
The set function is a function of the register model, and the set function is used for updating the expected value of the register model without changing the mirror value of the expected value.
Typically each register in the register model has two values, one a mirrored value and one a desired value.
The mirror value is typically used to describe the real value of a certain register in the device under test, i.e. the real value of that register in the current simulation environment. The mirror value is real-time data in the simulation process and can be obtained by monitoring and analyzing simulation waveforms or real-time information provided by a simulator.
The expected value is used to describe the value expected to be reached on a certain register of the current device under test, which is the expected value set by the tester according to design specifications, test plans, or functional requirements. The expected value is a test target for comparing whether the simulation result meets the expectation or not to verify the correctness of the design.
More specifically, the set function operates on the expected value of the register model as follows
Block_name_reg_name_field_name set (plus_aaa_ral:: block_name_reg_name_field_name), a field field_name representing the register reg_name of the block_name in the parameter configuration file plus_aaa_ral is configured into the corresponding field of the corresponding register of the corresponding module in the register model.
Step S8, call the set_cfg () function in the Build phase (Build phase) of the test Environment (Environment), and configure the expected value of the register model according to the transfer parameters when the test case is executed.
More specifically, in the test case, the parameter configuration file plus_aaa_ral is assigned with each variable by passing the parameter, and a random value or a fixed value may be assigned. The value assigned to each variable is configured into the expected value of the register corresponding to each variable by a set_cfg () function.
Step S9, calling a packaging function in a configuration Phase (configuration Phase) of the test environment, wherein the packaging function configures a Device Under Test (DUT), and the packaging function comprises an update function to realize configuration of initial values of a register model of the Device Under Test (DUT).
The update function is a function of the register model, and the function of the update function is to check whether the expected value is consistent with the mirror value, if not, the expected value is written into a Device Under Test (DUT), and the mirror value is updated to be the same as the expected value.
It should be noted that the same type of parameter assignment may be placed in a common parameter configuration file plus_aaa_ral, and different test cases may parse the common parameter configuration file plus_aaa_ral, so as to achieve the effect of reducing code redundancy.
In one embodiment, two device under test interfaces need to be verified, named device under test DUT0 and device under test DUT1, respectively, for which register models typically need to be instantiated in duplicate, specifically register model ral_model_0 and register model ral_model_1, in a UVM verification environment. Moreover, the configuration of the two devices under test may be random, i.e. different configurations may be performed for device under test DUT0 and device under test DUT 1. The initial value configuration method of the register model can realize verification of the butt joint of the device under test DUT0 and the device under test DUT1 under the condition that the register model has only one part.
To achieve the above function, when the parameter profile plus_aaa_ral is generated in step S6, the variables are declared in the form of an array, i.e., each variable in the parameter profile plus_aaa_ral is declared as two groups, and a one-dimensional array is declared as a two-dimensional array.
In this embodiment, the declaration format of the variable is changed to a static bit [ width-1:0] block_name_reg_name_field_name [2], which represents an array with depth of two, and is suitable for configuring two devices under test.
Further, if a single device under test is configured, the declaration format of the variable in the parameter configuration file plus_aaa_ral is static bit [ width-1:0] block_name_reg_name_field_name [3]; when two devices under test are configured, the declaration format of the variable in the parameter configuration file plus_aaa_ral becomes static bit [ width-1:0] block_name_reg_name_field_name [3] [2].
Similarly, if a single device under test is configured, the declaration format of the variable in the parameter configuration file plus_aaa_ral is static bit [ width-1:0] block_name_reg_name_field_name [ M ], M is the array depth; when N devices under test (i.e., 1 st device under test DUT (0) through N (N-1) th device under test DUT) are configured, the declaration format of the variable in the parameter configuration file plus_aaa_ral becomes static bit [ width-1:0] block_name_reg_name_field_name [ M ] [ N ].
When configuring two devices under test, the set_cfg () function in step S7 also needs to be asserted as set_cfg (int inst_id). The parameter inst_id indicates what number of devices to be tested corresponds to. More specifically, the set_cfg (int_id) function is implemented as follows; if the parameter inst_id is equal to 0, the set function operates on the expected value of the register model as follows
block_name. Reg_name. Field_name. Set (plus_aaa_ral: block_name_reg_name_field_name) [0], representing the configuration of the field field_name of the register reg_name of the block_name in the parameter configuration file plus_aaa_ral into the corresponding field of the corresponding register of the corresponding module of the device under test DUT0 in the register model.
If the parameter inst_id is equal to 1, the set function operates on the expected value of the register model as follows
block_name. Reg_name. Field_name. Set (plus_aaa_ral: block_name_reg_name_field_name) [1] indicates that the field field_name of the register reg_name of the block_name in the parameter configuration file plus_aaa_ral is configured into the corresponding field of the corresponding register of the corresponding module of the device under test DUT1 in the register model.
By analogy, when configuring N devices under test (i.e., 1 st device under test DUT (0) through N device under test DUT (N-1)), the declaration format of the variable in parameter configuration file plus_aaa_ral is static bit [ with-1:0 ] block_name_reg_name_field_name [ M [ N ].
If the parameter inst_id in the set_cfg (int inst_id) function is equal to n-1, the set function operates on the expected value of the register model as follows
block_name. Reg_name. Field_name. Set (plus_aaa_ral: the method comprises the steps of configuring a field field_name of a register reg_name of a module block_name in a parameter configuration file plus_aaa_ral to a corresponding field of a corresponding register of an n-th device under test DUT (n-1) corresponding module in a register model, wherein the value range of n is 0-N-1.
In step S8, when two devices under test are configured, a set_cfg (0) function is called, and then the expected value of DUT0 of the devices under test is configured according to the transfer parameters when the test case is executed; and (3) calling a set_cfg (1) function, and configuring expected values of the DUT1 according to the transfer parameters when the test case is executed.
Similarly, when configuring N tested devices (namely, 1 st tested device DUT (0) to N (N-1) th tested device DUT), calling a set_cfg (N-1) function, configuring the expected value of the N (N-1) th tested device DUT according to the transmission parameters when the test case is executed, and configuring the value assigned to each variable into the expected value of the register corresponding to each variable in the N (N) th tested device.
In step S9 of this embodiment, the encapsulation function is called, and whether the expected value and the mirror value are consistent or not is checked by the update function, if not, the expected value is written into the corresponding device under test, and the mirror value is updated to be the same as the expected value.
Although the present invention has been described with reference to the above embodiments, it should be understood that the invention is not limited thereto, but rather is capable of modification and variation without departing from the spirit and scope of the present invention.
Claims (8)
1. A register model initial value configuration method is characterized by comprising the following steps of,
step S1, building a UVM verification environment;
s2, recognizing a register form based on the Python script, and generating a standard register abstract layer file;
s3, generating a register model by using a ralgen command according to a register abstraction layer file;
s4, analyzing a register abstract layer file, a module name, a register name and a field name by using a Python script, and storing the attribute, the bit width and the default value of each field;
s5, identifying whether a register or a field is a reserved field or not by using a Python script;
step S6, generating a parameter configuration file plus_aaa_ral for the domain segment which is not a reserved domain and has the attribute of being readable and writable or only, wherein each domain segment which is not a reserved domain and has the attribute of being readable and writable or only corresponds to a variable, and the parameter configuration file plus_aaa_ral contains a statement of each variable;
step S7, adding a set_cfg () function in the register model, and calling the set function in the register model from the inside of the set_cfg () function;
step S8, in the test case, each variable in the parameter configuration file plus_aaa_ral is assigned through a transfer parameter, and the value assigned to each variable is configured into the expected value of the register corresponding to each variable through a set_cfg () function;
and S9, calling a packaging function in the configuration stage of the test environment, wherein the packaging function comprises an update function, the update function checks whether the expected value is consistent with the mirror value, if not, the expected value is written into the tested device, and the mirror value is updated to be the same as the expected value.
2. The method of claim 1, wherein in the step S6, the declarative format of the variable is static bit [ width-1:0] block_name_reg_name_field_name, the field field_name of the register reg_name indicating that the variable belongs to the block_name, the width of bits required for the variable is indicated, and the static indicates that the variable is a static variable.
3. A method for configuring initial values of a register model as claimed in claim 2, wherein the set function operates on the expected values of the register model in accordance with the following commands
Block_name_reg_name_field_name set (plus_aaa_ral:: block_name_reg_name_field_name), a field field_name representing the register reg_name of the block_name in the parameter configuration file plus_aaa_ral is configured into the corresponding field of the corresponding register of the corresponding module in the register model.
4. The method of claim 1, wherein when configuring a single device under test, the declaration format of the variables in the parameter configuration file plus_aaa_ral is static bit [ width-1:0] block_name_reg_name_field_name [ M ], where M represents array depth.
5. The method of claim 4, wherein when configuring N devices under test, i.e. 1 st device under test to N nth device under test, the declaration format of the variable in the parameter configuration file plus_aaa_ral is static bit [ width-1:0] block_name_reg_name_field_name [ M ] [ N ].
6. The method of claim 5, wherein the set_cfg () function in step S7 is declared as set_cfg (int inst_id), and if the parameter inst_id in the set_cfg (int inst_id) function is equal to n-1, the set function operates on the expected value of the register model as follows
block_name. Reg_name. Field_name. Set (plus_aaa_ral: the method comprises the steps of configuring a field field_name of a register reg_name of a module block_name in a parameter configuration file plus_aaa_ral to a corresponding field of a corresponding register of an n-th tested device corresponding module in a register model, wherein the value range of n is 0-N-1.
7. The method of claim 6, wherein when configuring N devices under test, i.e., 1 st device under test to N nth device under test, a set_cfg (N-1) function is called to configure the value assigned to each variable to the expected value of the register corresponding to each variable in the N-th device under test.
8. A method of configuring initial values of a register model as claimed in any one of claims 1 to 7, wherein the assignment of parameters of the same type is placed in a common parameter configuration file plus_aaa_ral, which can be parsed by different test cases.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311416850.5A CN117150987B (en) | 2023-10-30 | 2023-10-30 | Initial value configuration method for register model |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311416850.5A CN117150987B (en) | 2023-10-30 | 2023-10-30 | Initial value configuration method for register model |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN117150987A true CN117150987A (en) | 2023-12-01 |
| CN117150987B CN117150987B (en) | 2024-01-19 |
Family
ID=88899105
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311416850.5A Active CN117150987B (en) | 2023-10-30 | 2023-10-30 | Initial value configuration method for register model |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117150987B (en) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112131147A (en) * | 2020-09-21 | 2020-12-25 | 成都海光微电子技术有限公司 | Controller verification method, device and system, electronic equipment and storage medium |
| CN114841119A (en) * | 2022-05-11 | 2022-08-02 | 杭州云合智网技术有限公司 | Register modeling method, device, equipment and medium under multi-user mode |
| CN115017869A (en) * | 2022-06-24 | 2022-09-06 | 上海亿家芯集成电路设计有限公司 | UVM register model rapid generation method and system |
-
2023
- 2023-10-30 CN CN202311416850.5A patent/CN117150987B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112131147A (en) * | 2020-09-21 | 2020-12-25 | 成都海光微电子技术有限公司 | Controller verification method, device and system, electronic equipment and storage medium |
| CN114841119A (en) * | 2022-05-11 | 2022-08-02 | 杭州云合智网技术有限公司 | Register modeling method, device, equipment and medium under multi-user mode |
| CN115017869A (en) * | 2022-06-24 | 2022-09-06 | 上海亿家芯集成电路设计有限公司 | UVM register model rapid generation method and system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN117150987B (en) | 2024-01-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5995736A (en) | Method and system for automatically modelling registers for integrated circuit design | |
| US20110083114A1 (en) | Method and system for re-using digital assertions in a mixed signal design | |
| US20060271347A1 (en) | Method for generating commands for testing hardware device models | |
| CN109933521A (en) | Automated testing method, device, computer equipment and storage medium based on BDD | |
| JPS63145549A (en) | Simulation method for logic circuit | |
| CN114912391A (en) | Automatic generation method, device, equipment and medium of register design and verification model | |
| US6829731B1 (en) | Method and system for generating a design-specific test case from a generalized set of bus transactions | |
| CN114327476A (en) | Chip design file generation method and device and chip design method and device | |
| WO2001095160A2 (en) | Accessing state information in a hardware/software co-simulation | |
| CN102750401A (en) | System and method for generation of CIM-based power system circuit models | |
| CN107272441B (en) | Method for monitoring errors and data processing device for monitoring errors | |
| US20020072889A1 (en) | Efficient array tracing in a logic simulator machine | |
| CN111580409B (en) | Fault simulation test method for real-time embedded system | |
| CN117150987B (en) | Initial value configuration method for register model | |
| CN116227398A (en) | Method and system for automatically generating IP core test stimulus | |
| US6813751B2 (en) | Creating standard VHDL test environments | |
| US20030025490A1 (en) | Method for verifying hardware circuits through simulation | |
| CN112885403B (en) | Function test method, device and equipment of Flash controller | |
| CN111123084B (en) | TCL language-based digital circuit rapid test method | |
| CN116933699A (en) | Method, electronic device and storage medium for generating and storing waveform data in a circuit simulation process | |
| CN117312176B (en) | Chip verification test method and system based on UVM and electronic equipment | |
| CN116956789B (en) | Method, computing device and medium for accessing register back door | |
| US8225244B2 (en) | Large scale integration device and large scale integration design method including both a normal system and diagnostic system | |
| CN115510782B (en) | Method for locating verification errors, electronic device and storage medium | |
| CN116932412B (en) | Sharing platform and method capable of generating test excitation files with different formats |
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 |