AXI Fragmenter

[zhemao]

Not sure what happened to Wes' AXI fragmenter for the RISCV workshop demo. We need something like it for our CRAFT verification work, so I figured I would add my own.

For multibeat aw, we wait for the input w request before sending both an aw and w out.

For multibeat ar, we take in the input request and then send some number of output requests. This could be optimized for the case of single beat requests, but I don't think the extra logic is worth it.

We don't forward b responses except for the last one. For r responses, we just mess with the "last" field.

Only one set of transactions with the same ID is allowed to be inflight at a time. We save the lens for each transaction in registers index by the ID.

Since we have the fragmenter, we can also avoid handling multibeat requests in AXI -> TL converter.

[zhemao]

@terpstra Is there some AXI protocol requirement that I'm forgetting? Would be good to make sure.

[terpstra]

It seems reasonable. I'd make sure your test cases include a narrow burst,
though.

On Fri, Sep 23, 2016 at 4:52 PM, Howard Mao notifications@github.com
wrote:

@terpstra https://github.com/terpstra Is there some AXI protocol
requirement that I'm forgetting? Would be good to make sure.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#339 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDPii0XBiHRuODikC7wcxLcJSZNenKnks5qtGZMgaJpZM4KFfTJ
.

[terpstra]

I would ask Henry Styles to run a regression check on the PCIe dev board before you switch this over. AFAIK, he is the only one affected.

[zhemao]

The test case is a narrow burst. It's using 4 beats of 32 bits each.

[terpstra]

Have you run this by Henry yet? I'd like to reuse some of this code in the TL2-AXI4 converter pipeline.

[terpstra]

I note that you have the same busy register used for both AR and AW... those are actually distinct namespaces. It's also not super efficient to only allow a single transfer per ID.

[terpstra]

You also don't handle burst types other than increment. There's wrapping and fixed to consider.

[terpstra]

You also don't correctly update the address for a misaligned start access. Please consult section A3.4.1 of the AXI4 specification.

Aligned_Address = (INT(Start_Address / Number_Bytes) ) x Number_Bytes
Address_N = Aligned_Address + (N – 1) × Number_Bytes

[terpstra]

�Hmm. I think you would also need to modify the size of the first beat in a Fragmenter.

[terpstra]

Err, no, cancel that. The first transfer will still be small even if size is unchanged, so that is fine. You definitely still need to increment the address properly, though. Otherwise you would have the following:

address = 2, size = 2 (2^2=4 bytes), len = 4:
CORRECT: write(2, 2), write(4, 4), write(8, 4), write(12, 4)
YOURS: write(2,2), write(6,2), write(10,2), write(14, 2)
for a function write(offset, numBytes)

[zhemao]

Henry said there's some other bug that broke PCIe he needs to resolve before testing this.

The reason I'm not supporting more than one ID in-flight is because that will greatly expand the amount of state I need to keep. Instead of a few registers per ID I would need a queue per ID.

You're right that I do need to fix the support for FIXED_BURST among other things. I wasn't aware that start addresses could be misaligned. Thanks for pointing that out.

[zhemao]

It seems that we are adding AXI fragmentation a different way, so I'm closing this one. We actually don't need this anymore for CRAFT, since we are verifying the actual AXI (NASTI) crossbar.