roalogic / ahb3lite_apb_bridge Goto Github PK

Hi,
I'm using the IP to integrate some APB peripherals in my bus but it seems to be not managing to answer correctly when a sequence of two requests appears spaced by one clock cycle. What happens in the end is that the first request it's corrected routed to the bus but the last one doesn't as showed in the image below. The requests are simple with no burst (NONSEQ_HTRANS) and the slave it's inside the mask range as mentioned in the datasheet.

If the requests are spaced by more than 5 clock cycles, then I can request again with no problems but if a new request arrives in the following next 2 clock cycles it happens again.

Top file with the modules are in the zip below...
sim.zip

First of all thanks for this IP, I'm using it in a research project on the University of Twente in the Netherlands.

However in commit 18d9aee you introduced resetting some state to 'X's. When using the DC compiler in optimizing mode (compile_ultra) this generates logic that is incorrect. I'm not sure if this is a bug in the DC compiler or not, but my issue was fixed by changing the x's in the file to 0's.

It's even worse that this was not caught by formality.

To be clear when doing a post-synthesis simulation it would end up in a undefined (x's) state when trying to convert an ahb to apb transaction.

Hi @rherveille,

I believe there may be an issue with PADDR incrementing incorrectly. I'm using the ahb3lite_apb_bridge with a single instance of apb4_gpio directly connected. the AHB3 bus is 32-bit data/address while the APB bus is only 8-bit address/data. When performing byte wise accesses from the CPU everything works as expected. However when trying 32 bit accessing via the bridge I see PADDR increment by 4 (per beat) due to:
line 498: PADDR <= PADDR + (1 << ahb_hsize);
I believe this should be:
line 498: PADDR <= PADDR + (PDATA_SIZE/8);

With this change word and hword accesses appear to work as expected.
Cheers,