[Pipeline] Representing register reset values

[mortbopet]

We need a way to represent register reset (power on) values in the pipeline dialect.
Say that we have the following pipeline:

  %0:2 = pipeline.scheduled(%arg0, %arg1, %go) clock %clk reset %rst : (i32, i32, i1) -> (i32, i1) {
  ^bb0(%arg0_0: i32, %arg1_1: i32, %arg2: i1):
    %true = hw.constant true
    %1 = comb.sub %arg0_0, %arg1_1 : i32
    pipeline.stage ^bb1 regs(%1, %arg0_0, %arg2 : i32, i32, i1) enable %arg2
  ^bb1(%2: i32, %3: i32, %4: i1):  // pred: ^bb0
    %5 = comb.add %2, %3 : i32
    pipeline.stage ^bb2 regs(%5, %2 : i32, i32) enable %4
  ^bb2(%6: i32, %7: i32):  // pred: ^bb1
    %8 = comb.mul %6, %7 : i32
    pipeline.return %8, %true : i32, i1
  }

For our immediate usecase (and realistically, for most usecases) we only want to have a power-on value for the control (stage enable) values of a pipeline. However, given the current design of the pipeline, stage enable signals don't carry any special notion - they can be any value defined within a given stage (i.e. an op result or a stage input).

Is this a good design point? Thinking about it, it feels like this is some leftover gunk from when the pipeline was supposed to be able to represent latency insensitive pipelines. In other words, does it make sense that a pipeline stage has the ability to stall (e.g. not assert the enable signal for its following stage) but has no way to backpressure?

As such, would it make sense that a pipeline has a single top level control ("go") signal which is strung through each of the pipeline stages? Doing this, we would

1. always know which value will be the corresponding control signal for a given stage (could be useful if we want to have memory operations within a stage)
2. have full control over the registering of said control value, and thus easily assign it a reset value.
3. Also have the option to add a "done" signal to the output of the pipeline.

The above code, wherein %arg2 is used as the control signal, would become:

%out, %done = pipeline.scheduled(%arg0, %arg1) clock %clk reset %rst go %go : (i32, i32) -> (i32) {
  ^bb0(%arg0_0: i32, %arg1_1: i32, %s0_valid : i1):
    %true = hw.constant true
    %1 = comb.sub %arg0_0, %arg1_1 : i32
    pipeline.stage ^bb1 regs(%1, %arg0_0 : i32, i32)

  ^bb1(%2: i32, %3: i32, %s1_valid : i1):  // pred: ^bb0
    %5 = comb.add %2, %3 : i32
    pipeline.stage ^bb2 regs(%5, %2 : i32, i32)

  ^bb2(%6: i32, %7: i32, %s2_valid : i1):  // pred: ^bb1
    %8 = comb.mul %6, %7 : i32
    pipeline.return %8 : i32
  }

Wherein each stage has an explicit valid signal (i.e. an i1-typed value as the last argument in the stage block argument list) that can be used for anything that requires knowledge of stage validity within the stage. Again, no need to explicitly tell that the valid signals are to be registered, since there is no way that the user can modify this - it is strictly defined by the top-level go input.

With this design, it is then up to the user to only assert the go signal every II cycles.

[blakep-msft]

So this change doesn't explicitly address the feature request of having power on values, rather it adds a first-class "go" signal which controls when a new token can start down the pipeline, and adds automatic registering of that go signal for each pipeline stage.

This makes sense to me. I think it is important to support the ability to stall the pipeline (stop tokens which are part way down the pipe). This leads me to believe there should be 2 top-level signals:

• go - controls when a new token should be initiated (execute in the first stage)
• stall - controls if all existing tokens should stay where they are, or move to the next stage

[mortbopet]

This leads me to believe there should be 2 top-level signals

which seems natural to me.

I should have elaborated the initial post with saying that we can add register reset values in the current abstraction, however, it's then up to the user to explicitly denote which registers needs to be reset to what. That is, the user then manually have to do a lot of work wrt. tracking which register is actually used as an enable value, assign resets to that, and do that for every stage in the pipeline.

[blakep-msft]

I agree, I think the fact that this design avoids the manual work is a good thing.

[teqdruid]

I agree with the two input control signals. My only objections/concerns are the naming and semantics (which I think we need to define more precisely). What's the difference between 'go' and 'valid'? Aren't they both describing the validity? Would it be an error to assert valid when the pipeline isn't ready to accept new tokens? Under what conditions would it be an error to assert go? How do those interact with the stall signal?

BTW: once we decide on these error conditions, it'd be great to have the lowering produce asserts to test them at simulation time.

@blakep-msft Do you really want 'stall' to freeze all the stages where they are or do you want it to be a form of backpressure. i.e. stall the last stage, but any stages without a valid token in the next stage can proceed?

[mortbopet]

What's the difference between 'go' and 'valid'? Aren't they both describing the validity?

The motivation for the two names here are that 'go' implies starting a full pipeline run, whereas the inter-stage valid signal 'just' relates to the validity of a given stage. I'm indifferent about calling the top-level signal 'go' or 'enable', but 'valid' seems less descriptive.

Would it be an error to assert valid when the pipeline isn't ready to accept new tokens?

In this model, yes. I'd imagine that at some point soon we'll encounter pipelines without II=1, so we have to think about this anyways. Under the assumption that the II is known, its an option to wrap the pipeline in some stateful logic that is able to backpressure the head of the pipeline.

Regardless, i think the change proposed here is in the direction that we want to go in, so I'll go ahead and type something up.