Current status of multiple IO operations per channel

[rw1nkler]

Hi, I would like to ask about the current support for multiple channel operations in XLS.
In the past, there were several proposals and discussions about how to legalize and handle multiple IO operations per single channel:

• Legalize Multiple Channel Ops Per Channel (v1)
• Legalize Multiple Channel Ops Per Channel (v2)

I was told by @proppy that this support was greatly improved by @ericastor and that multiple non-exclusive (unconditional) sends should be possible.
In that case I would expect that a simple like the one below should work:

proc MultipleIO {
    req0_r: chan<u32> in;
    req1_r: chan<u32> in;
    resp_s: chan<u32> out;

    init {}

    config(
        req0_r: chan<u32> in,
        req1_r: chan<u32> in,
        resp_s: chan<u32> out
    ) { (req0_r, req1_r, resp_s)}

    next(state: ()) {
        let (tok, data) = recv(join(), req0_r);
        let tok = send(tok, resp_s, data);

        let (tok, data) = recv(tok, req1_r);
        let tok = send(tok, resp_s, data);
    }
}

Unfortunately, I receive the following errors:

Error: INVALID_ARGUMENT: Proc __multiple_io__MultipleIO_0_next has two unconditional operations on channel multiple_io__resp_s with no ordering: tok__1 and tok__3; Running pass #236: Legalize multiple send/recvs per channel [short: channel_legalization]; Running pass #236: post-inlining optimization passes [short: post-inlining-opt]; Running pass #236: post-inlining optimization passes [short: post-inlining-opt]; Running pass #236: post-inlining optimization passes when opt_level >= 1 [short: post-inlining-opt(opt_level>=1)]; Running pass #236: min-1 post-inlining optimization passes [short: post-inlining-opt(>=1)]; Running pass #236: Post-inlining passes [short: post-inlining]; Running pass #236: Default pass pipeline [short: default_pipeline]; Running pass #236: Top level pass pipeline [short: ir]

Because of that I have the following questions:

• What is the current state of this functionality?
• Are multiple unconstrained sends fully supported?
• Are there still any limitations or known issues?
• Is this considered stable and ready to use?

Thanks for the clarification.

[ericastor]

Sorry for the slow response; this fell through the cracks.

We have experimental functionality for the v2 proposal in XLS IR, our internal representation, and recently added an experimental way to use it in DSLX: the #[channel_strictness("...")] attribute. For example, if you annotate the channel at the point where it's declared with:

    #[channel_strictness("total_order")]
    resp_s: chan<u32> out;

it is supposed to support multiple operations on this channel when there is a well-defined order in which they should execute (e.g., your example above, due to the token you threaded between the sends). When you get to codegen, if you've left it at the default options, it will correctly complain that it cannot schedule without a relaxed worst-case throughput bound; supporting N operations on a single channel in a single activation requires lowering your throughput to at most 1/N.

This is still very much experimental, rather than considered stable or ready for use. We have some changes coming that we hope will improve it, but we're not yet certain that we've fixed all the issues.

[rw1nkler]

Thank you, I will give it a try!