AXIDownConverter behaviour on sub-word accesses

[FlyGoat]

Hi,

I discovered a problem on our AXIDownConverter.

When AXI Master initiate subword access, our AXIDownConverter would generate illegal request to downstream.

See following examples: For a read request from a bus width of 256 and downstream width of 32, if master made a read to ARADDR = 0x0 with ARSIZE = 0b010, our AXIDownConverter would convert it to 8 incr burst read to ARDDR 0x0 ~ 0x20, with ARSIZE = 0b010 each, which is undesired.

If master made write to AWADDR = 0x0 , ARWIZE = 0b010 and WSTRB= 0hffffffff, it would be converted to 8 incr burst write to AWDDR 0x0 ~ 0x20, with first one have WSTRB = 0hffffffff and rest have WSTRB = 0, this is prohibited under AXI spec.

This is causing problems on using wider system bus, for similar problem on Wishbone system it is fixed by #1999, but for AXI system as AXI Lite bus does not have SIZE or SEL for selecting read masks, so those undesired bursts will be forward to CSR bus and draining UART FIFO.

Thanks

[FlyGoat]

I tried to fix that problem on my own but failed. My migen and bus protocol skill is not sufficient for writing a fully functional converter.

My workaround for now is to use a third party verilog AXI IP.

https://github.com/alexforencich/verilog-axi

I tried to run litex’s bus components against designware’s AMBA VIP suite and there were too many failed cases popping up that I don’t know where to start with.

Given the challenge of implementing functional bus components I think it would be better if we could allow users to select between native implementation and third party implementation.

I wonder if it’s acceptable for litex upstream.

[enjoy-digital]

Hi @FlyGoat,

first, thanks for the different fixes/PR! I'll try to look at your issue and I'm not against your suggestion to allow third party implementation of interconnect/components: In fact that's what has been used initially for AXI and could allow using/comparing our implementation against others.

We already have the wrappers around https://github.com/alexforencich/verilog-axi with https://github.com/enjoy-digital/litex_verilog_axi_test and in LiteX, or AXI, we could allow using native or verilog_axi implementations. I'll try to prepare a PoC for this in the next days.

[FlyGoat]

Hi @enjoy-digital,

Any update?

Thanks