CFU is stratified into feature levels: L0: combinational; L1: fixed latency, II=1; L2: variable latency with request flow control; L3: variable latency with request and response flow control; L4: reordering of responses. I propose we cut L2 and L3/L4 to L2/L3.
Each successive CFU level is a big step up in power, flexibility, complexity. Except L2 to L3. There is not much difference between L2 and L3. L3 requires a CFU to respond to suspended response flow control by (eventually) suspending request flow control. L2 CFUs don't have to do this, so an L2 CFU is slightly easier to develop. Conversely, L2 obligates the requester (usually a CPU) to always sink a CFU response on any random cycle (as L2/L3 are variable latency), and to do so as often as every cycle. This is challenging when so many other CPU's FUs are contending to retire results and commit instructions.
So the main burden of cutting L2 is that variable latency CFUs must support response flow control. I think this is an acceptable trade-off to achieve a simpler spec.
Other considerations:
A requester that could implement L2 can just as well implement L3 but permanently assert resp_ready=1.
Also L3, with two flow controlled streams, can be conveyed over AXI-S interconnect infrastructure, but L2 cannot.
Current Vex and CFU Playground CFUs use L3 flow control, so cutting L2 is no hardship there.
Let's lighten the CFU-LI chapter of the spec and its concept burden.. Current L2 + L3 is just more adapters to maintain, more test cases, more complexity and questioning in the minds of CFU adopters, more time to explain CFU-LI.
UPDATE: cutting the old CFU-L2 shaves four pages from the CFU-LI chapter, and halves the required number of CFU feature level adapters.
grayresearch
commented
2 years ago
CFU is stratified into feature levels: L0: combinational; L1: fixed latency, II=1; L2: variable latency with request flow control; L3: variable latency with request and response flow control; L4: reordering of responses. I propose we cut L2 and L3/L4 to L2/L3.
Each successive CFU level is a big step up in power, flexibility, complexity. Except L2 to L3. There is not much difference between L2 and L3. L3 requires a CFU to respond to suspended response flow control by (eventually) suspending request flow control. L2 CFUs don't have to do this, so an L2 CFU is slightly easier to develop. Conversely, L2 obligates the requester (usually a CPU) to always sink a CFU response on any random cycle (as L2/L3 are variable latency), and to do so as often as every cycle. This is challenging when so many other CPU's FUs are contending to retire results and commit instructions.
So the main burden of cutting L2 is that variable latency CFUs must support response flow control. I think this is an acceptable trade-off to achieve a simpler spec.
Other considerations: A requester that could implement L2 can just as well implement L3 but permanently assert resp_ready=1. Also L3, with two flow controlled streams, can be conveyed over AXI-S interconnect infrastructure, but L2 cannot. Current Vex and CFU Playground CFUs use L3 flow control, so cutting L2 is no hardship there.
Let's lighten the CFU-LI chapter of the spec and its concept burden.. Current L2 + L3 is just more adapters to maintain, more test cases, more complexity and questioning in the minds of CFU adopters, more time to explain CFU-LI.
UPDATE: cutting the old CFU-L2 shaves four pages from the CFU-LI chapter, and halves the required number of CFU feature level adapters.