Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Seq] Canonicalize transitive clock gates #5504

Merged
merged 3 commits into from
Jul 6, 2023

Conversation

mortbopet
Copy link
Contributor

This adds a folder for clock gates which removes clock gates that are transitively enable'd by other clock gates in a clock gate hierarchy.

This adds a folder for clock gates which removes clock gates that are transitively enable'd by other clock gates in a clock gate hierarchy.
Copy link
Contributor

@fabianschuiki fabianschuiki left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, with the small comment on test enable.

Comment on lines 720 to 727
// Transitive clock gating - eliminate clock gates that are driven by an
// identical enable signal somewhere in a clock gate hierarchy.
auto clockGateInput = getInput().getDefiningOp<ClockGateOp>();
while (clockGateInput) {
if (clockGateInput.getEnable() == getEnable())
return getInput();
clockGateInput = clockGateInput.getInput().getDefiningOp<ClockGateOp>();
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you also need to check the test_enable here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm... would it then be correct to OR the test_enable of the current clock gate with the TE of the upstream matching clock gate?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I think you could also do that! Or just check if the test enables also agree, not just the regular enable. I'd expect in most designs there is no test enable, or if there is one, it's all connected to one single signal almost everywhere in the hierarchy. So you might not be losing much if you just check for it instead of creating a new comb.or 😃

Copy link
Contributor

@teqdruid teqdruid left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's generally safe (from a power PoV) to remove the one further down the chain but am not completely sure.

@@ -717,6 +717,15 @@ OpFoldResult ClockGateOp::fold(FoldAdaptor adaptor) {
if (isConstantZero(adaptor.getInput()))
return IntegerAttr::get(IntegerType::get(getContext(), 1), 0);

// Transitive clock gating - eliminate clock gates that are driven by an
// identical enable signal somewhere in a clock gate hierarchy.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: "... somewhere higher in the clock..."

@mortbopet mortbopet merged commit 8d02f07 into main Jul 6, 2023
5 checks passed
calebmkim pushed a commit to andrewb1999/circt that referenced this pull request Jul 12, 2023
This adds a folder for clock gates which removes clock gates that are transitively enable'd by other clock gates in a clock gate hierarchy.
@darthscsi darthscsi deleted the dev/mpetersen/clock_gate_opt branch June 4, 2024 14:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants