Is that not what the author is referring to? From the readme of his LiteDIP project[1]: "Plug-and-play LiteX-based IP blocks enabling the creation of generic Linux drivers. Design your FPGA-based SoC with them and get a (potentially upstream-able) driver for it instantly!"

[1]: https://gitlab.freedesktop.org/mupuf/litedip/

There isn't anything there apart from the readme.

I built a descriptor block into a FPGA design about 15 years ago, this was for PCI so I could put it at a fixed offset into the BAR for every device.

I don't see how the "get a (potentially upstream-able) driver for it instantly" would work. Someone would still need to write a driver, you just get a way to probe for whether to attach it or not.

Sorry about that, the project is still very early. Check out the fan_wip branch for actual code.

The point of LiteDIP is to provide both the IPs, and their drivers.

Also, rather than needing IPs to be located at a certain address in any sort of bus (PCI BARs, wishbone, ...), litedip exposes the list of IPs starting at address 0 along with their version and relative address.

The driver then lists these blocks, and either has a driver for this block's version or not.

i agree it's kind of confused. But from a compiler dev perspective (which i think is closer to OP's perspective), driver means a piece of software that put together components / tools and bootstrap the processing pipeline