Proper Way to Have Multiple Channel Ops Per Channel (DSLX)

[AyanaAlemayehu]

Hello! I have been writing some state machines in DSLX that interact with external memories, writing DSLX test procs to verify correctness. An example of these state machines is below:

pub proc external_memory_reader{

    payload_type_one:                       chan<uN[64][u32: 2]> in;
    payload_type_one_addr:                 chan<u32> out;

    config(
        payload_type_one:                   chan<uN[64][u32: 2]> in,
        payload_type_one_addr:             chan<u32> out,
    ) {
        (
            payload_type_one,
            payload_type_one_addr
        )
    }

    init {(
        u32: 10,                    
        join()                 
    )}

    next (state: (u32, token)) {
        //
        //  ...
        //  ...
        //  N-1 other states...
        //  ...
        //  ...
        //

        // state N
        // substate N.0
        let state_N_zero = state.0 == u32: 10;
        let new_tok = send_if(state.1, payload_type_one_addr, state_N_zero, u32: 0);
        let (new_tok, _) = recv_if(new_tok, payload_type_one, state_N_zero, zero!<uN[64][u32: 2]>());
        let next_state =
        if (state_N_zero) {(u32: 11, state.1)}
        else { state };
        // substate N.1
        let state_N_one = (state.0 == u32: 11);
        let new_tok = send_if(new_tok, payload_type_one_addr, state_N_one, u32: 0 + u32: 1);
        let (new_tok, _) = recv_if(new_tok, payload_type_one, state_N_one, zero!<uN[64][u32: 2]>());
        let next_state = 
        if (state_N_one) {(u32: 2, new_tok)}
        else { next_state };
        // end of state N


        //
        //  ...
        //  ...
        //  the rest of the states...
        //  ...
        //  ...
        //


        (next_state)
    }

}

I moved on to trying to generate verilog from these procs after verifying their correctness. However, when I try running the opt_main tool, I fail the channel_legalization pass with this output:

Error: INTERNAL: XLS_RET_CHECK failure (xls/solvers/z3_ir_translator.cc:1443) ty->IsTuple() ; 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]

I am having a hard time understanding how to fix the state machines I have written given this error message. As seen in the example, I have tried using predicates to ensure only one send or receive of a channel is running in a given activation (the predicates being state_N_zero and state_N_one), though that does not seem to be enough.

Also, having looked at the worked example in the documentation and compared it with my example, it seems fairly close to mine. So, I was hoping to learn where I went wrong that caused my example to fail to compile.

[allight]

Hm looks like we just forgot to handle bare-tokens in the ir-translator in FromLeafTypeTree probably. Not sure how it got past our tests though we don't use either token state elements or multiple channel ops that much so it might have just been lurking.

[allight]

Bug report version of this over at #3738

[proppy]

@allight thanks for the ack!

@AyanaAlemayehu, slightly off-topic but I'm curious if you've attempted to rewrite this using https://google.github.io/xls/dslx_reference/#match-expression?

    next (state: (u32, token)) {
        match (state.0) {
          u32:10 => {
            let new_tok = send(state.1, payload_type_one_addr, u32: 0);
            let (new_tok, _) = recv(new_tok, payload_type_one);
            (u32: 11, state.1)
          },
          u32:11 => {
            let new_tok = send(state.1, payload_type_one_addr, u32: 0 + u32: 1);
            let (new_tok, _) = recv(new_tok, payload_type_one);
            (u32: 2, new_tok)
          },
          _ => {
            state
          },
        }
    }

[AyanaAlemayehu]

The original state machine this example was derived from used a chain of if else-if else clauses (which caused the same ty->IsTuple() error) and in an attempt to try to fix the problem I switched to using send_if. I pasted in the match expression example you provided and received the same error

[AyanaAlemayehu]

@proppy Actually, I wrote my example wrong and meant to have state u32:10 return (u32: 11, new_tok). When I modify your example to include this edit:

 next (state: (u32, token)) {
        match (state.0) {
          u32:10 => {
            let new_tok = send(state.1, payload_type_one_addr, u32: 0);
            let (new_tok, _) = recv(new_tok, payload_type_one);
            (u32: 11, new_tok) // <-- changed state.1 to new_tok
          },
          u32:11 => {
            let new_tok = send(state.1, payload_type_one_addr, u32: 0 + u32: 1);
            let (new_tok, _) = recv(new_tok, payload_type_one);
            (u32: 2, new_tok)
          },
          _ => {
            state
          },
        }
    }

I get this error at codegen:
Error: INTERNAL: Expected one_hot_sel.473 to not contain a token in its type; type is token
(I also get this when using my original discussion example with if statements).

I saw this commit that seems to imply that match arms are not allowed to return tokens. Does that mean I cannot use match arms/if else chains in this way?

[allight]

No that should be allowed. It's just that there's another bug with tokens in match.