Verilog codegen for tuple outputs should retain their structure

[ted-xie]

I have a DSLX function that returns a tuple of type (u1, u8). The tuple fields are called (result, state). I would expect the emitted verilog to look like this:

output wire result,
output wire [7:0] state

Instead, I get a packed bit vector called output wire [8:0] out.

This is still usable, but generally it would be easier to integrate the generated code if the fields were unpacked into separate output ports.

[vincent-mirian-google]

A brief comment: perhaps, a feature request for multiple return values may be a more suited as a general solution, each return value can be assigned to a port.

[cdleary]

cc @meheff I think the reworking he's doing of codegen pipeline could tie in with how tuples or records (named tuples) end up presented on the module signature. Mark thoughts on where this one will fit? (I thought we had another issue open for this but can't find it!) This relates to #195

[allight]

We might want to build off of the work done on #1239 to support this.

We could have an annotation on structs/etc #[verilog_export("name")].

We would need to decide how to pass this down to the codegen. The easiest way might be to have the ir_convert do the verilog generation of the struct and pass it down in a field in the ir-interface proto. This is sort of ugly however.

@proppy any ideas?

[proppy]

@allight I was thinking of something like what was suggested in #1433 (as a follow-up to #1429) where we have fn annotations to name the return arguments, ex:

#[output_port_name(foo, bar, hop)]
fn user_module() -> (u1, u2, u3) {
}

or

#[named_return]
fn user_module() -> (foo: u1, bar: u2, hop: u3) {
}

would codegen:

module user_module(
    output wire foo,
    output wire [1:0] bar,
    output wire [2:0] hop
);