You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently if I write SystemVerilog that uses packed struct types for e.g.: a module input, Surelog will compile that to an input with bitwidth equal to the width of the packed struct, and struct field accesses will become part selects of the bitvector.
An alternative, which may often be easier to understand and process, is to compile the struct fields to multiple inputs/outputs. This would happen recursively and terminate at types that are not struct types (non-struct types would be handled the same way structs currently are). It would be an optional and likely non-default mode of elaboration.
Surelog should avoid applying this transformation to any blackboxed modules as well as the top level module, so that the output of compilation can still be connected to other designs that may not have had this transformation applied. It might also be reasonable to optionally automatically generate wrapper modules around any blackboxed modules when this is enabled, so that the wrapper module can be transformed in this way even though the blackboxed one is not.
The text was updated successfully, but these errors were encountered:
Currently if I write SystemVerilog that uses packed struct types for e.g.: a module input, Surelog will compile that to an input with bitwidth equal to the width of the packed struct, and struct field accesses will become part selects of the bitvector.
An alternative, which may often be easier to understand and process, is to compile the struct fields to multiple inputs/outputs. This would happen recursively and terminate at types that are not struct types (non-struct types would be handled the same way structs currently are). It would be an optional and likely non-default mode of elaboration.
Surelog should avoid applying this transformation to any blackboxed modules as well as the top level module, so that the output of compilation can still be connected to other designs that may not have had this transformation applied. It might also be reasonable to optionally automatically generate wrapper modules around any blackboxed modules when this is enabled, so that the wrapper module can be transformed in this way even though the blackboxed one is not.
The text was updated successfully, but these errors were encountered: