-
Notifications
You must be signed in to change notification settings - Fork 898
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
dfflibmap: enable inference #4698
Conversation
It would also be okay to skip scan flops. DFT is implemented in OpenROAD, and will replace flops with their scan equivalents. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some drive-by comments from a first read
1a5face
to
430e626
Compare
Should we also extend |
I don't think |
Well, seeing that cells.lib isn't referenced anywhere in the codebase, that certainly raises the question: what does cells.lib have to do with anything? But that's not relevant for this PR specifically. |
|
|
||
if (!parse_pin(cell, ff->find("clocked_on"), cell_clk_pin, cell_clk_pol) || cell_clk_pol != clkpol) | ||
continue; | ||
if (!parse_pin(cell, ff->find("next_state"), cell_next_pin, cell_next_pol)) | ||
if (!parse_next_state(cell, ff->find("next_state"), cell_next_pin, cell_next_pol, cell_enable_pin, cell_enable_pol)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm guessing the enapol
check is missing here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well, yes, but also: none of the cells passed to find_cell_sr
are DFFSREs, so the enable polarity doesn't actually matter. I couldn't find a PDK which has a DFFSRE, but I wanted to leave the infrastructure in to make it easy to add.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In that case I think we should log_assert(!has_enable && "Unimplemented");
even if we are guaranteed not to hit it due to the user code
The build failure should be possible to resolve with a rebase BTW |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- fix the enapol parameter
- fix CI
Functionally seems like a valid approach
6ce0c5f
to
4f40187
Compare
rebased, with |
Unfortunately, when used in ORFS, turns out this feature regresses area usage on ibex on sky130. When Repro: module foo(
input se,
input clk,
input xi,
input [8:0] a,
input [8:0] b,
output xo,
);
// To test with more logic around,
// uncomment and replace se with mod:
// wire mod;
// assign mod = ((a + b) % 7) == 3;
initial begin
xo = 0;
end
always @(posedge clk)
begin
if (se)
xo <= xi;
end
endmodule
I think we have work to do in |
I'm...not sure that's a valid transformation when the enable mux is baked into the flop? But I can see that it can be an issue if the polarity doesn't exactly match. Hmm. |
Yeah the idea is we probably should prevent baking the muxes into dffe PDK cells if it creates an inverter outside the PDK cell |
I'm not so sure about this anymore. The regression doesn't reproduce on commits of this PR branch, because it's based on an older main commit. Hilariously, when qwp was removed, a constid was removed too, which made the ibex synthesize better, but not when DFFEs are inferred. Apparently, the 1% regression we saw is indistinguishable from hash perturbations. Can't wait to have |
On nangate45:
I think we need to demote those to |
What are the reasons/motivation for this change?
dfflibmap
can't map flops with enables, so yosys has to use muxes. By using flops that have enables, we can save area and possibly delay.Explain how this is achieved.
The
next_state
attribute of theff
block needs to be evaluated to see if it's an enable expression. This means a bunch of infrastructure related to parsing liberty expressions.If applicable, please suggest to reviewers how they can test the change.
Run
dfflibmap -liberty foo.lib
on various liberty files you can find, and see if they a) parse without crashing and b) successfully detect the enable flops in the file.Still to do:
a bunch oflog_warning
s are commented out because they are extremely noisy.sky130 has some scan chain flops with the expression(D&DE&!SCE)|(IQ&!DE&!SCE)|(SCD&SCE)
, which the parser chokes on because of three ands instead of two - to investigate and fix. (to be clear, this won't infer, but it shouldn't issue the nonsense warning of "Inference failed on expression '(D&DE&!SCE)|(IQ&!DE&!SCE)|(SCD&SCE)' in next_state attribute of cell 'sky130_fd_sc_hd__sedfxtp_4' because it does not contain ff output 'IQ' - skipping." when it does.continue
in ado
/while
loop did not do what I thought it did.more generally, because the code loops through all cells to find each cell type, this results in a lot of duplicate warnings.there's now a lookup to avoid duplicate warnings.edfxtp
/edfxbp
.