AXIL crossbar doesn't support M_ADDR_WIDTH < 12

[martin-tanguay]

Hi,

I've checked out you "verilog-axi" repo (which is really cool and contains pretty much all the AXI tools) and I've found a bug in the AXIL crossbar where it doesn't support M_ADDR_WIDTH < 12. I've created a testbench with one master and 2 slaves and it works perfectly for M_ADDR_WIDTH >= 12, but asserts an error for M_ADDR_WIDTH < 12.

The root cause is in axil_register_wr.v (line 131), in axil_register_rd.v (line 119) and in axil_crossbar_addr.v (line 138). Looking at the AXIL interconnect, I've found that this limitation doesn't exist, so I copied the address check in the AXIL crossbar (M_ADDR_WIDTH[i*32 +: 32] < 0) and it works perfectly fine.

Is there any reason for not supporting M_ADDR_WIDTH < 12 ?

By the way, the AXI crossbar (not AXIL) also has the same limitation.

Thanks.

Martin Tanguay

[alexforencich]

Good point, I will change that to check against $clog2(STRB_WIDTH) instead of 12 for the AXI lite crossbar, and also the AXI lite interconnect.

For the AXI crossbar, the min address width is 12 bits to ensure that all regions of address space are at least 4096 bytes in size, and are naturally aligned on at least 4096 byte boundaries. This is effectively required as per the AXI spec as bursts cannot cross 4096 byte boundaries, so forcing all address ranges to 4096 byte alignment means that bursts will never hit more than 1 peripheral.

[martin-tanguay]

Thanks for the quick reply. I understand that in the AXI spec, bursts cannot cross 4096 byte boundaries, but can be less than that.
A good example would be a slave module with only 64 data addresses (6 bits of address), why would we lose 12 bits of address space ?

[alexforencich]

You wanna rewrite the crossbar to deal with splitting bursts across multiple ports? If you're slicing and dicing the address space on such small granularity, it probably makes sense to use AXI lite anyway instead of AXI. Or perhaps even AHB.

[alexforencich]

Also, there is an important difference between burst size and burst alignment. A burst of 2 bytes starting at 0x0FFF crosses a 4096 byte boundary and hence must be split into two bursts.

The idea here is to assume that you can get any AXI-compliant operation from upstream, in which case bursts can be any length and any alignment within those 4096 byte boundaries. Dealing with some finer alignment requires potentially quite a bit of additional logic, so it's easier just to make sure that all of the addressable regions are aligned on 4096 byte boundaries and rely on the upstream master that's issuing the request to split the bursts on these boundaries as required by the spec. Otherwise you're basically left with two options: detect oversize bursts and terminate them with an error similar to what you would do with an invalid address, or split them across multiple peripherals and then buffer and reassemble the responses, which can potentially be delayed and/or interleaved with other operations.

[martin-tanguay]

Understood. And by the way, I really didn't meant that the crossbar needs to be rewritten. On the contrary, the suite is really great, and I wanted to share if that could be an limitation...

Thanks for your answers.

[alexforencich]

No worries; and thanks for reporting this for the AXI lite crossbar, as this restriction isn't required for AXI lite as AXI lite does not support bursts.

For AXI, you're normally only going to use that when you need to move around lots of data with bursts, perhaps interfacing with things like DRAM controllers. In which case all of the address ranges are going to be much larger than 12 bits. For lots of small peripherals, it makes a lot more sense to use a simpler protocol like AXI lite, AHB, wishbone, etc. which doesn't require all of the additional logic to support bursts. You can dedicate one larger address range on the AXI crossbar, then adapt that to AXI lite and set up an AXI lite crossbar for all of the peripherals.

[alexforencich]

Also, I just pushed a new version with this fix, please let me know if it works for you.

[martin-tanguay]

Thanks Alex, I appreciate. Great set of tools ! I'm looking forward to use them. Martin