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

[rtl] Fix counter reset value on FPGA #2226

Merged
merged 1 commit into from
Nov 29, 2024

Conversation

nasahlpa
Copy link
Member

If the counter width is >= 49, we do not use a DSP on the FPGA. Then, we should use an asynchronous reset to initialize the counter.

This bug was detected when enabling the lockstep for the CW340. A lockstep mismatch happend as the mcycle counters of the main and shadow core did not match due to this bug.

@nasahlpa nasahlpa requested review from GregAC and vogelpi November 27, 2024 15:53
@@ -55,8 +55,12 @@ module ibex_counter #(
localparam int DspPragma = CounterWidth < 49 ? "yes" : "no";
(* use_dsp = DspPragma *) logic [CounterWidth-1:0] counter_q;

// DSP output register requires synchronous reset.
`define COUNTER_FLOP_RST posedge clk_i
if (CounterWidth < 49) begin : g_sync_reset
Copy link
Contributor

Choose a reason for hiding this comment

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

Could you explain the magic number "49". Also line 55 declares DspPragma as an int but initializes with strings. Maybe put both the counter_q and the `define inside the if-generate?

Also, could you please move the `undef COUNTER_FLOP_RST line right past its last (and only) use at line 71?

Copy link

Choose a reason for hiding this comment

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

It's an implementation detail for Xilinx FPGAs. A single DSP48 primitive can readily do up to a 48-bit counter.

Copy link
Member Author

Choose a reason for hiding this comment

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

Not an expert in this - why do we need this pragma anyways? Wouldn't the synthesis tool detect this counter and try using a DSP?

Copy link

Choose a reason for hiding this comment

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

I don't know. I assume someone tried it and wasn't getting the result they wanted, so they added the synthesis attribute.

That's the impression I get from the PR where it originated: #624

Copy link
Member Author

Choose a reason for hiding this comment

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

Could you explain the magic number "49". Also line 55 declares DspPragma as an int but initializes with strings. Maybe put both the counter_q and the `define inside the if-generate?

Also, could you please move the `undef COUNTER_FLOP_RST line right past its last (and only) use at line 71?

Done, thanks for the feedback!

I don't know. I assume someone tried it and wasn't getting the result they wanted, so they added the synthesis attribute.

That's the impression I get from the PR where it originated: #624

Ah thanks for linking this PR.

Copy link
Member Author

Choose a reason for hiding this comment

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

Ok to merge this now? It will unblock some SiVal tasks.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, let's merge this. CI ran through already.

@nasahlpa nasahlpa force-pushed the fix_counter_reset_value branch from a8416cb to 105bb12 Compare November 28, 2024 06:52
If the counter width is >= 49, we do not use a DSP on the FPGA.
Then, we should use an asynchronous reset to initialize the counter.

This bug was detected when enabling the lockstep for the CW340. A
lockstep mismatch happend as the mcycle counters of the main and
shadow core did not match due to this bug.

Signed-off-by: Pascal Nasahl <[email protected]>
@nasahlpa nasahlpa force-pushed the fix_counter_reset_value branch from 105bb12 to 3428e0c Compare November 28, 2024 06:55
Copy link
Contributor

@vogelpi vogelpi left a comment

Choose a reason for hiding this comment

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

Excellent work @nasahlpa , this looks good to me!

Yes, indeed the FPGA synthesis tool needs to be explicitly told to use DPS slices here and for counters wider than 48 bits, it will use 2 DSP slices and quite some logic to combine them. From a logic utilization and timing perspective this is not nice. Back in 2020 Noam (back then a student at ETH) was investigating how and where the code can be better mapped to FPGA. IIRC, the biggest improvements where achieved in the register file (using LUTRAM instead of FFs) and the performance counters.

@nasahlpa nasahlpa requested a review from matutem November 28, 2024 10:52
@vogelpi vogelpi added this pull request to the merge queue Nov 29, 2024
Merged via the queue into lowRISC:master with commit 54985d2 Nov 29, 2024
11 checks passed
@nasahlpa nasahlpa deleted the fix_counter_reset_value branch November 29, 2024 11:54
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.

5 participants