CN113835757B - Method and device for sharing register model by multiple hosts and electronic equipment - Google Patents
Method and device for sharing register model by multiple hosts and electronic equipment Download PDFInfo
- Publication number
- CN113835757B CN113835757B CN202111154304.XA CN202111154304A CN113835757B CN 113835757 B CN113835757 B CN 113835757B CN 202111154304 A CN202111154304 A CN 202111154304A CN 113835757 B CN113835757 B CN 113835757B
- Authority
- CN
- China
- Prior art keywords
- register
- class
- sequence
- host interface
- sequencer
- 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.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30098—Register arrangements
-
- 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 embodiment of the application relates to the technical field of chip application and discloses a method, a device and electronic equipment for sharing a register model by multiple hosts, wherein the method for sharing the register model by the multiple hosts designates a corresponding sequencer for a sequence corresponding to each host interface through a custom register extension class; determining a converter of a system interface bus corresponding to each host interface, and designating each converter to a sequence corresponding to the host interface; when the sequence corresponding to each host interface accesses the register model, the object of the register expansion class is appointed, and the sequence corresponding to each host interface and the converter are determined so as to operate the register model.
Description
Technical Field
The present application relates to the field of chip application technologies, and in particular, to a method and an apparatus for sharing a register model by multiple hosts, and an electronic device.
Background
In digital chip logic verification, register verification is commonly implemented using the (Universal Verification Methodology, UVM) register model approach. In a verification environment, a register model generator script is utilized to output a register model file of a device under test (Device Under Test, DUT). The register model is then instantiated in the verification environment, specifying its converter (Adapter) and predictor at the same time. The converter is responsible for converting the operations resulting from the register model into a form acceptable to the Bus Agent and then driving it onto the DUT's interface. Meanwhile, the information obtained by a Monitor (Monitor) in the bus agent can be sent to a register Predictor (Predictor), and an internal converter is responsible for converting the fed-back information into a form acceptable by the register model, so as to realize the change of the mirror value of the register in the register model. Thereby realizing the characteristics of verifying the read-write and the like of all the registers in the DUT.
Currently, the register model generator typically generates a default register map (default_map) and sets a sequencer (sequencer) and translator (Adapter) for the bus agent for a single host to access the chip registers via the interface. In practical chip designs, there are cases where different hosts access the same register through different interfaces, so it is necessary to add a register mapping table, and it is common to add a register mapping table by modifying a script of a register model generator.
In the process of realizing the application, the inventor finds that the current technical scheme at least comprises the following technical problems: the register mapping table is added by modifying the script of the register model generator, which is complex in operation and easy to make mistakes, and the expansibility of the host interface is insufficient.
Disclosure of Invention
The embodiment of the application provides a method, a device and electronic equipment for sharing a register model by multiple hosts, which solve the technical problems that the operation is complex and error is easy to occur by adding a register mapping table at present, and the expansibility of a host interface is insufficient, so as to improve the expansibility of the host interface.
In order to solve the technical problems, the embodiment of the application provides the following technical scheme:
in a first aspect, an embodiment of the present application provides a method for sharing a register model by multiple hosts, including:
a custom register extension class, wherein the register extension class comprises a specified function, and the specified function is used for specifying a sequencer and a converter in the form of parameters when being called by a verification environment;
assigning a corresponding sequencer for the sequence corresponding to each host interface;
determining a converter of a system interface bus corresponding to each host interface, and designating each converter to a sequence corresponding to the host interface;
and when the sequence corresponding to each host interface accesses the register model, designating the object of the register extension class, and determining the sequence corresponding to each host interface and the converter so as to operate the register model.
In some embodiments, the assigning a corresponding sequencer to a sequence corresponding to each host interface includes:
determining a sequence base class;
deriving a sequence corresponding to each host interface according to the sequence base class;
and designating a sequencer corresponding to each host interface one by one according to the first task of the sequence base class.
In some embodiments, the designating a sequencer corresponding to a sequence of each host interface according to the first task of the sequence base class includes:
in a first task of the sequence base class, acquiring a sequencer pointer corresponding to the sequence base class;
and determining a sequence corresponding to each host interface one-to-one according to the sequence pointer.
In some embodiments, the determining the converter of the system interface bus corresponding to each host interface includes:
the translator of the system interface bus corresponding to each host interface is instantiated at the top level of the verification environment.
In some embodiments, the method further comprises:
a first register model mapping table is determined and replaced with the source register mapping table.
In some embodiments, the determining the first register model mapping table includes:
expanding from a UVM base class to obtain a first register mapping class;
rewriting a read task and a write task through the first register mapping class;
the member variables of the parameters of the read and write tasks are directed to the handles of the register extension class.
In some embodiments, when the register extension class is invoked, a register extension class object is generated to enable the setting of sequencers and converters in read and write tasks.
In some embodiments, each host sends a corresponding sequence that is sent by the sequencer to a corresponding driver that drives the sequence onto a corresponding bus interface.
In a second aspect, an embodiment of the present application provides an apparatus for sharing a register model by multiple hosts, including:
the register expansion class module is used for customizing the register expansion class, wherein the register expansion class comprises a designated function, and the designated function is used for designating the sequencer and the converter in the form of parameters when being called by the verification environment;
a sequencer module for assigning a corresponding sequencer to the sequence corresponding to each host interface;
a converter module, configured to determine a converter of a system interface bus corresponding to each host interface, and assign each converter to a sequence corresponding to the host interface;
and the register model module is used for designating the object of the register expansion class when the sequence corresponding to each host interface accesses the register model, and determining the sequence and the converter corresponding to each host interface so as to operate the register model.
In a third aspect, an embodiment of the present application provides an electronic device, including:
At least one processor; and
a memory communicatively coupled to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of the multi-host shared register model of the first aspect.
In a fourth aspect, embodiments of the present application also provide a non-transitory computer-readable storage medium storing computer-executable instructions for enabling an electronic device to perform a method of a multi-host shared register model according to the first aspect.
The embodiment of the application has the beneficial effects that: in contrast to the prior art, the method for sharing the register model by multiple hosts provided by the embodiment of the application comprises the following steps: a custom register extension class, wherein the register extension class comprises a specified function, and the specified function is used for specifying a sequencer and a converter in the form of parameters when being called by a verification environment; assigning a corresponding sequencer for the sequence corresponding to each host interface; determining a converter of a system interface bus corresponding to each host interface, and designating each converter to a sequence corresponding to the host interface; and when the sequence corresponding to each host interface accesses the register model, designating the object of the register extension class, and determining the sequence corresponding to each host interface and the converter so as to operate the register model. Designating a corresponding sequencer for a sequence corresponding to each host interface through a custom register extension class; determining a converter of a system interface bus corresponding to each host interface, and designating each converter to a sequence corresponding to the host interface; when the sequence corresponding to each host interface accesses the register model, the object of the register expansion class is appointed, and the sequence corresponding to each host interface and the converter are determined so as to operate the register model.
Drawings
One or more embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements, and in which the figures of the drawings are not to be taken in a limiting sense, unless otherwise indicated.
FIG. 1 is a schematic diagram of a register model according to an embodiment of the present application;
FIG. 2 is a schematic diagram of a multi-host access system according to an embodiment of the present application;
FIG. 3 is a schematic diagram of a register mapping table of multiple hosts according to an embodiment of the present application;
FIG. 4 is a flow chart of a method for sharing a register model by multiple hosts according to an embodiment of the present application;
fig. 5 is a detailed flowchart of step S42 in fig. 4;
FIG. 6 is a flowchart illustrating a method for determining a first register model mapping table according to an embodiment of the present application;
FIG. 7 is a schematic diagram of a verification environment and a device under test according to an embodiment of the present application;
FIG. 8 is a schematic diagram of a multi-host shared register model according to an embodiment of the present application;
FIG. 9 is a schematic diagram of a register access provided by an embodiment of the present application;
FIG. 10 is a schematic diagram of an apparatus for sharing a register model with multiple hosts according to an embodiment of the present application;
fig. 11 is a schematic structural diagram of an electronic device according to an embodiment of the present application.
Detailed Description
For the purpose of making the objects, technical solutions and advantages of the embodiments of the present application more apparent, the technical solutions of the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application, and it is apparent that the described embodiments are some embodiments of the present application, but not all embodiments of the present application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.
In addition, the technical features of the embodiments of the present application described below may be combined with each other as long as they do not collide with each other.
The adoption of verification methodologies is one of the trends in chip verification, and unified verification methodologies (Universal Verification Methodology, UVM) are typical representatives thereof. The most important multiplexing unit in the UVM architecture is a bus Agent (Agent), and a verifier generates a transaction-level packet (transaction) by writing a Sequence (Sequence) in a sequencer (sequencer), and converts the transaction-level packet into an interface excitation signal to act on a bus interface through a Driver (Driver), and meanwhile, a Monitor (Monitor) collects the bus signal, converts the bus signal into the transaction-level packet, and sends the transaction-level packet to a scoreboard (scoreboard) for automatic comparison. UVM provides a basic verification architecture, and basic multiplexing and automatic verification are realized.
The technical scheme of the application is specifically described below with reference to the accompanying drawings of the specification:
referring to fig. 1, fig. 1 is a schematic structural diagram of a register model according to an embodiment of the present application;
as shown in fig. 1, the register a and the register B in the device under test (Device Under Test, DUT) are driven and monitored by a verification Environment (ENV) through a register model.
It will be appreciated that the verification environment ENV is a set of codes constructed to logically verify the device under test ENV, which codes have the functions of test stimulus input, output result detection, etc.
The register model is used for establishing the mapping of the DUT register of the tested design in the verification platform, and the security check manager can map to the operation of the DUT register by calling the internal method of the register model to operate the register model so as to realize the access and verification of the register;
the register model is a chip register model built using VMM-based register abstraction layer (Register Abstraction Layer, RAL) verification techniques and schemes. Because more register configuration and reading are involved in the security check verification test process, the register is modeled by using RAL, and the operation of the verification environment on the register model can be mapped to the operation on the DUT register, which is much simpler and more intuitive than directly sending the AHB bus operation to access the DUT register. On one hand, the access and verification of the register can be simply, conveniently and efficiently completed; on the other hand, the method is beneficial to improving the building speed of the verification environment platform and improving the readability of the verification environment codes. The register model may translate the RAL operation of the security manager to access the registers into an AHB transaction, and pass the AHB transaction through the channel to the AHB host verification model, which in turn translates into a signal capable of driving the AHB bus.
In the verification environment ENV, a register model file of the device under test DUT is output by a register model generator script. The register model is then instantiated in the verification environment, specifying its converter (Adapter) and predictor at the same time. The converter is responsible for converting the operations resulting from the register model into a form acceptable to the Bus Agent and then driving it onto the DUT's interface. Meanwhile, the information obtained by a Monitor (Monitor) in the bus agent can be sent to a register Predictor (Predictor), and an internal converter is responsible for converting the fed-back information into a form acceptable by the register model, so as to realize the change of the mirror value of the register in the register model. Thereby realizing the characteristics of verifying the read-write and the like of all the registers in the DUT.
Typically, the register model generator generates a default register map (default_map) and sets a sequencer (sequencer) and translator (Adapter) for the bus agent for a single host to access the chip registers via the interface.
For complex digital chips, it is common for different hosts to access registers inside the chip in order to achieve multiple selectivities for functional control in the design. The fact that the sequencers (sequencers) and converters (adapters) of different hosts are different results in that the default register mapping table cannot be normally used in this scenario.
Referring to fig. 2 again, fig. 2 is a schematic structural diagram of a multi-host access system according to an embodiment of the present application;
as shown in fig. 2, different hosts access the internal registers of the DUT via different interfaces, for example: host 1 is accessed through interface 1, host 2 is accessed through interface 2, and host 3 is accessed through interface 3 to fulfill the functional requirements of the host. Assuming that host 1 can access registers A, B, C via interface 1, host 2 can access registers a and B via interface 2, and not register C, host 3 can access registers a and C via interface 3, and not register B. Then normal use of the register model cannot be achieved for these three hosts if there is only one register map (default_map).
Referring to fig. 3 again, fig. 3 is a schematic diagram of a register mapping table of multiple hosts according to an embodiment of the present application;
as shown in fig. 3, in the register block, a register mapping table is respectively corresponding to each interface, for example: the interface 1 corresponds to the register mapping table 1, the interface 2 corresponds to the register mapping table 2, the interface 3 corresponds to the register mapping table 3, and then the accessible registers are loaded into the register mapping table. For example, when the host 2 initiates a write request to the register B, the address corresponding to the register B is first searched through the register mapping table 2, and then the address is driven onto the interface 2, so as to implement a write operation to the register B.
However, for complex digital chips, it is common for different hosts to access registers inside the chip in order to achieve multiple selectivities for functional control in the design. The fact that the sequencers (sequencers) and converters (adapters) of different hosts are different results in that the register mapping table cannot be used normally in this scenario.
And, the register map is manually added. However, for complex chips, the number of registers is very large, the error probability is very high, and the workload is large; the register map is added by modifying the register model generator script. The script is difficult, the workload of preparing script input files in the early stage is relatively more, and the verification codes of other modules can be in conflict, so that a large number of codes are reconstructed. Meanwhile, the mode of adding the register mapping table is not easy to expand, and the flexibility is low. In the process of developing a chip, the host is added or deleted, and in this case, the register model needs to be modified more, so that the problem of rapid convergence cannot be solved.
Based on the above, the application provides a method for sharing a register model by multiple hosts, which aims to achieve the purpose of considering future expansion modification of a chip system bus under the condition of not modifying the original register model generator script and the register model file when the multiple hosts access the register of a device DUT to be tested, so as to improve the expansibility of a host interface.
Since the sequencer and translator need to be formulated for register operation in the unified verification methodology (Universal Verification Methodology, UVM) verification environment, and the sequencers and translator of different hosts are different, the present application implements a multi-host shared register model by way of the verification environment top-level dispatch and switch sequencers (sequencers) and translators (adapters).
Specifically, referring to fig. 4, fig. 4 is a flow chart of a method for sharing a register model by multiple hosts according to an embodiment of the present application;
as shown in fig. 4, the method for sharing a register model by multiple hosts includes:
step S41: a custom register extension class, wherein the register extension class comprises a specified function, and the specified function is used for specifying a sequencer and a converter in the form of parameters when being called by a verification environment;
specifically, a custom class named register_extension is derived from the UVM base class UVM _object. A designation function is set in the register extension class, and is responsible for designating the sequencer and the translator when called by the Environment (ENV) through the form of parameters. Wherein the sequencer and expander are declared in the register extension class, while external sequencers and converters are passed into the object of the register extension class by a specified function, for example: the specified function is a set_register_configuration function for passing external sequencers and translators into the objects of the register extension class.
Step S42: assigning a corresponding sequencer for the sequence corresponding to each host interface;
specifically, referring to fig. 5 again, fig. 5 is a detailed flowchart of step S42 in fig. 4;
as shown in fig. 5, this step S42: assigning a corresponding sequencer to the sequence corresponding to each host interface, comprising:
step S421: determining a sequence base class;
specifically, a sequence base class is customized, for example: a custom class with a sequence name of bus_base_sequence is written, the sequence base class is used as a base class of a subsequent derivative sequence, and the register expansion class, namely a register_extension class, is instantiated in the sequence base class, which is equivalent to generating an object for the register_extension class.
Step S422: deriving a sequence corresponding to each host interface according to the sequence base class;
specifically, based on the sequence base class, a sequence corresponding to each host interface is derived, for example: derived sequence 1 and sequence 2, while host interface 1 corresponds to sequence 1 and host interface 2 corresponds to sequence 2.
Step S423: according to the first task of the sequence base class, designating a sequence corresponding to each host interface to be a one-to-one corresponding sequencer;
specifically, in the first task of the sequence base class, a sequencer (sequencer) corresponding to each host interface one-to-one is designated, that is, any sequence derived from the sequence base class (bus_base_sequence), after the corresponding sequencer is set in use, the sequencer is transferred into the register model, so that different scenes can freely switch sequencers, wherein different scenes comprise different sequences sent by different hosts. The first task comprises a Pre-start task, which is a callback task in UVM methodology and is used for a code writer to add own settings before starting to start a certain incentive.
It will be appreciated that the sequencer (sequencer) is the flow control responsible for requests and responses of transactions between sequences and drivers, and is an integral component of the UVM methodology verification platform. Each host, in order to send its own sequence, must be controlled for transmission by the sequencer and ultimately sent to the driver, which drives the sequence onto the bus interface. For example, to send the sequence of write data to register a, a sequencer is required to send the sequence to the drive.
Specifically, the designating a sequencer corresponding to a sequence corresponding to each host interface according to the first task of the sequence base class includes:
in a first task of the sequence base class, acquiring a sequencer pointer corresponding to the sequence base class;
and determining a sequence corresponding to each host interface one-to-one according to the sequence pointer.
For example: in the first task of the sequence base class, a sequencer pointer p_sequencer corresponding to the sequence base class is obtained, and a sequencer corresponding to each host interface one-to-one is determined according to the sequencer pointer p_sequencer, for example: and according to the sequencer pointer p_sequencer, designating a sequencer corresponding to the sequence A as a sequencer A, designating a sequencer corresponding to the sequence B as a sequencer B, and designating a sequencer corresponding to the sequence C as a sequencer C.
It will be appreciated that each host transmits a corresponding sequence, which must be transmitted by the sequencer for control, ultimately to the driver, which drives the sequence onto the bus interface.
Step S43: determining a converter of a system interface bus corresponding to each host interface, and designating each converter to a sequence corresponding to the host interface;
specifically, each host interface corresponds to a converter, and the converter is specified to a specific sequence, that is, to a sequence corresponding to the host interface, by instantiating the converter of the system interface bus corresponding to each host interface at the top layer of the verification environment, and by means of a configuration class function, for example: the class function is uvm db config# (T): set (), the converter is obtained from outside by configuring the class function uvm db config# (T): get () in the first task (pre_start) of the sequence base class (bus_base_sequence).
Wherein the converter (Adapter) is configured to implement a bridge of the register model and the bus interface, for example:
the first, register sequence will store the relevant information with the destination register in the UVM class UVM _reg_item instance, which is sent to the converter.
Second, upon receiving the uvm _reg_item instance, the translator extracts the information required by the bus control component therefrom, and generates the type of sequential transaction (bus_seq_item) required by the bus control component. The final translator directs the sequential transactions to the bus control component.
And thirdly, the bus control component acquires information such as addresses, data, operation modes and the like from a sequence transaction (bus_seq_item) and then initiates read-write access of the bus.
In an embodiment of the present application, the method further includes:
a first register model mapping table is determined and replaced with the source register mapping table.
Specifically, in the test case, a function set_type_override () of a factory (factory) mechanism of UVM is adopted, and the source register mapping table (UVM _reg_map) is replaced by a first register model mapping table (my_reg_map), wherein the first register model mapping table is a custom register mapping table, which is equivalent to replacing the source register mapping file with the custom register mapping file. It is understood that the first register model mapping table is a mapping table derived based on a source register mapping table extension.
Specifically, referring to fig. 6 again, fig. 6 is a schematic flow chart of determining a first register model mapping table according to an embodiment of the present application;
as shown in fig. 6, the determining the first register model mapping table includes:
step S601: expanding from a UVM base class to obtain a first register mapping class;
Specifically, the UVM base class is a register map class, for example: the UVM base class is a UVM _reg_map class in a UVM architecture, and is configured to specify offset addresses, access attributes, and corresponding buses of each register in a register list, where the first register map class is a map class obtained after expanding the UVM base class, for example: the extension results in a custom register map class, such as: and a my_reg_map class.
Step S602: rewriting a read task and a write task through the first register mapping class;
specifically, based on the first register mapping class, the first task body and the second task body corresponding to the read task and the write task of the task bus are rewritten, for example: the bus write task (do_bus_write) and the bus read task (do_bus_read) in the first register map class (my_reg_map) are rewritten. It is understood that overwriting refers to modifying the content of a function or task, while the name of the function or task is unchanged, and when automatically invoked, the function or task after the content is modified is executed to achieve the effect of modification.
For example: and (3) rewriting the read task and the write task, and assigning extension parameters (comprising sequencers and converters) which are input when the external register is accessed to the sequencers and converters in the register mapping table. Different parameters correspond to different hosts, and access of the different hosts to the register is realized.
Step S603: the member variables of the parameters of the read and write tasks are directed to the handles of the register extension class.
Specifically, the first register map class (my_reg_map) is extended from the UVM base class (UVM _reg_map). The bus write task (do_bus_write) and the bus read task (do_bus_read) are rewritten in the first register map class, and extension member variables in parameters uvm _reg_item of the bus write task and the bus write task are pointed to handles of the register_extension class (register_extension).
Specifically, when the register extension class is called, a register extension class object is generated to realize the setting of sequencers and converters in the read task and the write task.
For example: when called, the setting of sequencers and converters in the bus write task (do_bus_write) and bus read task (do_bus_read) may be accomplished by specifying the objects of a particular register extension class (register_extension).
Step S44: and when the sequence corresponding to each host interface accesses the register model, designating the object of the register extension class, and determining the sequence corresponding to each host interface and the converter so as to operate the register model.
Specifically, when the register model is accessed in a specific sequence, the register model acquires the sequencer and the converter by designating the object of the register extension class, namely instantiating the register extension class, and designating extension parameters as the form of the extension class instantiated in each sequence, so as to operate the register model. At register access, extension parameters are specified. Through the extension parameter, sequencers and converters in different hosts can be assigned to a register mapping table, so that the access of different hosts to registers is realized.
It will be appreciated that invoking the register model requires formulating a sequencer and a translator, while sequencers and translators of different hosts are different, by placing the translator's designation in the derived specific sequence (sequence) after instantiating the system interface bus at the top level of the verification environment, thereby implementing the multi-host shared register model.
In an embodiment of the present application, the system interface bus is an interface bus that can access registers, including but not limited to: one or more of AXI bus, AHB bus, APB bus, GPIO bus.
Referring to fig. 7 again, fig. 7 is a schematic diagram of a verification environment and a device under test according to an embodiment of the present application;
as shown in fig. 7, the host 1, the host 2, and the host 3 drive different interfaces to perform register configuration, where the host 1 corresponds to the interface 1, the host 2 corresponds to the interface 2, and the host 3 corresponds to the interface 3.
The operation of the host to register is described below in conjunction with fig. 7:
assuming that host 2 and host 3 write register a of a Device Under Test (DUT), interface 2 is an AXI bus and interface 3 is an AHB bus.
The first step is to obtain the sequencer. In the verification environment, sequence 2 is designated as the default sequence (default_sequence) of the AXI bus sequencer, and sequence 3 is designated as the default sequence of the AHB bus sequencer, so that the sequence base class obtains the sequencer pointer, and sequence 2 and sequence 3 extended from the base class obtain the respective sequencers.
The second step is to acquire the converter. The converters of the AXI bus and the AHB bus are instantiated at the top level of the verification environment, respectively, and assigned into sequence 2 and sequence 3.
While in the sequence base class a register extension class (register extension) has been declared and the obtained sequencer and translator are assigned to the object of the instantiated register extension class (register extension). I.e. the sequencer and converter of the AXI bus is obtained in sequence 2 and the sequencer and converter of the AHB bus is obtained in sequence 3. The access to register a may be completed by performing register model write operations in sequence 2 and sequence 3.
For example: and performing write operation on the register A through a register model. The register a is written hexadecimal 1234 in the sequence, while the register_extension parameter is entered, at which time the register_extension has been assigned to the sequencer and translator of the AXI or AHB bus, i.e., the sequencer and translator of the AXI or AHB bus.
In the embodiment of the present application, the sequencer and expander are declared in the register extension class (register_extension), while external sequencers and converters are passed into the objects of the register extension class through a specified function, for example: external sequencers and translators are passed into the objects of the register extension class through the set_register_configuration function.
Referring to fig. 8 again, fig. 8 is a schematic diagram of an architecture of a multi-host shared register model according to an embodiment of the present application;
as shown in fig. 8, bridging of the register model and the bus interface is achieved by means of a converter (Adapter). It can be seen that if the chip design needs to expand or delete the host, there is no influence on the original register model, and the top layer of the verification environment can be compatible with the previously developed test cases with only small changes, and the development of the subsequent test cases is not influenced, so that the expansibility of the host is improved.
In the embodiment of the application, each host sends a corresponding sequence to a corresponding driver through a sequencer, and the driver drives the sequence to a corresponding bus interface. Specifically, the sequencer (sequencer) is the flow control responsible for requests and responses of transactions between the sequencer and the driver, which drives the sequencer onto the bus interface, for example: as shown in fig. 8, when the host sends a sequence 1 of write data to register a, the sequence 1 is sent to the driver 1 by the corresponding sequencer 1, and the sequence 1 is driven onto the interface 1 by the driver 1.
Referring to fig. 9, fig. 9 is a schematic diagram illustrating a register access according to an embodiment of the present application;
As shown in fig. 9, the process of accessing the register includes:
a self-defining register model mapping table, namely a first register mapping table is generated;
rewriting task and rewriting read task, namely rewriting bus write task and bus read task;
the source register mapping table is replaced by the self-defined first register mapping table;
custom register extension class (register_extension);
acquiring a sequence corresponding to a host interface, for example: sequence a, sequence B, … …, sequence N;
instantiating a register extension class (register_extension) to obtain an object of the register extension class, for example: register_extension a, register_extension b, … …, register_extension n;
a sequencer is specified for each register extension class object, for example: a sequencer a is specified for register_extension a, a sequencer B is specified for register_extension B, … …, and a sequencer N is specified for register_extension N;
a translator is specified for the object of each register extension class, for example: designating a converter a for register_extension a, designating a converter B for register_extension B, … …, designating a converter N for register_extension N;
and designating the object of the register extension class to realize register access.
In an embodiment of the present application, a method for sharing a register model by multiple hosts is provided, including: a custom register extension class, wherein the register extension class comprises a specified function, and the specified function is used for specifying a sequencer and a converter in the form of parameters when being called by a verification environment; assigning a corresponding sequencer for the sequence corresponding to each host interface; determining a converter of a system interface bus corresponding to each host interface, and designating each converter to a sequence corresponding to the host interface; and when the sequence corresponding to each host interface accesses the register model, designating the object of the register extension class, and determining the sequence corresponding to each host interface and the converter so as to operate the register model. Designating a corresponding sequencer for a sequence corresponding to each host interface through a custom register extension class; determining a converter of a system interface bus corresponding to each host interface, and designating each converter to a sequence corresponding to the host interface; when the sequence corresponding to each host interface accesses the register model, the object of the register expansion class is designated, and the sequence and the converter corresponding to each host interface are determined to operate the register model.
Referring to fig. 10, fig. 10 is a schematic structural diagram of an apparatus for sharing a register model with multiple hosts according to an embodiment of the present application;
as shown in fig. 10, the apparatus 100 for multi-host shared register model includes:
a register extension class module 101, configured to customize a register extension class, where the register extension class includes a specified function, where the specified function is used to specify a sequencer and a converter in a parameter form when called by a verification environment;
a sequencer module 102, configured to assign a corresponding sequencer to a sequence corresponding to each host interface;
a converter module 103, configured to determine a converter of the system interface bus corresponding to each host interface, and assign each converter to a sequence corresponding to the host interface;
the register model module 104 is configured to specify an object of the register extension class when the sequence corresponding to each host interface accesses the register model, and determine a sequencer and a translator corresponding to each host interface to operate on the register model.
It should be noted that, the device for sharing the register model by multiple hosts described above may execute the method for sharing the register model by multiple hosts provided by the embodiment of the present application, and has the corresponding functional modules and beneficial effects of the execution method. For technical details not described in detail in the device embodiments, reference may be made to the method for sharing a register model by multiple hosts provided in the embodiments of the present application.
In an embodiment of the present application, an apparatus for sharing a register model by multiple hosts is provided, including: the register expansion class module is used for customizing the register expansion class, wherein the register expansion class comprises a designated function, and the designated function is used for designating the sequencer and the converter in the form of parameters when being called by the verification environment; a sequencer module for assigning a corresponding sequencer to the sequence corresponding to each host interface; a converter module, configured to determine a converter of a system interface bus corresponding to each host interface, and assign each converter to a sequence corresponding to the host interface; and the register model module is used for designating the object of the register expansion class when the sequence corresponding to each host interface accesses the register model, and determining the sequence and the converter corresponding to each host interface so as to operate the register model. Designating a corresponding sequencer for a sequence corresponding to each host interface through a custom register extension class; determining a converter of a system interface bus corresponding to each host interface, and designating each converter to a sequence corresponding to the host interface; when the sequence corresponding to each host interface accesses the register model, the object of the register expansion class is appointed, and the sequence corresponding to each host interface and the converter are determined so as to operate the register model.
Referring to fig. 11, fig. 11 is a schematic structural diagram of an electronic device according to an embodiment of the present application;
as shown in fig. 11, the electronic device 110 includes one or more processors 111 and a memory 112. In fig. 11, a processor 111 is taken as an example.
The processor 111 and the memory 112 may be connected by a bus or otherwise, which is illustrated in fig. 11 as a bus connection.
The memory 112 is used as a non-volatile computer readable storage medium for storing non-volatile software programs, non-volatile computer executable programs, and modules, such as elements (e.g., the various modules or elements described in fig. 10) corresponding to a method for sharing a register model with multiple hosts in embodiments of the present application. The processor 111 performs various functional applications and data processing of the method of the multi-host shared register model by running non-volatile software programs, instructions and modules stored in the memory 112, i.e., functions of the various modules and units implementing the method embodiments described above and the apparatus embodiments described above. The method for sharing the register model by multiple hosts can be executed by various electronic devices with certain logic processing capability, such as a control chip and the like.
Memory 112 may include high-speed random access memory and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, memory 112 may optionally include memory located remotely from processor 111, such remote memory being connectable to processor 111 through a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.
The modules are stored in the memory 112 and when executed by the one or more processors 111 perform a method of the multi-host shared register model in any of the method embodiments described above, comprising: a custom register extension class, wherein the register extension class comprises a specified function, and the specified function is used for specifying a sequencer and a converter in the form of parameters when being called by a verification environment; assigning a corresponding sequencer for the sequence corresponding to each host interface; determining a converter of a system interface bus corresponding to each host interface, and designating each converter to a sequence corresponding to the host interface; and when the sequence corresponding to each host interface accesses the register model, designating the object of the register extension class, and determining the sequence corresponding to each host interface and the converter so as to operate the register model.
In the embodiment of the application, a corresponding sequencer is designated for a sequence corresponding to each host interface through a custom register extension class; determining a converter of a system interface bus corresponding to each host interface, and designating each converter to a sequence corresponding to the host interface; when the sequence corresponding to each host interface accesses the register model, the object of the register expansion class is appointed, and the sequence corresponding to each host interface and the converter are determined so as to operate the register model.
Embodiments of the present application also provide a non-volatile computer storage medium storing computer-executable instructions for execution by one or more processors, such as the method of the multi-host shared memory model in any of the method embodiments described above, e.g., performing the steps described in the method above.
The above-described embodiments of the apparatus or device are merely illustrative, in which the unit modules illustrated as separate components may or may not be physically separate, and the components shown as unit modules may or may not be physical units, may be located in one place, or may be distributed over multiple network module units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
From the above description of embodiments, it will be apparent to those skilled in the art that the embodiments may be implemented by means of software plus a general purpose hardware platform, or may be implemented by hardware. Based on such understanding, the foregoing technical solution may be embodied essentially or in a part contributing to the related art in the form of a software product, which may be stored in a computer readable storage medium, such as ROM/RAM, a magnetic disk, an optical disk, etc., including several instructions for up to a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method described in the respective embodiments or some parts of the embodiments.
Finally, it should be noted that: the above embodiments are only for illustrating the technical solution of the present application, and are not limiting; the technical features of the above embodiments or in the different embodiments may also be combined within the idea of the application, the steps may be implemented in any order, and there are many other variations of the different aspects of the application as described above, which are not provided in detail for the sake of brevity; although the application has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit of the application.
Claims (7)
1. A method for sharing a register model by multiple hosts, comprising:
a custom register extension class, wherein the register extension class comprises a specified function, and the specified function is used for specifying a sequencer and a converter in the form of parameters when being called by a verification environment;
assigning a corresponding sequencer for the sequence corresponding to each host interface;
determining a converter of a system interface bus corresponding to each host interface, and designating each converter to a sequence corresponding to the host interface;
when the sequence corresponding to each host interface accesses the register model, designating the object of the register extension class, and determining the sequence corresponding to each host interface and the converter so as to operate the register model;
the method further comprises the steps of:
determining a first register model mapping table, and replacing the source register mapping table with the first register model mapping table;
the determining the first register model mapping table includes:
expanding from a UVM base class to obtain a first register mapping class;
rewriting a read task and a write task through the first register mapping class;
the member variables of the parameters of the read task and the write task are directed to the handles of the register extension class;
When the register extension class is called, a register extension class object is generated to realize the setting of sequencers and converters in the read task and the write task.
2. The method of claim 1, wherein the assigning a corresponding sequencer for each host interface corresponding sequence comprises:
determining a sequence base class;
deriving a sequence corresponding to each host interface according to the sequence base class;
and designating a sequencer corresponding to each host interface one by one according to a first task of the sequence base class, wherein the first task comprises a Pre-start task, and the Pre-start task is a callbacks task in UVM (UVM) methodology.
3. The method according to claim 2, wherein the assigning a sequencer for each host interface to a sequence one-to-one correspondence according to the first task of the sequence base class comprises:
in a first task of the sequence base class, acquiring a sequencer pointer corresponding to the sequence base class;
and determining a sequence corresponding to each host interface one-to-one according to the sequence pointer.
4. The method of claim 1, wherein determining the switch of the system interface bus corresponding to each host interface comprises:
The translator of the system interface bus corresponding to each host interface is instantiated at the top level of the verification environment.
5. A method according to any one of claims 1-4, wherein each host transmits a corresponding sequence, which is transmitted by the sequencer to a corresponding driver, which drives the sequence onto a corresponding bus interface.
6. An apparatus for sharing a register model with multiple hosts, comprising:
the register expansion class module is used for customizing the register expansion class, wherein the register expansion class comprises a designated function, and the designated function is used for designating the sequencer and the converter in the form of parameters when being called by the verification environment;
a sequencer module for assigning a corresponding sequencer to the sequence corresponding to each host interface;
a converter module, configured to determine a converter of a system interface bus corresponding to each host interface, and assign each converter to a sequence corresponding to the host interface;
the register model module is used for designating the object of the register expansion class when the sequence corresponding to each host interface accesses the register model, and determining the sequence corresponding to each host interface and the converter so as to operate the register model;
The register extension class module is further configured to:
determining a first register model mapping table, and replacing the source register mapping table with the first register model mapping table;
the determining the first register model mapping table includes:
expanding from a UVM base class to obtain a first register mapping class;
rewriting a read task and a write task through the first register mapping class;
the member variables of the parameters of the read task and the write task are directed to the handles of the register extension class;
when the register extension class is called, a register extension class object is generated to realize the setting of sequencers and converters in the read task and the write task.
7. An electronic device, comprising:
at least one processor; and
a memory communicatively coupled to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of the multi-host shared register model of any one of claims 1-5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111154304.XA CN113835757B (en) | 2021-09-29 | 2021-09-29 | Method and device for sharing register model by multiple hosts and electronic equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111154304.XA CN113835757B (en) | 2021-09-29 | 2021-09-29 | Method and device for sharing register model by multiple hosts and electronic equipment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113835757A CN113835757A (en) | 2021-12-24 |
| CN113835757B true CN113835757B (en) | 2023-08-15 |
Family
ID=78967584
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111154304.XA Active CN113835757B (en) | 2021-09-29 | 2021-09-29 | Method and device for sharing register model by multiple hosts and electronic equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113835757B (en) |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5140687A (en) * | 1985-10-22 | 1992-08-18 | Texas Instruments Incorporated | Data processing apparatus with self-emulation capability |
| DE102009019442A1 (en) * | 2009-02-25 | 2010-09-23 | Siemens Aktiengesellschaft | Method for automatic generation of test data, involves providing object model, which forms technical framework for statistical modification of test data, and reading sequential input-test data flow |
| CN105190561A (en) * | 2013-03-13 | 2015-12-23 | 高通股份有限公司 | Dual host embedded shared device controller |
| CN109684681A (en) * | 2018-12-06 | 2019-04-26 | 西南电子技术研究所（中国电子科技集团公司第十研究所） | Using the high layering verification method of UVM verification platform |
| CN112131829A (en) * | 2020-09-18 | 2020-12-25 | 山东云海国创云计算装备产业创新中心有限公司 | Verification method, system and related device of chip register |
| CN112286746A (en) * | 2020-10-31 | 2021-01-29 | 拓维电子科技(上海)有限公司 | Universal verification platform and method for AXI slave device interface |
| CN112417797A (en) * | 2020-11-27 | 2021-02-26 | 海光信息技术股份有限公司 | Register configuration synchronization method, verification platform system, configuration method and configuration device |
| CN113076227A (en) * | 2021-04-28 | 2021-07-06 | 深圳市汇春科技股份有限公司 | MCU verification method, system and terminal equipment |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10108417B2 (en) * | 2015-08-14 | 2018-10-23 | Qualcomm Incorporated | Storing narrow produced values for instruction operands directly in a register map in an out-of-order processor |
-
2021
- 2021-09-29 CN CN202111154304.XA patent/CN113835757B/en active Active
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5140687A (en) * | 1985-10-22 | 1992-08-18 | Texas Instruments Incorporated | Data processing apparatus with self-emulation capability |
| DE102009019442A1 (en) * | 2009-02-25 | 2010-09-23 | Siemens Aktiengesellschaft | Method for automatic generation of test data, involves providing object model, which forms technical framework for statistical modification of test data, and reading sequential input-test data flow |
| CN105190561A (en) * | 2013-03-13 | 2015-12-23 | 高通股份有限公司 | Dual host embedded shared device controller |
| CN109684681A (en) * | 2018-12-06 | 2019-04-26 | 西南电子技术研究所（中国电子科技集团公司第十研究所） | Using the high layering verification method of UVM verification platform |
| CN112131829A (en) * | 2020-09-18 | 2020-12-25 | 山东云海国创云计算装备产业创新中心有限公司 | Verification method, system and related device of chip register |
| CN112286746A (en) * | 2020-10-31 | 2021-01-29 | 拓维电子科技(上海)有限公司 | Universal verification platform and method for AXI slave device interface |
| CN112417797A (en) * | 2020-11-27 | 2021-02-26 | 海光信息技术股份有限公司 | Register configuration synchronization method, verification platform system, configuration method and configuration device |
| CN113076227A (en) * | 2021-04-28 | 2021-07-06 | 深圳市汇春科技股份有限公司 | MCU verification method, system and terminal equipment |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113835757A (en) | 2021-12-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR102428317B1 (en) | A novel ssd architecture for fpga based acceleration | |
| US20090276775A1 (en) | PCI Function South-Side Data Management | |
| CN113904938B (en) | System and method for dynamically configuring PCIe terminal equipment | |
| CN112131829A (en) | Verification method, system and related device of chip register | |
| US9720703B2 (en) | Data driven hardware chips initialization via hardware procedure framework | |
| US20070055911A1 (en) | A Method and System for Automatically Generating a Test-Case | |
| JP4157771B2 (en) | Method and system for efficient access to remote I / O functions in an embedded control environment | |
| CN108804313B (en) | Method and device for remotely debugging program and server | |
| US20220358270A1 (en) | Chip verification system and verification method therefor | |
| US5968174A (en) | Method and apparatus for implementing a 32-bit operating system which supports 16-bit code | |
| CN114153779A (en) | I2C communication method, system, equipment and storage medium | |
| CN111858296A (en) | Interface test method, device, equipment and storage medium | |
| CN115827502A (en) | Memory access system, method and medium | |
| US10496422B2 (en) | Serial device emulator using two memory levels with dynamic and configurable response | |
| US20240126567A1 (en) | Data processing system, method, and apparatus | |
| CN113835757B (en) | Method and device for sharing register model by multiple hosts and electronic equipment | |
| CN111857839B (en) | Linux-based PXI/PXIe bus device driving system | |
| CN110765060A (en) | Method, device, equipment and medium for converting MDIO bus into parallel bus | |
| US7519719B2 (en) | Automatic creation of protocol dependent control path for instrument application | |
| CN110327626B (en) | Virtual server creation method and device | |
| US6636964B1 (en) | Method and apparatus for loading an object-oriented operating system by providing an initial execution environment and migrating to a core execution environment thereafter | |
| CN116627496B (en) | UVM-based register model construction and verification method, system and electronic equipment | |
| CN115081366B (en) | Modeling method for sudden access of register | |
| CN114461296B (en) | Openresty-based service platform development and access method | |
| CN117251118B (en) | Virtual NVMe simulation and integration supporting method and system |
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 |