-
Notifications
You must be signed in to change notification settings - Fork 281
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] Add a preset value to allow fir registers to be preset #5667
Conversation
c6654ec
to
0a6fcbc
Compare
docs/Dialects/Seq/RationaleSeq.md
Outdated
Additionally, `sv` operations are also included to provide the register with | ||
a randomized preset value. | ||
a randomized preset value, unless an explicit preset is specified. | ||
Since items assigned in an `always_ff` block cannot be initialised in an | ||
`initial` block, this register lowers to `always`. |
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.
A slightly different formulation has the preset subsume the randomized preset value. I.e., there is a preset <value | "random">
and the presence of the "random" flavor is what produces the existing lowering. If no preset is specified, then this is equivalent to disabling randomization.
The main benefit of this is that it seems odd to lump eliding presets under disabling randomization and this provides a way out of it.
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 agree, we should introduce "preset random", but that requires a lot of test adjusments and it slightly exceeds the scope of what I need to do now. I adjusted the docs a bit to better reflect that.
0a6fcbc
to
ba0cc74
Compare
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.
Async regreset is currently conditionally assigned to a reset value in the initial block so what's the expected behavior of async reset value with preset?
The preset assignment precedes the async reset logic, so nothing should change in that case. |
This makes sense to me. Does the reasoning below make sense? We should separate out several things.
In the IR modeling, these should be kept as distinct things. When targeting FPGA flows, there should be an optional optimization pass that moves asynchronous reset initial values to preset values if the preset value is unset or random. I think the emission should eventually allow composition of all of these to give you either: reg foo;
// Asynchronous reset emission w/ random preset:
initial begin
`ifdef RANDOM_REG
foo = `RANDOM;
`endif
`ifndef SYNTHESIS
if (reset)
foo = foo_init_expr;
`endif
end
always @(posedge clock or posedge reset) begin
if (reset)
foo = foo_init_expr;
else
/* ... */
end reg foo;
// Asynchronous reset emission w/ constant preset:
initial begin
foo = foo_preset_literal;
`ifndef SYNTHESIS
if (reset)
foo = foo_init_expr;
`endif
end
always @(posedge clock or posedge reset) begin
if (reset)
foo = foo_init_expr;
else
/* ... */
end |
I agree, preset is orthogonal to async reset. On FPGAs we turn async resets to sync resets so we don't have to reason about that crazyness. Unless I am mistaken, now we get what you wrote down, with the exception that we always have a preset, random or constant. |
else if (!disableRegRandomization) | ||
randomInit.push_back(svReg); |
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.
Alternatively, why not just emit both? The random is ifdef
guarded and the preset follows the randomization and is not ifdef
guarded.
This logic for emission should already work for this below.
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 want these two to be orthogonal. If a register is preset, we don't reset it. I don't want to have to rely on macros here or SV assigment order and madness.
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.
You've convinced me. 😉 Emitting both is just going to be a useless procedural assignment.
ba0cc74
to
0f4dec2
Compare
See
RationaleSeq.md