RFC: Etherbone address detection

[m-byte]

I was recently thinking about how it would be nice of we were able to automatically detect the addresses of some standard ip cores connected to etherbone (haven't really looked into that, but this proposal probably also applies to uartbone and other host bridges). Here's the approach that seems most sensible to me:

Introduce a new message type on the same port as etherbone, but change the magic numbers slightly (e.g. 0x4E9F). The header should be similar to etherbone and include at least the following:
Magic number, version, message type, actual number of records, maximum number of records, flags for support of optional features, a more data available flag
After the header comes data with the length defined in the header.

As for message types, I envision the following:
A) DETECT_REQ: a detection request, if the protocol extension is supported, the other side will respond with DETECT_ACK. No response after a certain time period means the extension is not supported and csr files are definitely required. Number of entries is the maximum number of records that should be replied with.
B) DETECT_ACK: see above, number of entries is the actual number of entries sent back
C) DETECT_CONTINUE (optional): similar to DETECT_REQ, but starting after the last entry returned (only to be used if the more flag was set)
D) ADDR_REQ (optional): a way to request individual records by their well known id (see below)
E) ADDR_RESP (optional): response to ADDR_REQ with up to the maximum requested number of entries. The available number of entries per type should usually be identical to the number of published instances of that module.

The records:
All records consist of the following data within a fixed length):
Well known id
Base address
Version
Space for some optional flags that would have to be defined per module (module authors would be expected to change the version when making incompatible changes to these optional flags)

Well known ids:
To simplify the detection of standard cores (e.g. bitbang i2c, litei2c, litespi, litescope, ...), a range of ids should be set aside to uniquely identify these. This range should be managed either in a repo or wiki to prevent collisions.
For custom modules, another range should be set aside.

This should integrate into the host bridge, so that the address width determined using e.g. etherbone probe can be assumed to also apply to the address detection scheme. Since the requesting side is usually a computer, this would move potential overhead to that side.

Purpose:
For external tools like sigrok, litescope_cli or custom tools, there is currently no way around either compiling the base addresses (which might change from system to system) into the binary or accepting a csr.csv/.json. This can be quite annoying for users, as this file might change between versions and has to be kept track of accordingly.
With this scheme, it would be possible to publish specific modules, or all modules in a soc in a way that would be easy for external tools.
For less powerful FPGAs, only the basic DETECT part would have to be implemented. For more powerful FPGAs, which are more likely to have a lot of modules inside, the optional ADDR feature would simplify the detection of specific modules. So, depending on users needs it would be possible to e.g. only publish the deviceid address, multiple I2C ports or even all the modules available in the soc.

Of course, there is still one caveat: tools like litescope_cli would need more data than realistically could be placed into the optional data section, so some additional feature to also exchange this would be very convenient.

Alternatives I considered:

1. Define a well known address in wishbone -> almost impossible to make backward compatible
2. Have a second wishbone with CSRs that is only accessible to host bridges, store the data described above in those CSRs and then use the magic numbers to switch between the two -> seems wasteful

Any thoughts on this?