Skip to content

Fix/prologue synchronization#296

Open
guosran wants to merge 1 commit into
tancheng:masterfrom
guosran:fix/prologue-synchronization
Open

Fix/prologue synchronization#296
guosran wants to merge 1 commit into
tancheng:masterfrom
guosran:fix/prologue-synchronization

Conversation

@guosran

@guosran guosran commented Jun 19, 2026

Copy link
Copy Markdown
Collaborator

Summary

Addresses #292 with a minimized prologue fix. This PR only updates FlexibleFuRTL.py and its focused test.

Changes

  • During prologue-skipped const operations, keep the const queue aligned with the control stream.
  • Override only the selected FU operation to OPT_NAH for the skipped cycle.
  • Add a concrete example as an inline test comment.

No new ports or interfaces are introduced.

@tancheng tancheng requested review from tancheng and yyan7223 June 21, 2026 06:30
Comment thread fu/flexible/FlexibleFuRTL.py Outdated

s.recv_const.rdy @= reduce_or(s.fu_recv_const_rdy_vector)
s.recv_const.rdy @= reduce_or(s.fu_recv_const_rdy_vector) | \
((s.prologue_count_inport != 0) &

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.

Why the constant should be consumed during prologue?

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.

And why preloading those consts to the const mem and then skipping them?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

The const queue is driven by the control stream, not by whether the FU operation is actually executed after prologue masking.

Concrete example: suppose ctrl slot 0 is ADD_CONST with prologue_count=1, and ctrl slot 1 is another const-consuming op. The first dynamic visit to slot 0 is skipped by prologue, but the control stream still advances. If we do not consume the const for slot 0, that stale const remains at the head of the const queue, so slot 1 reads the wrong const.

So this fix keeps the const queue aligned with the scheduled control words. The FU op is masked to OPT_NAH for the prologue cycle, but the corresponding const token is still consumed.

Comment thread noc/CrossbarRTL.py Outdated
# A prologued input is consumed but not forwarded. This keeps the
# channel aligned with the control schedule.
if s.in_dir[i] > 0:
s.recv_required_vector[s.in_dir_local[i]] @= 1

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.

I don't get this, why crossbar can consume data during prologue?

I mean no offense, but branch kernel-submit is 32 commits behind branch master, can you sync with the master first? CrossbarRTL has been updated during these commits.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

I removed the Crossbar change from this PR. It now only touches FlexibleFuRTL.py and its focused test for const-queue alignment during prologue.

@guosran guosran force-pushed the fix/prologue-synchronization branch from 92bd204 to 4d0f9ae Compare June 23, 2026 20:41
@tancheng tancheng requested a review from Jackcuii June 24, 2026 22:05
@guosran guosran force-pushed the fix/prologue-synchronization branch from 4d0f9ae to 07a826a Compare June 25, 2026 14:43
@guosran guosran changed the base branch from kernel-submit to master June 25, 2026 14:52
@guosran guosran marked this pull request as draft June 25, 2026 14:54
@guosran

guosran commented Jun 26, 2026

Copy link
Copy Markdown
Collaborator Author

Concrete example:
During prologue, the FU should not execute the real operation yet.

cycle 0: ctrl = ADD, prologue_count = 1
FlexibleFuRTL sends OPT_NAH to inner FU
no ADD result is produced

cycle 1: prologue_count = 0
FlexibleFuRTL forwards ADD
FU executes normally

@guosran guosran marked this pull request as ready for review June 26, 2026 00:32
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.

2 participants