Skip to content

The hazards of different LMULs have not been considered in their entirety. #239

Open
@WEIhabi

Description

@WEIhabi

It was mentioned earlier #111 that a different LMUL might affect hazard, and the response given by the development team was to utilize stalling when the LMUL is changed (WAIT_STATE in the ara_dispatcher) to avoid this situation.

However, when we verified it using formal verification, we found the following errors.

image
image
image
image
image

When the first incoming instruction vslideup.vx,vl=144,EW16,LMUL=2,vs2=v0,vd=6,vm=1,stride=128
Next instruction is vadd vl=16,EW16,LMUL=1/2,vs1=v11, vs2=v7,vd=v31,vadd.vv v31, v7, v11

The original slideup instruction that would have written vd=6 would have written to v7 (because stride and LMUL=2), but the next vadd instruction would have already taken out the data from the source register, v7, and done the math.
This causes the vadd instruction, which is supposed to stall and wait for v7 to be written back before taking out the data, to get the data that has not yet been written back beforehand, causing an error.

The main reason for this failure is that the stall mechanism in ara_dispatcher is not well thought out (only LMUL[2]=0 && LMUL_old > LMUL_new are taken into account).

To complete the above consider that it might be possible to rewrite it as follows:

if ((!vtype_q.vlmul[2] && (vtype_d.vlmul[2:0] < vtype_q.vlmul[2:0])) || (vtype_q.vlmul[2] && (vtype_d.vlmul[2:0] > vtype_q.vlmul[2:0])))
                  state_d = WAIT_IDLE;
end

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions