Open leonardt opened 4 years ago
If the user specifies verilog instead of systemverilog, the 'flattentypes" pass could be run so that we do not run into the ND-array issues.
Actually, it seems like we should do this at the coreir level, since we just pass the ndarray argument through. So we could just handle it there (the same issue applies for the .sv
versus .v
by default though)
@rdaly525 yes, there's already a disable_ndarray
option in magma and disable-ndarray
flag for flattentypes in coreir that will flatten ndarrays and generate verilog compatible code (no unpacked arrays)
By default, we should use a
.sv
file name if we generated ndarrays using unpacked arrays (since this is a system verilog feature). This should make it easier for downstream tools to consume the generated code with the right language features enabled. We could generate a regular.v
file if verilog ndarrays are disabled. We should consider whether we should inspect the hierarchy for presence of ndarrays and choose.sv
or just generate.sv
by default (easier) and have a flag to force.v
(e.g. if a user is using a toolchain that requires verilog rather than sv)