Allowing invokes to pass in subtypes to ref cells

[nathanielnrn]

A synchronous discussion today with @sampsyo and @eys29 led to discussion about ref cells accepting components that are subtypes of their declared "type". We would need to think through the implications, but it feels like this could be an interesting topic to pursue in the future.

This came up in the context of our dynamic axi generator discussion. In particular, we are creating an "axi-seq-mem" that has the interface of a seq_mem, along with ports that conform with the AXI protocol.

Consider a seq_mem with ports addr0, write_data, read_data, content_en, and write_en.

An axi_seq_mem has all of these ports, and a bunch more.

It could be useful to have calyx accept the following as a valid program

// This is not actually needed, but describes the interface of a seq_mem
component seq_mem(addr0, write_data, write_en, content_en) -> (read_data){
  // stuff...
}

component axi_seq_mem(addr0, write_data, write_en, content_en,...<more ports>...) -> (read_data,...<more ports>...){
 // more stuff...
}

component foo () -> () {
  cells {
    ref my_seq_mem = seq_mem(32, 1, 1);
  }
  // groups and control...
}

component bar () -> () {
  cells{
    my_axi_mem = axi_seq_mem(32,1,1); // Would this need to be a primitive to parameterize like this?
  // groups
  control {
    invoke foo[my_seq_mem = axi_seq_mem]()();
  }

Note that we pass in an axi_seq_mem to the foo component instead of a seq_mem.
Also note that the parameterization would need to be the same between the two, which I believe is only available for primitives? Which may limit the utility of allowing this kind of subtyping.
EDIT: I forgot we can just look at bitwidths of ports as a proxy for parametrization, and this is probably closer to what we actually want.

Either way, would be happy to hear any and all thoughts on this!

[rachitnigam]

I would remove the requirement that the parameters need to be the same and just focus on the names and bitwidths of ports.