[FEATURE] AHB interface support

[Blebowski]

Describe the problem/limitation you think should be addressed

It would be nice if there was an option to generate register map with AHB interface.

[arnonsha]

A built in AHB interface is indeed something that I miss. There are still processors without AXI interface where data transfer speed is important.

[amykyta3]

Will do!
Not a huge fan of AHB, but I do recognize it is still somewhat prevalent

[arnonsha]

thank you very much @amykyta3 for your support !

[Blebowski]

Hi,

@amykyta3

do you have any plan / roadmap on when could this be available ?

We at Tropic Square are currently evaluating PeakRDL toolchain
as we would like to replace ORDT with it. But we see that the development more-less stalled in the last
half year. We are coming to a point where would would need some extra features, e.g.:
Feature: Generate covergroup for accesses to registers
Latex output

we would likely be able to provide some engineering effort to look into these,
but we would like to discuss on how to cooperate on the development.
If you are open to this discussion, we would appreciate it, we are waiting for your response.

We have brought-up the Questa test environment on our side (for regblock and UVM).
We would need an info on when could a merge requests be reviewed and how often do you do releases?
If we want to use the project out of official packages, we need to get new things into it quite quickly (e.g. bi-weekly
basis).

Since the current development seems to be stalled, this does not seem to be the case.
We are considering to create a fork of all the sub-tools, package locally in our network via poetry,
and do our own release scheme. In my experience then it always ends in fork changes diverging
from mainline and never getting back...

[amykyta3]

Indeed the project has been a bit quiet lately but it is certainly not abandoned. PeakRDL and related tools are all something I develop in my free time outside of work. I have taken a little bit of a sabbatical from working on it due to some other volunteer work I have been involved with this past year that has been taking a priority, but should be wrapping up in the next couple weeks. Don't worry - I fully intend to resume work on PeakRDL once my spare time frees up again, including reviewing some of the contributions from the community.

If you are able to implement the AHB layer on your end, please know that you can always contribute this feature as a pull request so that others can benefit. Open-source can be a thankless endeavor, but contributing is the best way to give back to the community and grow the tools.

[Blebowski]

Hi @amykyta3 ,

thanks for your reply. Its good to know that the you aim to continue with the project.
I hope you had a good rest (the penguin is super cute) doing something usefull.

Would you be willing to discuss possible collaboration on PeakRDL on a call ?

[allRisc]

All,

I wanted to pick up the conversation that occurred in #175 (between @amykyta3, @davekeeshan, and @arnonsha).

1. I think AHB-Lite is perfectly sufficient for a vast majority of applications. Very few interfaces use the extra features added in AHB5 outlined below:
   - Larger HPROT size
   - HNONSEC (though it would be necessary for https://github.com/orgs/SystemRDL/discussions/285)
   - Exclusive Transfers (HEXCL, HMASTER, HEXOKAY)
2. However, AHB-Lite (from the AMBA3 standards) does fully support bursting (see https://eecs.umich.edu/courses/eecs373/readings/ARM_IHI0033A_AMBA_AHB-Lite_SPEC.pdf)

So as I look into this I have the following questions:

• Are we okay dropping burst support? It doesn't seem to have been discussed in the PR.
  • I think this is likely a reasonable first step as the most common (in my experience) core which uses AHB (Cortex-M0+) does not support bursting
• Do we want to target a fully pipe-lined interface?
  • For some of my use cases supporting zero wait state transfers is highly beneficial

[amykyta3]

Correct me if I'm wrong (i'm not really an AHB expert)..
Isn't AHB's "burst" somewhat a misnomer? From my reading of the spec, all that HBURST does is provide a hint to the target as to what the addressing pattern is. I assume this is useful for memory devices like DRAMs so that they can initiate the correct prefetch pattern. AHB still requires the initiator to provide a valid HADDR during each cycle of a burst, so wouldn't an AHB target be able to simply ignore HBURST and rely on HADDR to still be compliant?
As far as I can tell, an AHB INCR burst looks no different than a series of back-to-back AHB SINGLE transactions.

[allRisc]

That is correct. Since the manager (formerly master) must keep the address coherent while performing a burst a subordinate (formerly slave) could simply look at the address and ignore burst. However, such an implementation still requires an awareness of the HTRANS signal going to BUSY instead of IDLE since they have slightly different requirements about what is held constant on the subordinate output.

Under an implementation where we claim to comply with bursting would you propose we add the HBURST signal in the design, but leave it unconnected?

[arnonsha]

I agree: For register files and SRAM memories bursts doesn't provide any advantage, so yes we can ignore the burst input completely.
I would also like to see a zero wait state / fully pipelined transfers (See here a timing diagram showing AHB<->cpuif signals for addrmap/regfile containing registers only)
At a later stage we can add sram support which breaks the pipline. This requires controlling the hreadyout signal, and choosing the address going into the cpuif: Either a sampled HADDR, or directly from the bus (See as described here)