Methods for managing a full fp issue unit

[Amund Bergland Kvalsvik]

Hello BOOM community,

I am pretty deep into the process of modifying the BOOM for security research. My modifications create a pretty hefty backlog in many of the issue queues. Currently, it is stalling on the MediumBoomConfig because the core is dispatching 2 fp instructions when all but one of the slots in the fp issue unit are full, resulting in a shift of only 1 in the slots, meaning that only instruction 1 is received. I can't tell if this is a known design problem and only visible because of my modifications or if there are no mechanisms that prevent the fp issue unit from overflooding?

In short, what are the mechanisms by which the core stalls in case the issue units end up being full? Do these signals also work for the fp issue unit and fp pipeline?

Kind regards,

Amund

[Jerry Zhao]

Instructions stall at the dispatch/rename stage if the issue queues are full.
Increasing the depth of the issue queues obviously alleviates this, but can be costly. 
Aggressive designs will try to implement very deep issue queues while minimizing issue queue area cost. Some of the configuration parameters around issue queue size address this.

-Jerry

--
You received this message because you are subscribed to the Google Groups "riscv-boom" group.
To unsubscribe from this group and stop receiving emails from it, send an email to riscv-boom+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/riscv-boom/CAG%3DtxvyKbdQde_q%2BQorSiCGGzusZXA-M2oqTDvo12%2BV%2BD8zcPg%40mail.gmail.com.

[Amund Bergland Kvalsvik]

Hello Jerry, and thank you for the response.

Very specifically, I am looking for the specific signals that control this feedback loop. I can see that BasicDispatcher has the ability to stall rename2/dispatch using the ren_readys, but I must admit I am struggling to parse this code.

Beyond that I cannot see any signals or wires which actually stall dispatch if the issue queue are full? If you know where to look, help would be much appreciated.

Kind regards,

Amund

[Tom George]

Hi Amund,

The issue queue stage ready signals (which say if it is full) connect to the dispatch stage at the line: fp_pipeline.io.dis_uops <> dispatcher.io.dis_uops(i) (line 832 of core.scala in the v4 code).

The issue queue ready signals are generated in line 212 of issue-unit-age-ordered.scala in the v4 code: io.dis_uops(w).ready := RegNext(PopCount(is_available) > w.U(log2Ceil(nFastSlots).W) + PopCount(io.dis_uops.map(_.fire)))

One thing that might have been confusing is that, within the Basic Dispatcher is that we input dis_uops from the core to the ren_uops input of Basic Dispatcher, but the outputs of Basic Dispatcher are called dis_uops. And then, we use the ready signals from the issue queue (which, since they go backwards, are inputted to the dis_uops output of the Basic Dispatcher), to say whether ren_uops (in Basic Dispatcher) are ready (and this is the same as dis_uops in core.scala).

Please let me know if any other part of the feedback loop was making you confused.

Tom

[Amund Bergland Kvalsvik]

Thank you Tom! That was my thought but I did not manage to follow the code to see if it was actually correct. Great to know exactly how it works, even if I do think some of the naming in that particular step is a bit confusing.

I did find my corresponding issue as well, which turned out to be that statechanges to issue slots created a discrepancy between slots that were actually valid and slots that reported would_be_valid.

Kind regards,

Amund

To view this discussion on the web visit https://groups.google.com/d/msgid/riscv-boom/541ce4f0-8498-4e1b-8fbf-8ccad0beed58n%40googlegroups.com.