-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Emit Parametrized PeakRDL output #33
Comments
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. |
Thanks allot! |
Also looking forward to implementing this one! However it is easily one of the more complicated features I have on my list. 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:
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. |
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. Another question: do you have any ETA on this? |
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. |
Thanks.. I might try to look in the code as well. 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! |
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. |
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. |
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: ***@***.***>
|
BTW another thought- |
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? |
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 😆 |
Not sure I follow regarding the place holder - probably something missing in my understanding. I'm still studying the code. Part of it I understand analytically, and part of it is just trial and error.. (things fail - I get a Python exception and then I fix that area). Sort of an opportunistic debug mode.. Validation - yes, that's what I did temporarily right now.. bypassing validation only when the reset value / array dimensions are a ParameterRef. Nothing else should be disturbed. I think emitting some kind of runtime checking or assertions eventually cannot be avoided since you don't know what funny things the users will do .. (can be enabled optionally via subcommand flag..) Regarding review, sure, actually I've already forked the project. Thanks for your support! |
Hi, I've uploaded a sketch implementation that allows parametrization of: I'm now working on parametrized field width. hopefully it'sll be easier and quicker. forked projects: I didn't touch the command line tool though. One thing I didn't get right is the selective selection of parameters to keep symbolic. I'm now adding the missing trial implementation of field msb/lsb being kept parametrized. Here, I'll pass down the specific list of params from the cmdline to the actual code. Only params the user requested to be kept symbolic will be kept as such. Rest will be resolved. |
Hi @galaviel,
Do you have any ideas about this problem? Below is the simple RDL code I used to try this feature:
Any help would be greatly appreciated. |
Hi, ( Jimmy - will take look now ) I've uploaded the missing feature of msbit/lsbit parametrization. Repo links - same 2 as before, and in addition - https://github.com/galaviel/PeakRDL-Parametrized.git (had to change the cmdline tool itself to pass cmdline options to the compiler). Commit msg below. Note tested only with the trivial case of single field, lsbit=0 msbit=some parameter name. And seems to work (ran RTL simulation). Again provisory, needs to be better (re)structured. commit msg: Adding support for keeping parametrized, the ms/ls-bit of the field. Note: ms-bit expression must be comprised only of the single parameter Also, Fixing a conceptual bug: Previously if --keep_params was provided But, for the Field MSbit, I now added this support. Only Field MSbits So, need to pass 'options' (cmdline options) to the compiler, since the |
Hi Jimmy, Please try '[SIZE:0]' instead of just [SIZE] to define the field. For some reason the latter isn't working. Need to figure out why. Let me know how goes. |
Hi @galaviel, Thank you for your reply!!!
Please let me know if there is anything I missed or if there are any additional steps I need to take. The following is the error message
Thank you! |
Hi Jimmy, I do believe you need to pull from all 3 repositories (the compiler, command line tool, and regblock exporter) since I've edited all three. Here's my setup. There is an order which you need to clone the repo's which @amykyta3 has specified in a previous discussion (can't find it now ..). anyway here's my setup:
hope this works for you - if not let's try to understand together what are the issues, Thanks, Gal. |
Hi @galaviel, I just wanted to let you know that I was able to successfully install your repository using the instructions you provided. However, I encountered an issue when running the command
To resolve this issue, I manually commented out line 6 in the "sw_onwrite.py" file, which is located here. Once again, thank you for your help and for sharing your work with the community. Sincerely, |
Hi @galaviel, I have another small question. I was looking at the generated RTL module interface and noticed the following code snippet:
My question is regarding the Thanks. |
Hi Jimmy, Regarding the redundant import, you are right. I've removed this line & pushed to github. Regarding the unassigned parameter, if I understand correctly what you were asking, then I would say that's the whole point. (keeping it unassigned). Hope this is what you meant, if not do let me know, Thanks, Gal. |
Hi @galaviel, Thnaks for your response! I understand and agree with your thoughts. I have a new situation that I'm not sure if you have considered before.
I hope that my question was clear, but please let me know if there's anything that needs clarification. Thank you, |
Hi Jimmy, Sorry for my late reply .. was lost in the flood of emails. I see your point. I'll work on fixing that. keep you posted.. |
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.
The text was updated successfully, but these errors were encountered: