Does the AXI bus adapter support the downsizer from 256bits to 8bits？ about verilog-axi

[alexforencich]

Well, ostensibly it should work, but I don't test every possible combination of parameters, so it's possible there is some sort of a bug. I'll take a look at it and see if I can figure out what's going on.

[alexforencich]

So, after running the testbench for a while, I haven't seen any issues yet (at 256 bits it takes quite a long time to run). Can you share any details on exactly what issue you're running in to? A screenshot of the simulation or a waveform dump that I can open in gtkwave would be helpful.

[chengquan]

Thank you for your quick reply.
I use VCS for simulation, and I upload a waveform graph. (32bit-to-8bit config)
the Op is: I read data starting from 0xa2c0. Arsize is 2, Arlen is 0, i.e. No burst. especially, the increase of addr is 1, not 4. Because I need to test the (uint_8* ptr) case in a 32-bit MCU.
Namely, read 4 bytes at 0xa2c0, then, read 4 bytes at 0xa2c1, then read 4 bytes at 0xa2c2, then...........
But the waveform shows that the addr suddenly jumps into 0xa2c5 from 0xa2c1, which should be 0xa2c2 (I guess).
I am debugging my code. Maybe this is a master-port bug in my design, not yours.
BTW, in the waveform, the first (a2*) at line #1 is 0xa2c0,the second (a2*) is 0xa2c1.
Due to the resolution problem, I cannot zoom it out.
The upper half of the waveform is input to the adapter module (32-bit bus), and the lower half is output (8-bit bus).

[alexforencich]

Oh, so you're seeing an issue with 32 to 8, not 256 to 8. Yeah, there definitely is a bug in there somewhere, let me check the spec to see exactly what the issue is. It looks like we both might have bugs.

First burst: read 4 bytes starting at 0xa2c0 - arsize 2 for 4 bytes, arlen 0 for 1 cycle. This one is converted to a 4 cycle burst starting at 0xa2c0 - arsize 0 for 1 byte, arlen 3 for 4 cycles.

Second burst: read 3 bytes starting at 0xa2c1 - arsize 2 for 4 bytes, arlen 0 for 1 cycle. I need to check the spec for what is allowed with the LSBs, but if you want to read 4 bytes starting at an unaligned address, you actually need to specify arlen=1 for a 2 cycle burst since it is an unaligned operation and you effectively need to read 8 bytes starting at 0xa2c0 and then discard the extra bytes. What you specified is actually a burst read of length 3, and my width converter is getting tripped up by the nonzero LSBs and is generating a burst with length 4 followed by a burst of length 256, which is definitely wrong.

[chengquan]

Alex,
Thank you very much. I solved my problem according to your suggestion at 32-to-8 case. I just slightly changed my C code. Now it works!! Now, I replace uint_8* with uint_32* and shifter op. Also, I think standard AXI-4 can support unaligned addr function. Specifying arlen=1 for a 2 cycle burst seems to be a little redundant.

Besides, in 256-to-8 case, I met another problem. In this case, all the addresses are aligned. However, the axi bus is getting stuck around the final burst transmission in write channel.
I am debugging this problem. Maybe this is because some mismatches between my code and yours. But 256-to-32 case functions well. Once I fix it, I will let you know.

[chengquan]

Hello, Alex.
I debugged my project, and know why my project cannot pass 256-to-8 case.
The reason is that I narrow so many bits that some FIFOs in some modules are easy to reach to 'full' state, which means some data is lost during the transmission.
I just increase the depth of FIFOs to remedy this situation. Now, my project can pass the test bench.
You project is perfect. Thank you very much.
Let me close this issue.
Again, many thanks for your project~

[alexforencich]

Well, I think there still is a bug on my end, those partial reads with nonzero address LSBs are definitely not being handled correctly. I'm actually thinking part of the problem is my AXI simulation model, I think it always sets the LSBs of the address to 0, but this is not always going to be the case. I think a stop-gap solution is to simply mask off the LSBs based on awsize/arsize, then I can work on a more proper solution when I have time.

[chengquan]

Got it. Hope you can solve this bug and share a new releasing. lol...

[alexforencich]

Alright, I think I have that fixed. I had to update the AXI master model first to actually drive the unaligned address so I could replicate the issue and address it properly. Feel free to update and see if it works in your setup with unaligned operations. I also rewrote some of the conditions and moved a few things around, so the new version might also be a little bit better in terms of area and timing.

[chengquan]

Hi Alex,
Just now, I tested this new releasing. I used int8* pointer to access the memory data via your axi adapter with 32-to-8 configuration. This releasing goes well. Thank you for your contribution.

[alexforencich]

Excellent, good to hear! I guess the question now for you is which method is more performant (if that matters) or more readable (if performance doesn't matter).

[chengquan]

Thanks~ I am gonna integrate your code into my SoC for an ASIC design. Hope I can make it.