Relax or simplify channel connectivity requirements for integration of sub-procs

[mikex-oss]

What's hard to do? (limit 100 words)

When updating a sub-proc interface (adding some channels exposed to config), it appears you need to plumb the channels all the way through -- this includes not only declaring the channels in the parent config and passing it down to the spawned sub-proc instantiation but also requires explicit send/receive nodes on the channel -- in order for the parent proc to build.

I think this can be a bit of undue friction for "IP integration" (I'm referring to both initial and version updates) when we start building stuff in XLS at scale.

In my experience, it's common in normal top-level construction methodology that chip top engineers focus on a few functional buses to enable DV and don't want to have to try to connect everything correctly at once.

The channel connectivity requirements in XLS are reminiscent of a similar behavior in EDA tools with SV interface ports, which can't be left unconnected in module instantiations. E.g. VCS will error with:

[Error-[SV-UIP] Unconnected interface port, the port “my_if” of top-level module "my_module” whose
type is interface MY_INTERFACE is left unconnected. It is illegal to leave the interface ports unconnected.
Please make sure that all interface ports are connected.]

However, for regular ports, top level construction aggressively use tie offs and unread sinks to avoid this extra connectivity. The use of SV interfaces in my previous org was blocked by this issue with interface connectivity until a custom flow was developed to handle "floating interfaces".

Current best alternative workaround (limit 100 words)

Currently, you need to fully hook up the new channels in the parent proc, including at least one (fake) send (for input) or receive (for output).

One pattern I've seen to satisfy the mandatory send/receive node seems to be:

recv_if(tok, new_channel_in, false, zero!<chan_type>());
send_if(tok, new_channel_out, false, zero!<chan_type>()); 

Your view of the "best case XLS enhancement" (limit 100 words)

It's probably reasonable to require the spawned proc instantiation to contain the new channel args (similar to adding a new argument to a function), but it would be helpful to be able to isolate updates to these instantiations and say "I don't want to do anything with these channels at this point".

As an incremental step, it would be nice to have the requirement on having a send/receive node turned into a warning that could be downgraded instead of an invalid program.

As a bigger step, I wonder if there could be some syntactic sugar added to DSLX that just creates placeholder boilerplate for the user.

[richmckeever]

There's a proposal we are working on to change the proc model so that a proc creates the channels you use to interface with it, rather than the spawner creating them; and a proc would only expose the channel ends that external code should use (e.g. not the read end of a channel the proc's own next function reads).

I think this would mitigate the problem you are talking about, because you would not fundamentally need to change a spawner if you create new channels in a spawnee. Then we would just need a way for the spawnee to declare that it doesn't care whether you ever interact with some particular exposed channel end (or perhaps a way to make a blanket declaration to that effect in a spawner target).