How to set hdl path for fields in Cadence uvm_rgm?

[adyashrotriya]

*.set_hdl_path(); works fine for a 8 bit register.

But, for registers with fields with different names, how do we set hdl path for the entire field?

For example, 8 bit register will have 4 reserved bits, 2 column_width, 2 row_width. These three fields together will form the register. How do I set hdl path for the entire register that accommodates these three different fields.

Thanks.

[lisakb1963]

You need to have (N sets) of this tag:

<vendorExtensions:hdl_path>my_dut_reg</vendorExtensions:hdl_path>

In your case you would have one at the register level -- depending on how your design is working this can be the straight name of the register -- the top level path is defined at outside of the register blocks.

For instance my register (you don't have to reserve fields that is the default, but you can do it -- you just will not use it in the rtl

spirit:register>

<spirit:name>my_reg</spirit:name>

<spirit:addressOffset>0x01</spirit:addressOffset>

<spirit:size>8</spirit:size>

...

<spirit:field>

<spirit:name>col_width</spirit:name>

<spirit:bitOffset>2</spirit:bitOffset>

<spirit:bitWidth>2</spirit:bitWidth>

<spirit:vendorExtensions>

<vendorExtensions:collect_coverage>cov_all</vendorExtensions:collect_coverage>

<vendorExtensions:hdl_path>my_fld_col_width</vendorExtensions:hdl_path>

</spirit:vendorExtensions>

</spirit:field>

.. the same for the row_width.

After all the fields have been defined, you make all the vendorExtensions forthe register itself. This is where you would put the actually path to the 8 bit register name within the DUT.

As far as the RTL, these must be exact names -- to create my_dut_reg you can use the hdl field names and bit concatenations. This way you can manipulate fields of registers and the register or vice versa --depends on your RTL decode.

Edited December 27, 2011 by lisakb1963

[Euphemia]

You need to have (N sets) of this tag:

<vendorExtensions:hdl_path>my_dut_reg</vendorExtensions:hdl_path>

In your case you would have one at the register level -- depending on how your design is working this can be the straight name of the register -- the top level path is defined at outside of the register blocks.

For instance my register (you don't have to reserve fields that is the default, but you can do it -- you just will not use it in the rtl

spirit:register>

<spirit:name>my_reg</spirit:name>

<spirit:addressOffset>0x01</spirit:addressOffset>

<spirit:size>8</spirit:size>

...

<spirit:field>

<spirit:name>col_width</spirit:name>

<spirit:bitOffset>2</spirit:bitOffset>

<spirit:bitWidth>2</spirit:bitWidth>

<spirit:vendorExtensions>

<vendorExtensions:collect_coverage>cov_all</vendorExtensions:collect_coverage>

<vendorExtensions:hdl_path>my_fld_col_width</vendorExtensions:hdl_path>

</spirit:vendorExtensions>

</spirit:field>

.. the same for the row_width.

After all the fields have been defined, you make all the vendorExtensions forthe register itself. This is where you would put the actually path to the 8 bit register name within the DUT.

As far as the RTL, these must be exact names -- to create my_dut_reg you can use the hdl field names and bit concatenations. This way you can manipulate fields of registers and the register or vice versa --depends on your RTL decode.

Hi lisakb1963,

 

Do we have to add tags to each fields or just add register names? I'm new to this technique, trying to find out a way to add hierarchical hdl_path in python codes to generate the xml schema. But not sure how to deal with the hierarchical path. Does it have to be an exact path or just a tag and then clarify at last in the 8 bit register name?

 

Thanks.