Type name is not uniquified if parameter from parent scope is used

[hughjackson]

https://github.com/SystemRDL/PeakRDL-uvm/blob/af894376240a8b10a98ab9e49a3a16283343c09f/peakrdl/uvm/exporter.py#L173

The following RDL code highlights the issue:

addrmap block {
    regfile rf_t #(boolean P = false) {
        reg {
            field {} f1 = P ? 1 : 0;
        } r0;
    };

    rf_t #(.P(false)) rf1;
    rf_t #(.P(true))  rf2;
};

A cut down version of the output shows that whilst the regfiles (rf_t) are uniquified (with addition of _P) both unique instances use the same r0 type (block__rf_t__r0) so they end up with the same reset value, even though rf2.r0.f1 should have a reset value of 1.

    // Reg - block::rf_t::r0
    class block__rf_t__r0 extends uvm_reg;
        rand uvm_reg_field f1;
        virtual function void build();
            this.f1.configure(this, 1, 0, "RW", 1, 'h0, 1, 1, 0);
        endfunction : build
    endclass : block__rf_t__r0

    // Regfile - block::rf_t
    class block__rf_t extends uvm_reg_block;
        rand block__rf_t__r0 r0;
    endclass : block__rf_t

    // Regfile - block::rf_t_P_t
    class block__rf_t_P_t extends uvm_reg_block;
        rand block__rf_t__r0 r0;
    endclass : block__rf_t_P_t

    // Addrmap - block
    class block extends uvm_reg_block;
        rand block__rf_t rf1;
        rand block__rf_t_P_t rf2;
    endclass : block

[amykyta3]

Nice find! This is definitely an oversight in the compiler when generating component type names. I already had to extend the behavior defined by the SystemRDL spec to account for dynamic property assignments.

Since this is actually a bug in the systemrdl-compiler, moving this issue under that project.

[amykyta3]

My mistake. This is indeed a UVM exporter issue. Transferring it back :facepalm:

[amykyta3]

Fixed in v2.0.2