[Seq] Add a new pass to sink clock_gate ops to the users #7474

prithayan · 2024-08-08T22:00:53Z

This is a new pass that sinks seq.clock_gate into its users and attempts to remove as many seq.clock_gate ops as possible.

Any operation that can potentially encode the enable directly, will replace its gated clock with the un-gated clock and encode the clock gate enable as the operation's enable signal.
Currently only the CompRegOp operation is handled, but similar transformation needs to be attempted on other supported operations also.

The first phase of the pass is a global transformation that continues to push the clock gates into the referenced modules, until none of the instance ops are driven by a gated clock.
Next, best effort is made to remove the gated clock and encode the enable directly into the operation that is being driven by the clock.

fabianschuiki

Awesome! This is a very useful transform 😍. Does the code also work if a module is instantiated multiple times? And if one of the instances has a clock gate in front and the other does not?

fabianschuiki · 2024-08-09T16:17:22Z

lib/Dialect/Seq/Transforms/SinkClockGates.cpp

+  /// Combine two consecutive clock_gate ops, into one.
+  void collapseConsecutiveClockGates(ClockGateOp driverGate,
+                                     ClockGateOp userGate) {
+    mlir::OpBuilder builder(context);
+    builder.setInsertionPoint(userGate);
+    Value enable = getEnable(driverGate);
+    enable = builder.create<comb::AndOp>(userGate->getLoc(), enable,
+                                         userGate.getEnable());
+    userGate.getInputMutable().assign(driverGate.getInput());
+    userGate.getEnableMutable().assign(enable);
+  }


This is very neat! Might also make sense as a canonicalization on ClockGateOp.

Good idea, will add another PR to add this pattern.

fabianschuiki · 2024-08-09T16:21:02Z

lib/Dialect/Seq/Transforms/SinkClockGates.cpp

+  /// If the clock_gate op has `test_enable`, combine it with the `enable` and
+  /// return the final enable.
+  Value getEnable(ClockGateOp clkGate) {
+    Value enable = clkGate.getEnable();
+    // If there is testEnable, or it.
+    if (auto testEnable = clkGate.getTestEnable()) {
+      OpBuilder builder(clkGate.getContext());
+      builder.setInsertionPointAfter(clkGate);
+      enable =
+          builder.create<comb::OrOp>(clkGate->getLoc(), enable, testEnable);
+    }
+    return enable;
+  }


I'm wondering if we'd need to keep the regular enable and the test_enable separate… probably not?

I asked David, and seems like its okay to combine them. Not sure of other use cases, if that's required then we need two additional ports for every gated clock.

Ah right, good point, forgot about that. I was just wondering of how a user might expect the pass to behave in CIRCT -- someone could expect that the enable inputs would be preserved as separate signals. But on the other hand this is also very easy to adjust once the pattern of the pass is established, and this comes up as a concrete need. Combining them feels like a good start!

lib/Dialect/Seq/Transforms/SinkClockGates.cpp

uenoku · 2024-08-13T16:20:12Z

lib/Dialect/Seq/Transforms/SinkClockGates.cpp

+      auto clkGate = dyn_cast_or_null<ClockGateOp>(in.getDefiningOp());
+      if (!clkGate)


This seems like a bit fragile since it could break analysis when there is wire between instance and clock.

As you pointed out, this would require a fixed-point analysis to handle all the possible dataflow operations that can propagate clocks. I think such operations of passing a clock by a wire are very rare, and it might be fine to ignore them for this transformation. This transformation does not guarantee that all clock gates will be removed. I want to do some more experiments with this transformation enabled, and then based on the need, we can utilize a fixed-point analysis.

uenoku · 2024-08-14T11:27:19Z

And if one of the instances has a clock gate in front and the other does not?

Yeah I think this transformation requires fixed-point analysis whose lattice is a pair of clock and enable.

prithayan · 2024-08-14T19:51:19Z

Thanks a lot @fabianschuiki and @uenoku for the feedback.
The major issue in the previous iteration was multiple instances.
I have handled that in this version.
The other concern regarding the precision of this analysis, this is intended as a fast/simple and best-effort analysis, so its okay to miss a few clock_gates. We donot intend to eliminate all the clock gates.
Additionally clock_gates to some public-modules/extern-modules cannot be removed.
As Hideto suggested, I am also working on a fixed-point analysis that we might utilize if the need for it arises.

Please take another look at it.

dtzSiFive

Cool! This is neat! 😁 🎉

Left some minor feedback.

include/circt/Dialect/HW/HWStructure.td

include/circt/Dialect/Seq/SeqPasses.td

lib/Dialect/Seq/Transforms/SinkClockGates.cpp

uenoku · 2024-08-16T08:04:43Z

include/circt/Dialect/HW/HWStructure.td

+    void appendPorts(
+                  ArrayRef<std::tuple<StringAttr, Type, Location>> insertInputs,
+                  ArrayRef<std::pair<StringAttr, Value>> insertOutputs);


What's difference from modifyPorts which we are going to deprecate?

Good point, thanks for bringing it up, I will add comments.
Few reasons,

Stop using the deprecated methods.

Implement a simpler API, that only appends the input and then output ports, the most-common/only use case. Avoids the generic methods, that can insert/delete at random port indices.

Avoid any performance foot-guns, the deprecated methods can have performance issues, implementing the fresh API that we discuss and properly inspect to ensure there are no obvious performance issues.

At least rhodium can stop using the deprecated API, and switch to this, if its approved.
I will commit this separately, so if it makes sense to discuss this more broadly, I will create a new PR with this change.
What do you think ?

Sorry for delayed replay. TBH I don't find much difference between deprecated functions. The intention for the deprecation was "it doesn't make sense to have an API which takes input and output ports separately" (

circt/lib/Dialect/HW/HWOps.cpp

Lines 675 to 679 in 5d8cf69

/// This is marked deprecated as it's only used from HandshakeToHW and

/// PortConverter and is likely broken and not currently tested. Users of this

/// are still written dealing with input and output ports separately, which is

/// an old and broken style.

[[deprecated]] static void

) so I'm not sure it's a right direction.

Thanks for your suggestions Hideto, I updated the interface, we need the output Values to update the OutputOp also added the input values, that can be set as the block arguments are added. This avoids the need to know the argument index of the input args.

lib/Dialect/Seq/Transforms/SinkClockGates.cpp

uenoku · 2024-08-16T12:41:27Z

lib/Dialect/Seq/Transforms/SinkClockGates.cpp

+  SmallVector<StringAttr> getInstanceArgNames(HWInstanceLike inst) {
+    SmallVector<StringAttr> argNames;
+    if (auto args = inst->getAttrOfType<ArrayAttr>("argNames")) {
+      auto attr = args.getAsRange<StringAttr>();
+      argNames.insert(argNames.begin(), attr.begin(), attr.end());
+    }
+    return argNames;
+  }


Could you add argNames getter to HWInstanceLike. I guess all operations that implement HWInstanceLike have non-optional argNames

lib/Dialect/Seq/Transforms/SinkClockGates.cpp

uenoku · 2024-08-16T12:51:17Z

lib/Dialect/Seq/Transforms/SinkClockGates.cpp

+    if (auto compReg = dyn_cast<CompRegOp>(gatedOp)) {
+      Value clk = compReg.getClk();
+      auto gate = dyn_cast_or_null<ClockGateOp>(clk.getDefiningOp());
+      if (!gate)
+        continue;
+      clk = gate.getInput();
+      Value enable = getEnable(gate);
+      OpBuilder builder(context);
+      builder.setInsertionPoint(compReg);
+      auto compEn = builder.create<CompRegClockEnabledOp>(
+          compReg->getLoc(), compReg.getInput(), clk, enable,
+          compReg.getNameAttr(), compReg.getReset(), compReg.getResetValue(),
+          compReg.getPowerOnValue(), compReg.getInnerSymAttr());
+      compReg->replaceAllUsesWith(compEn);
+      opsToErase.insert(compReg);
+    }


I think this should go to canonicalization if it's always beneficial.

Yeah, I thought about that, but as you pointed out, I don't think this is "beneficial" in all cases. This should only happen if the user explicitly enables this transformation. So, the transformation of "sink clock-gates" implies trying to combine the clock gate's enable into the operation that is driven by the gated clock. This might not be desirable in general, and if we add it to the canonicalization we can't disable it in general.
But maybe this can be added to some op interface. A new op interface that any op can opt-in, and then we can invoke it from here.
My plan is to add the enable to FirRegOp next, similar transformation needs to happen to memory ops also, but its semantics are slightly non-trivial.

uenoku

What do you think about decoupling canonicalization from this pass? I feel it looks more cleaner if SinkClockGates only sinks clock gates and not perform comp reg simplification.

uenoku · 2024-08-16T12:55:37Z

lib/Dialect/Seq/Transforms/SinkClockGates.cpp

+        auto oldEnablePort = clockEnablePortIndices[index];
+        auto oldEnableVal = inst->getOperand(oldEnablePort);
+        auto *def = oldEnableVal.getDefiningOp();
+        assert(llvm::isa_and_nonnull<ConstantOp>(def));


Why is it guaranteed to be constant?

This is a constant, because this is another instance of a module that is already visited. When the first instance was visited, we added the enable port to all the module instances. The enable port for all the other instances were set to a constant true, except the one that is being visited, which is set to the clock gate op's enable. This ensures that we donot add multiple enable ports for the same clock gate port when visiting multiple instances of a module.

lib/Dialect/Seq/Transforms/SinkClockGates.cpp

prithayan requested review from uenoku and fabianschuiki August 8, 2024 22:03

fabianschuiki reviewed Aug 9, 2024

View reviewed changes

uenoku reviewed Aug 13, 2024

View reviewed changes

prithayan force-pushed the dev/pbarua/sink-clock-gates branch from 7768308 to c7503c9 Compare August 14, 2024 19:47

prithayan requested review from fabianschuiki and uenoku August 14, 2024 19:57

dtzSiFive reviewed Aug 15, 2024

View reviewed changes

prithayan force-pushed the dev/pbarua/sink-clock-gates branch from c7503c9 to 28d5a67 Compare August 15, 2024 21:33

prithayan marked this pull request as ready for review August 15, 2024 21:41

prithayan requested a review from darthscsi as a code owner August 15, 2024 21:41

uenoku reviewed Aug 16, 2024

View reviewed changes

lib/Dialect/Seq/Transforms/SinkClockGates.cpp Outdated Show resolved Hide resolved

uenoku reviewed Aug 16, 2024

View reviewed changes

lib/Dialect/Seq/Transforms/SinkClockGates.cpp Outdated Show resolved Hide resolved

uenoku reviewed Aug 16, 2024

View reviewed changes

lib/Dialect/Seq/Transforms/SinkClockGates.cpp Outdated Show resolved Hide resolved

uenoku reviewed Aug 16, 2024

View reviewed changes

lib/Dialect/Seq/Transforms/SinkClockGates.cpp Show resolved Hide resolved

uenoku reviewed Aug 16, 2024

View reviewed changes

lib/Dialect/Seq/Transforms/SinkClockGates.cpp Outdated Show resolved Hide resolved

prithayan force-pushed the dev/pbarua/sink-clock-gates branch from 28d5a67 to bdf3452 Compare August 22, 2024 13:07

prithayan added 6 commits August 22, 2024 09:46

[HW] Add an API to append ports to HWModuleOp

782620b

[Seq] Add a new pass to sink the clock_gate ops

6496fb9

Handle multiple instances of a module

7765e25

Address review comments

37c4fc2

Address review comments

c278d87

Update appendPorts interface, to combine input and output ports

9d876f0

prithayan force-pushed the dev/pbarua/sink-clock-gates branch from bdf3452 to 9d876f0 Compare August 23, 2024 17:07

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Seq] Add a new pass to sink clock_gate ops to the users #7474

[Seq] Add a new pass to sink clock_gate ops to the users #7474

prithayan commented Aug 8, 2024

fabianschuiki left a comment

fabianschuiki Aug 9, 2024

prithayan Aug 14, 2024

fabianschuiki Aug 9, 2024

prithayan Aug 14, 2024

fabianschuiki Aug 15, 2024

uenoku Aug 13, 2024

prithayan Aug 14, 2024

uenoku commented Aug 14, 2024

prithayan commented Aug 14, 2024

dtzSiFive left a comment

uenoku Aug 16, 2024

prithayan Aug 16, 2024 •

edited

Loading

uenoku Aug 21, 2024

prithayan Aug 23, 2024

uenoku Aug 16, 2024

uenoku Aug 16, 2024

prithayan Aug 16, 2024

uenoku left a comment

uenoku Aug 16, 2024

prithayan Aug 16, 2024

		auto clkGate = dyn_cast_or_null<ClockGateOp>(in.getDefiningOp());
		if (!clkGate)

	/// This is marked deprecated as it's only used from HandshakeToHW and
	/// PortConverter and is likely broken and not currently tested. Users of this
	/// are still written dealing with input and output ports separately, which is
	/// an old and broken style.
	[[deprecated]] static void

[Seq] Add a new pass to sink clock_gate ops to the users #7474

Are you sure you want to change the base?

[Seq] Add a new pass to sink clock_gate ops to the users #7474

Conversation

prithayan commented Aug 8, 2024

fabianschuiki left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

uenoku commented Aug 14, 2024

prithayan commented Aug 14, 2024

dtzSiFive left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

prithayan Aug 16, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

uenoku left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

prithayan Aug 16, 2024 •

edited

Loading