Testing AXI custom component

--- Quote Start ---

I have seen that the bridge between the axi component instantiated into qsys and the hps is very verbose! There are many componets auto-instantiated by qsys like a axi-avalon translator or something like that, did you try just to connect you component directly to the hps without using the qsys generated code? In other words have you tried just to instantiate in qsys the hps and outside the tool link it to your component?

I will try for sure to debug it with signal tap! That is always a good idea.

The verification environment provided as bfm in the quartus 15.1 and quartus 16.0 is not so straight forward to use, do you know what they mean for read/write and combined accepted capability?

Thank you for any tips,

Cheers. =)

--- Quote End ---

In short: No. I needed a working system in too short a time frame to continue debugging. If I was designing now, I'd connect the HPS directly to any of my AXI components, and maybe even license an ARM switch IP instead of using Avalon to handle multiple components. My IP wasn't setup to handle TIDs correctly, and we switched to using the simpler Avalon bus architecture, so this became a non-issue for us. In addition, there's no multi-AXI command handling built in to the Linux kernel driver, so there is only one transaction active from the HPS to the fabric at any given point either way (I believe through communication with Altera).

Not to mention that if you lose the FPGA clock and the AXI gets stuck, an HPS running Linux will freeze until an AXI transaction completes (this is part of AXI). Maybe adding a timeout that can reset the AXI bus could work.