Skip to content

fix(scheduler): defer warp_pcs[0] init out of reset block (#334)#357

Open
gautamdev17 wants to merge 1 commit into
vortexgpgpu:masterfrom
gautamdev17:fix-non-constant-reset-warp-scheduler
Open

fix(scheduler): defer warp_pcs[0] init out of reset block (#334)#357
gautamdev17 wants to merge 1 commit into
vortexgpgpu:masterfrom
gautamdev17:fix-non-constant-reset-warp-scheduler

Conversation

@gautamdev17
Copy link
Copy Markdown

Fixes #334

Problem

warp_pcs[0] was being assigned from base_dcrs.startup_addr inside the reset block. This is not allowed in ASIC synthesis,reset assignments must be constants, not runtime signals.

Fix

Added a reg initialized flag that starts at 0 on reset. On the first cycle after reset, warp_pcs[0] and active_warps[0] are loaded together, so warp 0 only becomes schedulable once it has the correct boot address. All other scheduler logic runs normally after that.

This adds one extra cycle before the first instruction is fetched,which has no practical impact.

…u#334)

Non-constant reset assignment (base_dcrs.startup_addr) inside if(reset)
is illegal in ASIC synthesis. Introduces 'initialized' flag: reset block
uses constants only; warp_pcs[0] and active_warps[0] set atomically one
cycle after reset deassertion so warp 0 never schedules with PC=0.
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.

Assignment to non-constant value in reset statement - warp scheduling

1 participant