8000 LoopConv downsample with padding generates a zero-row mvin and stalls the load pipeline · Issue #417 · ucb-bar/gemmini · GitHub
[go: up one dir, main page]

Skip to content

LoopConv downsample with padding generates a zero-row mvin and stalls the load pipeline #417

Open

Description

@90ICEDA

Description

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      0