Skip to content

[hardware] fix latency stall bug in VMFPU #482

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.

Sign up for GitHub

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

Merged
hopang-0221 merged 2 commits into from
Aug 16, 2026
Merged

[hardware] fix latency stall bug in VMFPU #482

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
d7699da
[hardware] fix latency stall bug in VMFPU
Navaneeth-KunhiPurayil Apr 5, 2026
a02e573
[chore] update CHANGELOG.md
Navaneeth-KunhiPurayil Aug 10, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -55,6 +55,7 @@ and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.
- Fix u-boot to support RVV-linux
- Fixed src emul check for vector integer extension operation
- Fix VSTU queue overrun due to pointer comparison
- Fix latency stall bug in vmfpu

### Added

Expand Down
21 changes: 10 additions & 11 deletions hardware/src/lane/vmfpu.sv
View file
Open in desktop

@hopang-0221 hopang-0221 Aug 12, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Hi Navaneeth, can you explain why you use the latency_stall instead of the registered latency_stall_{d,q}? The same for vinsn_issue_lat and vinsn_processing_lat signals.

@Navaneeth-KunhiPurayil Navaneeth-KunhiPurayil Aug 12, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

This is because it is computed from an already registered signal vinsn_issue_q and vinsn_processing_q while previously it was using _d signals

@hopang-0221 hopang-0221 Aug 16, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

LGTM!

Original file line number Diff line number Diff line change
Expand Up @@ -208,6 +208,7 @@ module vmfpu import ara_pkg::*; import rvv_pkg::*; import fpnew_pkg::*;
[VFREDMIN:VFREDMAX]: fpu_latency = LatFNonComp;
[VFCVTXUF:VFCVTFF]: fpu_latency = LatFConv;
[VFMIN:VFSGNJX]: fpu_latency = LatFNonComp;
[VMFEQ:VMFGE]: fpu_latency = LatFNonComp;
default: begin
case (sew)
EW64: fpu_latency = LatFCompEW64;
Expand Down Expand Up @@ -1366,8 +1367,8 @@ module vmfpu import ara_pkg::*; import rvv_pkg::*; import fpnew_pkg::*;

// Latency stall mechanism to ensure in-order FPU execution when needed
// i.e. when issue insn has latency lower than processing insn latency
fpu_latency_t vinsn_issue_lat_d, vinsn_processing_lat_d;
logic latency_stall, latency_problem_d, latency_problem_q;
fpu_latency_t vinsn_issue_lat, vinsn_processing_lat;
logic latency_stall, latency_problem;

always_comb begin: p_vmfpu
// Maintain state
Expand Down Expand Up @@ -1416,21 +1417,21 @@ module vmfpu import ara_pkg::*; import rvv_pkg::*; import fpnew_pkg::*;
fpu_red_complete_d = 1'b0;

// Get latencies
vinsn_issue_lat_d = fpu_latency(vinsn_issue_d.vtype.vsew, vinsn_issue_d.op);
vinsn_processing_lat_d = fpu_latency(vinsn_processing_d.vtype.vsew, vinsn_processing_d.op);
vinsn_issue_lat = fpu_latency(vinsn_issue_q.vtype.vsew, vinsn_issue_q.op);
vinsn_processing_lat = fpu_latency(vinsn_processing_q.vtype.vsew, vinsn_processing_q.op);

// fpnew allows out-of-order execution and different instruction
// types have different latencies. We have to enforce in-order execution.
// If we are about to issue an instruction while another one is processing,
// issue only if the new instruction is slower than the previous one.
// VFDIV-like instructions have variable latency, so stall them not to create
// problems.
latency_problem_d = (vinsn_issue_lat_d < vinsn_processing_lat_d) ||
(((vinsn_issue_d.op inside {VFDIV, VFRDIV, VFSQRT}) ||
(vinsn_processing_d.op inside {VFDIV, VFRDIV, VFSQRT})) &&
vinsn_issue_d.id != vinsn_processing_d.id);
latency_problem = (vinsn_issue_lat < vinsn_processing_lat) ||
(((vinsn_issue_q.op inside {VFDIV, VFRDIV, VFSQRT}) ||
(vinsn_processing_q.op inside {VFDIV, VFRDIV, VFSQRT})) &&
vinsn_issue_q.id != vinsn_processing_q.id);

latency_stall = vinsn_issue_q_valid & vinsn_processing_q_valid & latency_problem_q;
latency_stall = vinsn_issue_q_valid & vinsn_processing_q_valid & latency_problem;

operand_a = (vinsn_issue_q.op == VFRDIV) ? scalar_op : mfpu_operand_i[1]; // vs2
operand_b = (vinsn_issue_q.use_scalar_op && vinsn_issue_q.op != VFRDIV)
Expand Down Expand Up @@ -2357,7 +2358,6 @@ module vmfpu import ara_pkg::*; import rvv_pkg::*; import fpnew_pkg::*;
narrowing_select_out_q <= 1'b0;
fflags_ex_valid_q <= 1'b0;
fflags_ex_q <= '0;
latency_problem_q <= 1'b0;
simd_red_cnt_q <= '0;
mfpu_state_q <= NO_REDUCTION;
reduction_rx_cnt_q <= '0;
Expand All @@ -2381,7 +2381,6 @@ module vmfpu import ara_pkg::*; import rvv_pkg::*; import fpnew_pkg::*;
narrowing_select_out_q <= narrowing_select_out_d;
fflags_ex_valid_q <= fflags_ex_valid_d;
fflags_ex_q <= fflags_ex_d;
latency_problem_q <= latency_problem_d;
simd_red_cnt_q <= simd_red_cnt_d;
mfpu_state_q <= mfpu_state_d;
reduction_rx_cnt_q <= reduction_rx_cnt_d;
Expand Down
Loading