How to easily handle UVM hdl_paths for generated RTL

[davidthomasf]

Hi all,

First of all really awesome tool! Getting industry standardization here would be awesome.

My question is on the best way to automatically handle hdl_paths in the generated UVM code for fields where the RTL is generated by PeakRDL-regblock. General idea is to have the default hdl_path for fields to be whatever PeakRDL-regblock generates for the field, since that will be correct for most registers in the design. The complexity is that the path depends on the register name, field name, and access type. Quick example:

sw: rw, hw: r would look like this:
field_storage.<register_name>.<field_name>.value

sw: r, hw: rw would look like this:
hwif_in.<register_name>.<field_name>.next

I'll note that there may be a few simpler options of using the structs themselves as hdl paths as opposed to going all the way down to the value/next fields, but I don't think those options really resolve the fundamental issue.

I think I see a few potential approaches:

1. Have some smarts in the verification environment to automatically assign hdl_paths for any fields without them according to how PeakRDL-regblock generates them. This seems like a reasonable path (and probably my default plan at this point), but it would be nice if the tool could handle this automatically.
2. Enable registers/fields to have "dynamic" defaults in SystemRDL where you would use a function that takes in the field name and the field access properties to figure out the correct hdl path. This could possibly be done with embedded perl code, but it seems at first glance that this would be fairly complex.
3. Have engineers add the correct hdl_path in the SystemRDL. Would work but is fairly inefficient.
4. Some other option I'm not thinking of.

Curious to hear how/if others have solved this problem. It seems like a potential benefit of having the same tool generate the rtl and the uvm collateral, but I don't see an easy way to make it happen with what I currently understand.

Thanks!

[amykyta3]

I actually have something planned for this - see SystemRDL/PeakRDL-regblock#15

Essentially the plan is that when you generate the RTL, PeakRDL-regblock would also dump out a utility class definition that "understands" the structure of the generated SystemVerilog.
Then it is up to the verification owner to apply the HDL path to the appropriate node in the larger UVM model's structure.

This approach has several benefits:

• PeakRDL-regblock already understands the structure of the code it generates, so it makes sense to have that be the tool that generates the HDL paths as well. Locality of concepts is important for tool maintenance (and preventing discontinuities in tool versions)
• Outputting a separate utility class (rather than embedding it into the UVM) gives the verification owner flexibility in case there are multiple instances of the same regblock in the same design.

In the past, I've had the UVM tool generate the HDL paths automatically, but this becomes cumbersome to maintain, since the UVM generator needs to know the difference between blocks generated by the tool vs other 3rd party IP that may have been imported from elsewhere.

I'm planning on rewriting the PeakRDL-uvm tool since there were some dumb decisions I made, and there are a few things that I don't do exactly according to official UVM recommendations. Once that is done (and stable) I'll probably implement the HDL path overlay feature in PeakRDL-regblock.

[davidthomasf]

Thanks for the quick reply!

That solution makes a lot of sense to me. I particularly like the approach of having regblock generate the output.

[jiangqingliu88]

I had the same problem. I have a three-block register model that could allocate segment addresses, but had no backdoor access.At present, I have passed the front door access test of register RAL model, but backdoor access peek, poke has been unsuccessful, always , I suspect that the sturct format of systemverilog does not support VPI for backdoor access,Although the filedstorage struct-registeer string corresponds to the RAL model at all levels, it is also possible that my HDL_path path is not correct. Can you access it through the backdoor ？？？？