Comments (13)
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.
from systemrdl-compiler.
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
from systemrdl-compiler.
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.
from systemrdl-compiler.
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.
from systemrdl-compiler.
Oh I see what you were originally asking. I misinterpreted your question. I will check your original Python code to see what is missing.
from systemrdl-compiler.
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!
from systemrdl-compiler.
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.
from systemrdl-compiler.
See new method added in v1.27.0: Node.get_global_type_name()
from systemrdl-compiler.
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;
};
from systemrdl-compiler.
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
from systemrdl-compiler.
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.
from systemrdl-compiler.
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.
from systemrdl-compiler.
from systemrdl-compiler.
Related Issues (20)
- Deprecate MessageHandler. Rework all tools to use Python's logging
- Array stride for last element may be wrong HOT 6
- Generate one cycle strobe signal on empty register read HOT 7
- regfile inside addrmap does not compile HOT 1
- Cannot alias registers with we = true HOT 2
- Add ability to inject define macros into preprocessor
- Empty addrmap causes compiler to crash HOT 4
- Software-writable field spanning multiple words should cause error message (accesswidth/regwidth problem) HOT 1
- User defined property default for array type causes exception HOT 2
- [BUG] Parameter internal cleanup after first elaboration HOT 1
- Add support for assigning references in importer API
- Unintended `external` applied to `addrmap` instance HOT 3
- Add method to generate a globally scoped type name to Node API HOT 1
- if struct is not fully defined, compiler crashes, it should point the line with to the error in the SystemRDL file HOT 2
- detecting name collisions during path serialization HOT 1
- Allow Elaboration without addrmap HOT 1
- Set abbreviated Node.type_name for long parameterized types HOT 1
- [FEATURE] property_src_ref needed for UserEnum and UserEnumMember
- Describe how addressing is impacted by ispresent in docs HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from systemrdl-compiler.