Channel legalization is starting to feel like proc inlining more and more, both because it's big and because it does a lot of surgery on channels. It can be unclear when a channel needs an adapter and if you want different semantics for your arbitration, it may be a big undertaking.
Current best alternative workaround (limit 100 words)
Explicitly make bespoke arbiters.
Your view of the "best case XLS enhancement" (limit 100 words)
It would be nice if DSLX were expressive enough to write an arbiter nicely. This requires type-generics (#1646) and some thought on how frontends should handle multiple channel ops- for DSLX, we might require users to explicitly instantiate arbiters and expect language features to make this convenient enough that it isn't a burden. For XLScc, the current model could be evolved via something like #1638- instead of the current behavior (marking channel strictness), you'd use the same configuration to decide which adapter to insert from the beginning.
What's hard to do? (limit 100 words)
Channel legalization is starting to feel like proc inlining more and more, both because it's big and because it does a lot of surgery on channels. It can be unclear when a channel needs an adapter and if you want different semantics for your arbitration, it may be a big undertaking.
Current best alternative workaround (limit 100 words)
Explicitly make bespoke arbiters.
Your view of the "best case XLS enhancement" (limit 100 words)
It would be nice if DSLX were expressive enough to write an arbiter nicely. This requires type-generics (#1646) and some thought on how frontends should handle multiple channel ops- for DSLX, we might require users to explicitly instantiate arbiters and expect language features to make this convenient enough that it isn't a burden. For XLScc, the current model could be evolved via something like #1638- instead of the current behavior (marking channel strictness), you'd use the same configuration to decide which adapter to insert from the beginning.