Implement interface_array & module_array

[hs-apotell]

Implement interface_array & module_array

Dependent on UHDM PR chipsalliance/UHDM#790

[alaindargelas]

Interface arrays and module arrays do not help anything in the elaborated model, they are like keeping the model folded.
At most, they have their place in the non elaborated model. They have no place in the elaborated model.
In the elaborated model we need the bit blasted view like we bit blast the generate statements loops.

[alaindargelas]

This is redundant information

[hs-apotell]

Interface arrays and module arrays do not help anything in the elaborated model

Of course they do. May not be for simulation but for tools they provide the ranges and the location information. In the elaborated model, both the array and the blasted view is required.

[alaindargelas]

For Generate statements we do not keep any folded view, we bit blast, same with the gate arrays, we have to be consistent. You can keep the module_arrays and instance_arrays in the non-elaborated model.

[alaindargelas]

Plus tools like Yosys and Verilator would see 2 views of the same thing, errors in perspective.
This PR cannot go in as is

[hs-apotell]

I followed your lead on this. #3101 is your change where you introduced interface_arrays in the elaborated model. This PR is following the same convention for module_arrays. Is #3101 wrong?

There is no duplication in the elaborated model. The arrays are pointing to the blasted elements (not recreating them) and the array itself is unique within the tree. Has introduction of interface_arrays in the elaborated tree with #3101 introduced any problems that I am not aware of?

I can make the necessary changes to remove the module_arrays from the elaborated model but I strongly disagree with your assessment on this.

[alaindargelas]

I can't reconcile the explanation here:
#3198 (comment)

and the actual logs in the PR, the 2 don't match. I see a bunch of new entries that are redundant in the logs you added to the PR.

Example:
UnitElab.log
These entries existed already, why there are new entries with no particular new info:

\_module: work@my_module ([email protected][0][0][0]), file:top.v, line:29:3, endln:29:44
|vpiModule:
\_module: work@my_module ([email protected][0][0][1]), file:top.v, line:29:3, endln:29:44
|vpiModule:
\_module: work@my_module ([email protected][0][1][0]), file:top.v, line:29:3, endln:29:44
|vpiModule:
\_module: work@my_module ([email protected][0][1][1]), file:top.v, line:29:3, endln:29:44

Do they have the same ID as the actual module instance parented to the parent module?

[hs-apotell]

Backtracking a bit

#3101 is a change you introduced. This added interface_array to elaborated tree. interface_array/Interfaces hold references to the blasted instances i.e. interface.

With the above change, I expected InterfArrayBind to also change. But the PR doesn't have any affect on this test. The test file itself includes interface_arrays but not as port entries but as a member of the module. This use case is not covered by your update. That's what is reported as #3198.

Also, your PR #3101 did not add the interface_arrays to the non-elaborated tree. This PR i.e. #3200 adds that too.

This specific PR i.e. #3200 was following your example from #3101 to add module_arrays to elaborated tree and the non-elaborated tree. Since the non-elaborated tree was still missing the interface_array entries, this PR adds that too.

In all of this change, there are no new modules or interface are instantiated. Both interface_array and module_array hold references to the interface and module respectively that are already created and existent in the elaborated tree. For non-elaborated tree, the interface_array/Interfaces and module_array/Modules containers are not populated, as expected since the non-elaborated tree doesn't have the blasted view of these arrays.

Hope this clarifies the confusion.

[hs-apotell]

Do they have the same ID as the actual module instance parented to the parent module?

Yes, they have the same ID. The entries you have shown in your comment are elements of module_array/Modules container. This container holds references to the instantiated modules after blasting the array.

This is happening in UHDMWriter.cpp:L3493-L3510 here in this change.

[hs-apotell]

All of these vpiModule entries are not new instances. They are pointers to the existing instances in the elaborated tree. module_array/Modules holds references to all the instantiated module.

[hs-apotell]

@alaindargelas Our discussion was paused without a conclusion. This PR still has the interface_array and module_array in elaborated tree. If you still disagree that this is incorrect, please let me know so I can update it and repost the change. I need to follow up this with other xxx_array for non-elaborated tree which is likely to use #3101 and this PR as a model.

I would highly recommend reviewing your own change in #3101 and this PR closely before making a conclusion. The instances of interface_array and module_array are unique and interface_array/vpiInterface and module_array/vpiModule are not new instances but are references to existing instance so there is no duplication.

[alaindargelas]

Do they have the same ID as the actual module instance parented to the parent module?

Yes, they have the same ID. The entries you have shown in your comment are elements of module_array/Modules container. This container holds references to the instantiated modules after blasting the array.

This is happening in UHDMWriter.cpp:L3493-L3510 here in this change.

OK, got it now. Thanks for the detailed explanation. I'll merge.

[alaindargelas]

@hs-apotell update UHDM in this branch, I commented the non-standard extension -> conflict in UHDM