Emit Parametrized PeakRDL output

[galaviel]

Greetings !
Awesome project BTW!

I did a quick pilot in my company using PeakRDL with Synopsys VCS, replacing an existing register module with SystemRDL specification + PeakRDL output. Worked Nicely.

A feature that we miss is the ability to emit parametrized output. Meaning keep the symbolic SystemRDL parameters in the generated RTL instead of replacing them with actual values.

This can allow us to embed the generated RTL CSR module in a generic/parametrized design, have the user specify actual parameters in the instantiation, and let those Parameter values seep down to the generated CSR RTL. (in addition to configuring the logic that surrounds the register module).

This can be a killer feature..
Is this a change that can be done at the PeakRDL generator level? or is this in the SystemRDL Parser code/project before that?

Any help appreciated,
I think I'll take a look myself..

Thanks in advance, Gal.

[amykyta3]

That is certainly the long-term plan, however it is not something that is possible currently until I make updates to the underlying compiler. For that, see: SystemRDL/systemrdl-compiler#58

Since this is a request for the PeakRDL-regblock sub-project, I will migrate this issue there.

[galaviel]

Thanks allot!
really looking forward to that.
Note it will mean changing the port type from Struct's to SystemVerilog Interfaces since the former does not allow parametrization (as far as I can tell). Which results in many small changes to the output RTL.

[amykyta3]

Also looking forward to implementing this one! However it is easily one of the more complicated features I have on my list.
Parameters can potentially influence all sorts of aspects of the register block, not just the number of elements in an array, or an address offset. There are countless edge cases such as property assignments and structural changes as well.

To avoid over-complicating, the implementation of this feature for the regblock will likely be limited to only be allowed for a select few value assignments that cover the more common use-cases. Off the top of my head:

• Field width
• Field reset value
• Array size
• Address offset (maybe)
• ispresent property

Beyond these, the implementation can get extremely complicated due to limitations in the SystemVerilog language.

Agree that something would have to change for the hwif definition to accommodate this.

[galaviel]

Sounds great! I think that's the way to go... Implementing the limited feature set users are actually likely to use, is a great way to provide real life value to users. fast.
Regarding Array size - will you allow an expression? such that the size of the Array can be e.g. 4*PARAM ?

Another question: do you have any ETA on this?
I think right now I'll try to assign unique values to parameters and try to search & replace them in the generated RTL, that might work for simple stuff and provide a simple work-around.
Thanks!

[amykyta3]

Yes - in many of the cases, preserving the parameter to the output will necessitate preserving expressions as well.

Since this is something I work on as a hobby on my own personal time, it is difficult to provide an ETA. I have quite a few items in my backlog that I plan to address first before I start working on this feature.

[galaviel]

Thanks..
regarding ETA - of course, I understand and I greatly appreciate the awsome work you've done :)

I might try to look in the code as well.
Coming from EE background I haven't studied compilers at all but I hope I can manage...

Again, a simpler work-around for now (since I do need this) would be to assign unique integer values to PARAMETERS, then perform search & replace in the genereated RTL. I think that might work mostly, perhaps a manual touch-up will be required in 2-3 places after that, which is hopefully an acceptable solution for my users.

Thanks again!

[galaviel]

Hi,

I'm experimenting with adding very limited support for parametrized out - only for register Array sizes and field reset values for now. I've modified all 3 repo's (the compiler, peakrdl command line tool and the regblock generator/exporter).

Surprisingly this seems to work. The output looks OK for my simple RDL input file.

The readback part is more difficult though. One thing I don't understand is the need for 'n_regs' in file peakrdl_regblock\readback\generators.py.

Since all register array dimensions are known in advance, why is it really necessary to go through all the individual register MDA array elements in order to dedude n_regs? this is known already..

Just curious

Thanks, Gal.

[amykyta3]

Part of the readback block is to reduce all possible readable registers into a single flattened array. Since not all registers are necessarily going to to be readable by software, this is not necessarily going to simply be the accumulation of all enclosed registers in an array.
In order index into this flattened array, the cumulative number of elements prior needs to be tracked. This is done via the n_regs variable.

[galaviel]

Right. not all registers are readable. Got it, thanks.In that case I would perhaps suggest to rename n_regs -> n_readable_regs. Also, related to naming convention, perhaps I got this wrong, but in file PeakRDL-regblock\src\peakrdl_regblock\forloop_generator.py,I see two classes: Body and LoopBody. It seems the latter is the entire loop rather than only the loop body as its name suggests - (includes the for(..) line, the body itself - assignments and the enclosing 'end'). Is my understanding correct? I think I'll finish this limited "sketch"/try with parametrization (the templates needs modifications too - need to change to SystemVerilog Interface instead of struct and many other small changes). After that I need to do some cleaning.  Is this work interesting in any way to post back to the community or contribute back to the project? I imagine you have your own ideas on how to implement this (most likely better than mine..) but I do really need this feature urgently...should I fork the project and commit there? haven't work with Github in the past.. On Monday, 17 April 2023 at 04:35:44 GMT+3, Alex Mykyta ***@***.***> wrote: Part of the readback block is to reduce all possible readable registers into a single flattened array. Since not all registers are necessarily going to to be readable by software, this is not necessarily going to simply be the accumulation of all enclosed registers in an array. In order index into this flattened array, the cumulative number of elements prior needs to be tracked. This is done via the n_regs variable. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[galaviel]

BTW another thought-
since parameter values are not known at time of generation, part of the validation cannot be done.
How do you feel about inserting SystemVerilog Assertions to do the validation at runtime in this case?

[galaviel]

One more thing, in PeakRDL-regblock\src\peakrdl_regblock\readback\generators.py, you use the term "$i{i}sz" because you do not know in advance the size of the array. I wonder why that is - isn't the entire register supposed to be SW readable or not, and thus its dimensions are known in advance? why there is a need to search and replace the actual array size after iterating through all the array dimensions?

[amykyta3]

During iteration of a regfile, or nested regfiles, it is not known how many of the elements will be readable, so therefore it is not known how much of an offset is required between blocks. This is why the placeholder is emitted temporarily and then back-filled later.

Regarding validation - I was initially planning on bypassing validation of various aspects of the design since they are not known. Inserting assertions is an interesting idea that might be useful in some areas.

Lastly, I would love to see what you have done so far. Generally on GitHub, if you fork a repository to your personal workspace and push your changes, they will be visible for me (and others) to review. It would definitely be interesting for me to see how you implemented this feature. Of course, the challenge is always going to be to make it robust in all the general cases which is up to me to do 😆