Add support for Avalon memory mapped peripherals

[Jan-Snoeijs]

The protocol is popular in Intel FPGAs. I am happy to help building support for this

[amykyta3]

I was actually wondering about Avalon and whether it was still popular with Intel devices. I primarily work with ARM-based ASICs and Xilinx FPGAs so am not as familiar with Intel's ecosystem. Seems like a very reasonable thing to add support for.

At first glance, it looks like the Avalon protocol has several different variants based on what interface properties are selected. Can you help me understand which permutations are more "popular"?

The basic handshake looks quite similar to AMBA's APB which is quite simple. Additional modes appear to be similar to a subset of AMBA's AXI in some ways, so they look quite familiar to me already.

Specifically:

• How prevalent is the use of the waitrequestAllowance property? This is doable, but I would have to implement a skid buffer to adapt. If not too popular, I'd prefer to skip this one.
• How about pipelined transfers? The mode with variable latency would fit well with the internal PeakRDL architecture. I basically support something similar with AXI4-Lite.
• Burst transfers do not seem particularly useful for the regblock generator since these are better suited for large memories/caches. Will probably not support.

My initial hunch is that I would add this as two Avalon variants:

• Simple non-pipelined agent
• Agent with pipelined support

I still need to study it a bit more - it's possible the pipelined implementation will be quite simple and the non-pipelined one is not necessary. Unlike AXI, Avalon does not seem to require wait states on the responses, so that simplifies things quite a bit.

Let me know what you think!

[Jan-Snoeijs]

Thanks for the detailed analysis. The most common variants I have seen are:

• simple agent, no pipeline just the "fundamentals" signals group. (response, byteenable, lock, waitrequest are optional; you can decide to support them at a later stage) 3.5.3. Read and Write Transfers with Fixed Wait-States
• pipelined agent with readdatavalid and waitrequest 3.5.4.1. Pipelined Read Transfer with Variable Latency

I have also seen and used burst transfers, but can definitely be skipped.

I dont think waitrequestAllowance is very popular. I've never used that before

Implementing the agent with fixed wait-states should be the easiest as it's just a single handshake unlike AXI-lite's multiple handshakes for address, data and response

[amykyta3]

Great! Thanks for confirming. This doesn't seem too difficult to add.

[amykyta3]

Turns out that Avalon adapts very cleanly to the internal protocol I use, so it was very quick to implement (see commit above)

I still need to put together some proper testcases and documentation, but that should be pretty quick work.

[Jan-Snoeijs]

That was quick! Thank you so much

I have left a comment on the commit

[amykyta3]

Had to make a minor change to support proper pipelining, but it has been merged.

Would be nice to have an example agent.sv file this would produce to validate it.

If you want to try it on your end, do the following:

# Install PeakRDL first
python3 -m pip install peakrdl

# Replace the regblock generator installation with the pre-release
git clone git@github.com:SystemRDL/PeakRDL-regblock.git
python3 -m pip install ./PeakRDL-regblock/

# Generate an Avalon regblock from a SystemRDL definition
peakrdl regblock <your_rdl_file> --cpuif avalon-mm-flat -o output_dir/

Here is a simple RDL file you can use as a testcase: https://github.com/SystemRDL/PeakRDL-regblock/blob/main/tests/test_structural_sw_rw/regblock.rdl

Will the agent generated code be synchronous or purely combinational logic?

It depends. By default the Avalon interface will have zero latency and therefore be very combinational. If you enable more re-timing stages via command-line args (see peakrdl regblock --help), there will be added access latency.

[Jan-Snoeijs]

Thanks a lot! Will try on my end and let you know if there is anything odd

[amykyta3]

Published in v0.14.0.