'pipeline' Dialect

Operation definition

pipeline.latency (::circt::pipeline::LatencyOp)

Pipeline dialect latency operation.

Syntax:

operation ::= `pipeline.latency` $latency `->` `(` type($results) `)` $body attr-dict

The pipeline.latency operation represents an operation for wrapping multi-cycle operations. The operation declares a single block wherein any operation may be placed within. The operation is not IsolatedFromAbove meaning that the operation can reference values defined outside of the operation (subject to the materialization phase of the parent pipeline).

Traits: HasOnlyGraphRegion, HasParent<UnscheduledPipelineOp, ScheduledPipelineOp>, SingleBlock, SingleBlockImplicitTerminator

Interfaces: RegionKindInterface

Attributes:

Results:

pipeline.latency.return (::circt::pipeline::LatencyReturnOp)

Pipeline latency return operation.

Syntax:

operation ::= `pipeline.latency.return` ($inputs^)? attr-dict (`:` type($inputs)^)?

The pipeline.latency.return operation represents a terminator of a pipeline.latency operation.

Traits: HasParent, Terminator

Operands:

pipeline.return (::circt::pipeline::ReturnOp)

Pipeline dialect return.

Syntax:

operation ::= `pipeline.return` ($inputs^)? attr-dict (`:` type($inputs)^)?

The “return” operation represents a terminator of a pipeline.pipeline.

Traits: HasParent<UnscheduledPipelineOp, ScheduledPipelineOp>, Terminator

Operands:

pipeline.scheduled (::circt::pipeline::ScheduledPipelineOp)

Scheduled pipeline operation

The pipeline.scheduled operation represents a scheduled pipeline. The pipeline contains a single block representing a graph region.

A pipeline.scheduled operation can exist in multiple phases, mainly pertaining to when registers have been materialized (made explicit). For an in-depth explanation, please refer to the Pipeline dialect rationale.

A pipeline.scheduled supports a stall input. This signal is intended to connect to all stages within the pipeline, and is used to stall the entirety of the pipeline. It is lowering defined how stages choose to use this signal, although in the common case, a stall signal would typically connect to the clock-enable input of the stage-separating registers.

The go input is used to start the pipeline. This value is fed through the stages as the current stage valid/next stage enable signal. Note: the op is currently only designed for pipelines with II=1. For pipelines with II>1, a user must themselves maintain state about when the pipeline is ready to accept new inputs. We plan to add support for head-of-pipeline backpressure in the future.

Any value defined outside the pipeline is considered an external input. An external input will not be registered.

The pipeline may optionally be provided with an array of bits stallability which is used to determine which stages are stallable.

• If not provided and the pipeline has a stall signal, all stages are stallable.
• If provided, and the pipeline has a stall signal, the number of bits must match the number of stages in the pipeline. Each bit represents a stage, in the order of which the stages appear wrt. the pipeline.stage operations. A bit set to 1 indicates that the stage is stallable, and 0 indicates that the stage is not stallable.

The exit (non-registered) stage of a pipeline cannot be non-stallable, and will always follow the stallability of the parent pipeline.

For more information about non-stallable stages, and how these are lowered, please refer to the Pipeline dialect rationale.

Traits: AlwaysSpeculatableImplTrait, AttrSizedOperandSegments

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface), OpAsmOpInterface, RegionKindInterface

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

pipeline.stage (::circt::pipeline::StageOp)

Pipeline stage terminator.

Syntax:

operation ::= `pipeline.stage` $nextStage
              custom<StageRegisters>($registers, type($registers), $clockGates, $clockGatesPerRegister, $registerNames)
              custom<Passthroughs>($passthroughs, type($passthroughs), $passthroughNames)
              attr-dict

The pipeline.stage operation represents a stage terminator. It is used to communicate:

1. which stage (block) to transition to next
2. which registers to build at this stage boundary
3. which values to pass through to the next stage without registering
4. An optional hierarchy of boolean values to be used for clock gates for each register.

• The implicit ‘!stalled’ gate will always be the first signal in the hierarchy. Further signals are added to the hierarchy from left to right.

Example:

pipeline.stage ^bb1 regs(%a : i32 gated by [%foo, %bar], %b : i1) pass(%c : i32)

Traits: AlwaysSpeculatableImplTrait, AttrSizedOperandSegments, HasParent, Terminator

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Successors:

pipeline.unscheduled (::circt::pipeline::UnscheduledPipelineOp)

Unscheduled pipeline operation

The “pipeline.unscheduled” operation represents a pipeline that has not yet been scheduled. It contains a single block representing a graph region of operations to-be-scheduled into a pipeline. Mainly serves as a container and entrypoint for scheduling.

The interface of a pipeline.unscheduled is similar to that of a pipeline.scheduled. Please refer to this op for further documentation about the interface signals.

Traits: AlwaysSpeculatableImplTrait, AttrSizedOperandSegments, HasOnlyGraphRegion, SingleBlock, SingleBlockImplicitTerminator

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface), OpAsmOpInterface, RegionKindInterface

Effects: MemoryEffects::Effect{}

Attributes:

Operands:

Results:

'pipeline' Dialect Docs

• Pipeline Dialect Rationale