missing parameterization in the component hierarchy

[jeras]

missing parameterization in the component hierarchy

[jeras]

Thanks.

I might be able to do it myself, but I might not be as lucky as when I figured using the exit callbacks would generate definitions in the correct order of dependency. So I might write an ugly hack which would plague my company or/and the internet for eternity.

Seriously if time permits, I will try to repay you by writing a simple example of this problem for the documentation.
Separately I will write down all the research I have done on a user defined property for specifying field types:

• boolean,
• arbitrary precision integers,
• fixed point.

[amykyta3]

This is working exactly as intended. The reason the street component gets its type name augmented by the parameter is because that is the component that the parameter definition is bound to.
It is true that the child reg components house and car also have their contents augmented by the same parameter, but that is merely due to the availability of that parameter within the lexical scope. house and car themselves do not have any parameter bound to them directly.

Also due to how lexical scopes work, the house and car components do not need their type names to be augmented further since they are guaranteed to be distinct within that lexical scope.
The language reference has more details on how type names are augmented in section 5.1.1.4. This compiler also extends this type name generation further to cover situations where dynamic property assignments augment a named type.

Regarding how to generate unique & reusable structs - I do the exact same thing in several places and it is nearly identical to what you are currently doing:

• UVM class generator: https://github.com/SystemRDL/PeakRDL-uvm/blob/main/src/peakrdl_uvm/exporter.py#L231-L242
• Regblock hwif struct generator: https://github.com/SystemRDL/PeakRDL-regblock/blob/main/src/peakrdl_regblock/hwif/generators.py#L15
• C header struct generator: https://github.com/SystemRDL/PeakRDL-cheader/blob/dev/src/peakrdl_cheader/header_generator.py#L253-L256

[jeras]

I tried cheader (installed with pip) and got a jinja related error, lets skip this one for now.
The UVM class generator is a bit different, since UVM classes can be parameterized, so they provide much more flexibility compared to SystemVerilog or VHDL-2008 RTL. Well Vivado documentation states SystemVerilog class support in synthesis, but this is again beyond this discussion.

So I will focus on the regblock generator. Again the one installed with pip. I am not sure how to check the version or whether it matters (whether there were related changes done to the sources.

I run the regblock generator:

peakrdl regblock city.rdl -o regblock/ --cpuif apb4

And I checked the generated SystemVerilog package city_pkg.sv.
It only contains the parameter default 32-bit field definitions, 16 and 7 bit field definitions are not generated.

If I try to generate markdown, just to check again if my interpretation of the standard and your response are correct:

peakrdl markdown city.rdl -o city.md

I can clearly see the 7 and 16 bit fields.

As a conclusion, I would say you have the same issue (I need a solution for) in the regblock generator.

[jeras]

I had a look at the UVM generator and it does generate the extra parameterized types.
I will use the code as reference, but I have run out of time for this project, maybe I will get back someday.
Still, UVM classes could use their own parameterization features instead of making a new class for each parameterization.

[amykyta3]

Oh I see what you were originally asking. I misinterpreted your question. I will check your original Python code to see what is missing.

[amykyta3]

Ok so after reviewing your example I see what is going on.
I assume you expected to see the parameter displayed in the type names, so instead of this:

DEF-component: street_NUM_8
  INS-component:   HOUSE : street_house_Type
  INS-component:   CAR : street_car_Type

you want this:

DEF-component: street_NUM_8
  INS-component:   HOUSE : street_NUM_8_house_Type
  INS-component:   CAR : street_NUM_8_car_Type

The subtlety is that Node.inst.get_scope_path() returns a lexical scope path, and not a resolved type hierarchy. This is intentional, but extremely subtle and definitely misleading.
After reviewing some of my own examples, I actually made the same mistake! The only place I do it correctly is in the UVM generator using a custom function that is somewhat convoluted

Since this is actually a pretty common usage pattern, I'll add a utility function in the compiler's API to return the proper type name. get_scope_path() is tantalizingly close to what you need, but not quite the correct mechanism to generate unique global type names.

I have created a separate issue (#187) to track this feature.

Thanks for pointing this out. I totally screwed this up in the PeakRDL-regblock and the upcoming rewrite of PeakRDL-cheader!

[jeras]

I agree with the assessment that this would be a common usage pattern and that adding it to the API would help.

I mostly understand the distinction between the lexical scope a resolved type and the instantiation path, but when I have to use them properly, or describe them unambiguously, they become confusing (like pointers in C). I would like to think through where exactly in the hierarchy should be the parameterization, so I could comment on your implementation, but I would probably just add to the confusion. Still I will use the new API in my code.

[amykyta3]

See new method added in v1.27.0: Node.get_global_type_name()

[jeras]

I used the new API in my VHDL code generator and it works properly.

In the commit I noticed in class FieldNode(VectorNode): there was some code related specifically to field width.
I did not try to understand what exactly it does, my question is, whether it would work if field properties other than width were parameterized.

So I wrote an example and tested it. Apparently it works. So just ignore the above question.

I attached the example, since it is a nice example and could be reused. I got inspiration from this music album.

interrupt control/status registers

Matching fields in both registers have the same instance names, and name/desc properties, so it makes sense to define a register with this fields only once. The parameters define sw/hw used as defaults in the registers to distinguish between configuration and status.

reg interrupt_register #(
    accesstype SW = rw,
    accesstype HW = r
){
    default sw = SW;
    default hw = HW;
    field {} SYSTEM_CLOCK;
    field {} KEYBOARD;
    field {} CASCADE;
    field {} MODEM;
    field {} MOUSE;
    field {} SOUND_BLASTER;
    field {} FLOPPY_DISK_DRIVE;
    field {} PRINTER;
    field {} CMOS;
    field {} NETWORK;
    field {} DFX;
    field {} SCSI;
    field {} VGA;
    field {} COPROCESSOR;
    field {} PRIMARY_IDE;
    field {} SECONDARY_IDE;
};

regfile interrupt_controller {
    interrupt_register #(.SW (rw), .HW (r )) CONF;
    interrupt_register #(.SW (r ), .HW ( w)) STAT;
};

addrmap pc {
    interrupt_controller IRQ;
};

[amykyta3]

Glad it is working for you!

The extra code for fields and their width is to properly disambiguate type names in this situation:

field thing {};

thing thing1;
thing thing2[8];

Despite using the same component type declaration, I would consider these to be different types since they are different widths. thing1 would use the original type name, and thing2 would include a suffix of _w8 since it was altered to a different bit width from the original definition.
I haven't decided yet, but in the future I may move this to be part of the extended type name generation described here: https://systemrdl-compiler.readthedocs.io/en/stable/dev_notes/dpa_type_generation.html

[jeras]

I did not check what the standard would state regarding this code, and came up with this interpretation.

Instead of a single 8-bit vector field, this is an array of length 8 of single bit fields. So 8 individual children of the register node. If this interpretation does not make sense, it might help to explicitly rule it out. Still it seem like some ambiguity in the standard syntax.

[jeras]

Regarding dpa_type_generation, did you try to contact Accellera to ask the original authors for their interpretation.

I wrote them once regarding the old SystemC license, which was not open source enough for Debian. They did reply with a polite refusal, but the point is they did reply. Years later they did change the license, there were probably others asking about this.

My point is Accellera might be willing to give your contact information to some of the original authors and some might reply and be willing to discuss this issues with you.

[amykyta3]

Regarding 8-bit vector for fields: This is clearly described in the spec. See section 9.3 I have had several contacts from the SystemRDL committee that helped greatly with the initial interpretation of the spec. Responses have been mixed though. Some have been very helpful, others completely unresponsive. I would love to see more engagement from Accellera regarding the RDL standard. I would recommend reaching out here: https://forums.accellera.org/forum/52-systemrdl-discussion/ One of the committe members, Richard Weber, appears to be sparsely active there. There are also a few email aliases listed in the spec or other Accelera pages. They may be tired of getting my emails, but perhaps if others reached out they would respond :-)

…

On Thu, Oct 12, 2023 at 1:17 PM Iztok Jeras ***@***.***> wrote: Regarding dpa_type_generation, did you try to contact Accellera to ask the original authors for their interpretation. I wrote them once regarding the old SystemC license, which was not open source enough for Debian. They did reply with a polite refusal, but the point is they did reply. Years later they did change the license, there were probably others asking about this. My point is Accellera might be willing to give your contact information to some of the original authors and some might reply and be willing to discuss this issues with you. — Reply to this email directly, view it on GitHub <#186 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC3W6I36LNKRZUENCM2K5ODX7BF67ANCNFSM6AAAAAA5ZDZWEQ> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>