Units vs. Structs
The decision of whether to model a DUT component with a unit or a struct often depends on your verification strategy. Compelling reasons for using a unit instead of a struct include:
- You intend to test the DUT component both standalone and integrated into a larger system. Modeling the DUT component with a unit instead of a struct allows you to use relative path names when referencing HDL objects. When you integrate the component with the rest of the design, you simply change the HDL path associated with the unit instance and all the HDL references it contains are updated to reflect the component s new position in the design hierarchy. This methodology eliminates the need for computed HDL names (for example, (path_str).sig ), which impact runtime performance.
- Your e program has methods that access many signals at runtime. The correctness of all signal references within units are determined and checked during pre-run generation. If your e program does not contain user units, the absolute HDL references within structs are also checked during pre-run generation. However, if your e program does contain user units, the relative HDL references within structs are checked at run time. In this case, using units rather than structs can enhance runtime performance.
On the other hand, using a struct to model abstract collections of data, like packets, allows you more flexibility as to when you generate the data. With structs, you can generate the data either during pre-run generation, at runtime, or on the fly, possibly in response to conditions in the DUT. Unit instances, however, can only be generated during pre-run generation, because each unit instance has a unique and constant place (an e path) in the runtime data structure of an e program, just as an HDL component instance has a constant place in the DUT hierarchical tree.Thus you cannot modify the unit tree by generating unit instances on the fly.
Any allocated struct instance automatically establishes a reference to its parent unit. If this struct is a generated during pre-run generation it inherits the parent unit of its parent struct. If the struct is dynamically allocated by the new or gen action, then the parent unit is inherited from the struct belonging to the enclosing method.
HDL Paths and Units
Relative HDL paths are essential in creating a verification module that can be used to test a DUT component either standalone or integrated into different or larger systems. Binding an e unit instance to a particular component in the DUT hierarchy allows you to reference signals within that DUT component using relative HDL path names. Regardless of where the DUT component is instantiated in the final integration, the HDL path names are still valid. To illustrate this, let's look at how the switch_fabric is bound to the DUT unit_example (TB top).
To associate a unit or unit instance with a DUT component, you use the hdl_path() method within a keep constrain as in the code shown in previous example.
Predefined Methods for Any Unit
There is a predefined generic type any_unit, which is derived from any_struct. any_unit is the base type implicitly used in user-defined unit types, so all predefined methods for any_unit are available for any user-defined unit. The predefined methods for any_struct are also available for any user-defined unit.
- hdl_path()
- full_hdl_path()
- e_path()
- agent()
- get_parent_unit()
hdl_path()
Returns the HDL path of a unit instance. The most important role of this method is to bind a unit instance to a particular component in the DUT hierarchy. Binding an e unit or unit instance to a DUT component allows you to reference signals within that component using relative HDL path names. Regardless of where the DUT component is instantiated in the final integration, the HDL path names are still valid. The binding of unit instances to HDL components is a part of the pre-run generation process and must be done in keep constraints. Although absolute HDL paths are allowed, relative HDL paths are recommended if you intend to follow a modular verification strategy.
syntax : [unit-exp.]hdl_path(): string
full_hdl_path()
Returns the absolute HDL path for the specified unit instance. This method is used mainly in informational messages. Like the hdl_path() method, this method returns the path as originally specified in the keep constraint, without making any macro substitutions.
syntax : [unit-exp.]full_hdl_path(): string
e_path()
Returns the location of a unit instance in the unit tree. This method is used mainly in informational messages.
syntax : [unit-exp.]e_path(): string
agent()
Specifying an agent identifies the simulator that is used to simulate the corresponding DUT component. Once a unit instance has an explicitly specified agent name then all other unit instances instantiated within it are implicitly bound to the same agent name, unless another agent is explicitly specified.
An agent name may be omitted in a single-HDL environment but it must be defined implicitly or explicitly in a mixed HDL environment for each unit instance that is associated with a non-empty hdl_path(). If an agent name is not defined for a unit instance with a non-empty hdl_path() in a mixed HDL environment, Specman Elite issues an error message.
Given the hdl_path() and agent() constraints, Specman Elite establishes a correspondence map between the unit instance HDL path and its agent name. Any HDL path below the path in the map is associated with the same agent unless otherwise specified. This map is further used internally to pick the right adapter for each accessed HDL object.
It is possible to access Verilog signals from a VHDL unit instance code and vice-versa. Every signal is mapped to its HDL domain according to its full path, regardless of the specified agent of the unit that the signal is accessed from.
When the agent() method is called procedurally, it returns the agent of the unit. The spelling of the agent string is exactly as specified in the corresponding constraint.
syntax : keep [unit-exp.]agent() == string;
Where
string : One of the following predefined agent names: verilog, vhdl, mti_vlog, mti_vhdl, ncvlog and ncvhdl. Specifying the agent name as verilog or vhdl is preferred because it makes the e code portable between simulators. The predefined names are case-insensitive; in other words, verilog is the same as Verilog.
get_parent_unit()
Returns a reference to the unit containing the current unit instance.
syntax :[unit-exp.]get_parent_unit(): unit type
Unit-Related Predefined Methods for Any Struct
The predefined methods for any struct include
- get_unit() : Return a reference to a unit
- get_enclosing_unit() :Return a reference to nearest unit of specified type
- try_enclosing_unit() : Return a reference to nearest unit instance of specified type or NULL
- set_unit() : Change the parent unit of a struct
Bạn Có Đam Mê Với Vi Mạch hay Nhúng - Bạn Muốn Trau Dồi Thêm Kĩ Năng
Mong Muốn Có Thêm Cơ Hội Trong Công Việc
Và Trở Thành Một Người Có Giá Trị Hơn
Mong Muốn Có Thêm Cơ Hội Trong Công Việc
Và Trở Thành Một Người Có Giá Trị Hơn
Bạn Chưa Biết Phương Thức Nào Nhanh Chóng Để Đạt Được Chúng
Hãy Để Chúng Tôi Hỗ Trợ Cho Bạn. SEMICON
