template tree for fields in a record type

[mayagokhale]

The template tree for top level ports, signals and variables is extremely useful to pass the type information out to the hnode parser. However, this information isn't available for fields within a structured type. For example for a declaration sc_rvd_out<fp_t<11,52>> m_port, the template types are generated as (sc_rvd_out) sc_rvd_out (sc_rvd_out) fp_t (fp_t) 11 (fp_t) 52 > Template args (DFT): sc_rvd_out fp_t 11 52 But for the fields within sc_rvd_out, such as ready, valid, data, there isn't a template arg tree. This means that the plugin will have to call the appropriate matcher to generate these trees or else write equivalent code to parse the field types.

[rseac]

The thinking was that sc_rvd was to be considered as a SystemC primitive. Very much the likes of sc_in. Hence, there would be implicit knowledge in the generation that sc_rvd would have the respective signals (ready, etc.).

Do we wish to change this so that sc_rvd is no longer considered a primitive?

[mayagokhale]

I used scrvd as the example because I don't yet have code that explicitly recognizes that class. I can add that in. However, the issue still remains for sc types that can take user-defined type template parameters.

Using sc_rvd as the example since it isn't being recognized as a special type, I am flattening the m_port fields as m_port_ready, m_port_valid, and m_port_data, i.e. hPortout m_port_data [ hTypeinfo NONAME [ hType UNKNOWNTYPE NOLIST The type isn't known because I don't recognize TemplateSpecialization: field m_port_data type follows TemplateSpecializationType 0x113e8a0c0 'sc_out<struct fp_t<11, 52> >' sugar sc_out |-TemplateArgument type 'struct fp_t<11, 52>':'struct fp_t<11, 52>' -RecordType 0x113e8a0a0 'class sc_core::sc_out<struct fp_t<11, 52> >' -ClassTemplateSpecialization 0x113e89fb0 'sc_out'

At this point I would have to traverse fp_t with those parameters to find the fields in it. As we discussed, we can either keep the nested record structure and have the verilog parser unravel it or used bit offsets into the top level structure (data). In either case, the plugin needs to recursively traverse fields of a class to generate the appropriate translation for the fields that is consistent -- either passing along the structure or resolving to bit offsets and lengths. In either case it requires traversing the TemplateSpecialization tree at a lower level than is currently being done.

[rseac]

I understand.

At the moment, only SystemC modules are parsed for their fields. We could extend it such that for every identified type used in a port or signal declaration, the FieldDecl and VarDecl within it are also parsed. This would allow one to access the fields within a type.

Opened up #91 to make it clear.

[rseac]

@mayagokhale I believe this is done now.