You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
LoopConv downsample with padding generates a zero-row mvin and stalls the load pipeline #417
I found a potential RTL bug in Gemmini's LoopConv path (commit 8c3f9923).
When downsample=1 and padding>0, LoopConv can generate an mvin command with zero rows, triggering the assertion in LoadController.scala:189:
A single mvin instruction must load more than 0 bytes
When the fatal assertion stop is disabled, the zero-byte load causes abnormal DMA command tracking and pipeline stalls. The operation does not complete within 6 million simulation cycles.
The issue is also reachable through directly issued RoCC instructions, without relying on the C convolution wrapper.
Root Cause
In LoopConv.scala (around lines 296–365), the downsampled row count is calculated as I >> downsample. For certain padding-region iterations, this evaluates to zero, but the control logic still issues the corresponding mvin command.
The zero-byte command violates the LoadController invariant and disrupts DMA command tracking, preventing the pipeline from making progress.
I tested a local RTL fix that skips issuing the mvin when the computed row count is zero while still advancing the loop iteration. The modified design completes the triggering case without the original assertion or stalled DMA transactions. Both supported control cases continue to pass with identical TileLink traffic.
Activity