WIP: Support records in vpi

[benreynwar]

Description

The goal is to make it possible to use cocotb with a design that uses nested records and arrays in it's ports, signals and generics. Related to issue #237.

It is a long way from being finished, but it would be useful to get some feedback. If you have the time and inclination, any comments would be appreciated.

I've added comments to the code where I have questions about how things should work.

[tgingold]

rti: run time information. That's all the data emitted by translate to describe vhdl types and subtypes.

[tgingold]

grt.rtis is the package that describes the rti.

[tgingold]

rti node. All the ghdl_rtin_* records defines the rti data.

[tgingold]

Example for a port:
you have an rti that describes the port: its name, its type, its mode...
But you also need its address to get its value. But a port is part of an entity that can be instantiated many times. So you need the context of the port, which consists of the entity/architecture and the address of the entity/architecture instance.

[tgingold]

Not at the C level. There is AVHPI which is inspired from VHPI but uses Ada style. But there is no C VHPI interface. Shouldn't be very hard to do, but there are very few examples.

[tgingold]

I really prefer to have standalone tests. That's easier to investigate and do not depends on cocotb evolution.

[tgingold]

Looks ok.

[tgingold]

It's the prefix for names in the vhpiHandleT. All the names in a record must be unique.

[tgingold]

Yes, to be added ?

[tgingold]

and also record subtypes ? :-)

[tgingold]

Possibly. In VPI you can directly get the value of a vector.

[tgingold]

Yes, generics contain the raw value, while signals are addresses to an internal structure.

[tgingold]

Ah OK. So that's the for_generate_statement. There is an array containing the sub-instances, because the block can be repeated many times. So we need to update the context to point to the corresponding sub-instance.

[tgingold]

I think it is mainly SDF annotations + what has been asked for VPI.

[tgingold]

That looks OK, but I haven't thoroughly reviewed this subprogram.

[tgingold]

Ah. An array type declaration like type my_vec is array (0 to 7) of bit is represented as an anonymous unconstrained array type declaration type anon_my_vec is array (integer range <>) of bit followed by a subtype declaration subtype my_vec is anon_my_vec(0 to 7). So we need to ignore the anonymous array type declaration and pretend that the subtype declaration is a type declaration.

[tgingold]

Use --vpi-trace to dynamically set this flag.

[tgingold]

Comments added.

[benreynwar]

Awesome, thanks a bunch for the help!

[tgingold]

If you need more comments, do not hesitate. Maybe we can start to merge some parts. For example, if it is already possible to scan through generics of a record type, this specific part could be tested and added.

[benreynwar]

I'm trying to understand the RTI structures but am having difficulty understanding what data is stored in the memory that the Loc fields point to. My understanding is that the Loc fields tell us the location of relevant data in the memory relative to the address specified by Rti_Context.Base, but I'm not sure what structure exactly is stored in this location, and how the stored data is different for the different RTI nodes.

[tgingold]

Note that there is the option '--dump-rti' to dump the rtis at runtime: ghdl -r design --dump-rti That could be useful to understand how rtis work. This is implemented by grt-disp_rti, which is almost standalone. 1) VHDL types are represented as close as possible to the corresponding C type. So a scalar is represented as a scalar, an array as an array and a record as a struct. 2) For signals, the scalars and the scalar sub-elements are represented as pointers. So a bit signal is represented by a pointer, a std_logic_vector by an array of pointer, and a record by a struct of pointers. The pointer points to ghdl_signal record defined in grt-signals. The record contains the current value, but also the value for 'event, 'active, 'last_value, 'last_event... 3) for records, there is one RTI for each element, which gives the offset from the record address to the field address. But grt.rtis_utils has many subprograms to handle the rtis, including Record_To_Element.

[benreynwar]

Looking at grt-disp_rti is helping. I don't have any additional questions, and there's nothing that's worth reviewing yet. I'm just going through grt-disp_rti and making sure I understand what's going on.

[benreynwar]

When a new array type is defined that binds an unbound type an anonymous RTI type object is created:

type mytype is array(natural range <>) of std_logic_vector(WIDTH-1 downto 0);

However when a new record type is defined that binds an unbound type an anonymous type is not created. Rather the information about the bounds is stored in the element node of the record.

type mytype is record
  a: std_logic_vector(WIDTH-1 downto 0);
end;

This is a bit of a pain when dealing with the subcomponents of the signal, since there is no RTI type that can be easily referred to. Instead we have to refer to the unbound type, and the bounds information. It would be much more pleasant if records created anonymous types in the same way that arrays do. Is this a change that could be limited to the RTI part of the codebase or would it be more complicated?

[benreynwar]

Also, the RTI tree has Ghdl_Rti_Object to represent signal/port/constant/generic but doesn't contain any more fine-grained objects to represent the subcomponents. Is this intentional so that we don't get a crazy number of objects that might effect peformance, or was it just that there was no advantage to it? Having more fine-grained objects could simplify things when dealing with records and arrays.

[tgingold]

Also, the RTI tree has Ghdl_Rti_Object to represent signal/port/constant/generic but doesn't contain any more fine-grained objects to represent the subcomponents. Is this intentional so that we don't get a crazy number of objects that might effect peformance, so was it just that there was no advantage to it? Having more fine-grained objects could simplify things when dealing with records and arrays.

That's not possible. The size of arrays is not known when the RTIs are generated.

[tgingold]

type mytype is array(natural range <>) of std_logic_vector(WIDTH-1 downto 0); However when a new record type is defined that binds an unbound type an anonymous type is not created. Rather the information about the bounds is stored in the element node of the record.

I am not sure to understand what you means: ``` entity repro1 is generic (WIDTH : natural := 4); end; architecture behav of repro1 is type myarr is array(natural range <>) of bit_vector(WIDTH-1 downto 0); type myrec is record a: bit_vector(WIDTH-1 downto 0); end record; begin end; ``` `ghdl -r repro1 --dump-rti`: ... ``` ghdl_rtik_architecture, D=1, sloc=5:14: behav filename: repro1.vhdl ghdl_rtik_entity, D=1, sloc=1:8: repro1 filename: repro1.vhdl ghdl_rtik_generic, D=1, sloc=2:12; width: natural := 4 ghdl_rtik_type_array: myarr is array (natural range <>) of bit_vector (3 downto 0) ghdl_rtik_type_record: myrec is record ghdl_rtik_element: a: bit_vector (3 downto 0) ```

[benreynwar]

My understanding is that an anonymous RTI node with kind Ghdl_Rtik_Subtype_Array is created. The Ghdl_Rtik_Type_Array with name myarr then references this anonymous subtype as it's Element.

For the myrec type no anonymous subtype array is created, rather the Ghdl_Rtik_Type_Array is used in conjunction with the bounds stored in the layout associated with the Ghdl_Rtin_Element.

The anonymous types don't show in the disp_rti dump because they are not children of any of the blocks.

[benreynwar]

I still don't understand why this couldn't be implemented as an anonymous subtype. Defining the bounds in the object is equivalent to defining the bounds in an anonymous subtype and then pointing the object to that subtype. I don't use much of vhdl08 so it's possible I'm missing something. I have a book on vhdl08 arriving in a couple of weeks :).

No, because the bounds may belong to the object and not to the subtype. For example: type string_acc is access string; a := new string'("Hello"); b := new string'("my world"); So a and b have two different bounds, and the number of such objects is unknown. So if we needed to always have bounds in an RTI we would have to dynamically create RTIs.

Still trying to get my head around this. In the example you gave we'll be creating RTIs for a and b. Why wouldn't it be practical to create an anonymous subtype for each at the same time?

Edit: I'm going to sleep now. Thanks for the explanations.

[tgingold]

Still trying to get my head around this. In the example you gave we'll be creating RTIs for a and b. Why wouldn't it be practical to create an anonymous subtype for each at the same time?

And to store the bounds within this RTI ? The consequence is that you will have to modify the RTIs each time to assign such a variable, because you could change the bounds. But RTIs are read-only. Or having RTIs that say that the bounds are within the object ? I fear that would be much more complex or not very different from the current implementation.

[benreynwar]

Still trying to get my head around this. In the example you gave we'll be creating RTIs for a and b. Why wouldn't it be practical to create an anonymous subtype for each at the same time?

And to store the bounds within this RTI ? The consequence is that you will have to modify the RTIs each time to assign such a variable, because you could change the bounds. But RTIs are read-only. Or having RTIs that say that the bounds are within the object ? I fear that would be much more complex or not very different from the current implementation.

I understand. The bounds are determined after elaboration and could change during runtime. I have to try to remember about non-synthesizable vhdl too :).

[tgingold]

Yes. On top of that, subprograms parameters are often of unbounded types.

[benreynwar]

I'm continuing to very slowly work on this. If anyone is impatient and would like to have a crack themselves, I won't be at all offended if you take over :).