I have never been able to identify a technical barrier to doing this, the important features most people actually care about are implemented over a 1x PCIe link and USB, plus a couple of GPIOs to twiddle the power/reset button connections. Most OEM implementations also connect to the LPC bus and others on the server board to allow more in depth diagnostics, voltage logging, etc. but those are bonus features and not requirements for a useful product. I do not see any technical reason a useful generic PCIe implementation couldn't be produced, and as a result I have a strong feeling that the lack of such products is an intentional choice by one or more of the vendors involved to increase margins by pushing users who want these features up to entry level server boards instead of sticking a card in a higher-end desktop board that might better fit their needs.
I have one, it works. Look at that board though! Given that component and board density, I don't find it very surprising that it costs around 200$ USD. Maybe you could get clever and design one that tries to work 100% via pcie device functions, and cut down the (physical) complexity of the IPMI device, but then the wide system and interface compatibility of the IPMI board would suffer.
To wit, the card needs to do the following, at a minimum:
1. Provide a VGA/UEFI/VFB-equivalent framebuffer for display capture
2. Provide a USB-device interface to emulate keyboard+mouse.
3. Provide a network interface of some sort for remote control
4. Provide GPIO headers/sinks at the appropriate power levels to replace traditional motherboard front-of-device switches -or- provide a PMBus header to perform equivalent functions with a support PSU.
You can get away with a subset of the above, but without that, you will be missing something critical to enabling lights-out-management. On top of that, a full-featured IPMI board is also generally expected to provide some fashion of environmental monitoring and fan control, which the PAUL does provide. It throws in some extra features as well, and provides some maintenance/lifecycle management capabilities of the board itself.
Providing all the above, is about the same amount of complexity of shipping a SBC and ecosystem itself, made moreso by the compatibility requirements.
You don't have nearly as big a market willing to pay $200 for all that -- its certainly not a matter of adding the chip and flash and dropping some vias.
Even having a standardish system-on-chip and non-bespoke firmware is 'new' (post-2020?). It could have been done 10-15 years ago sure, but noone was willing to do the long tail of tasks needed to get a product to market yet.
I was aware of these but I could have sworn when they came out they at least were only officially supported on ASRock Rack motherboards. That doesn't seem to be the case anymore, or I'm just entirely misremembering.
They do still seem to have the standard ASRock Rack problem of being very interesting to "homelab" and other small volume users but not exactly straightforward to obtain. No one who'll let me buy a single unit brand new has them in stock.
Definitely set an auto-notify on Newegg now that I know they work with generic motherboards, though it's a fair bit more expensive than a NanoKVM it's a lot more appealing to me to actually be a complete standalone internal device that doesn't rely on external wiring to function. The various "PCIe" versions of the PiKVM and its ilk still require an external HDMI connection and sometimes even external power.
That's what they claim. Until another binary closed source firmware upgrade arrives, of course.
I'd love to see something like this where the board had a basic video card, so you could use it in a system without any video output. Bonus if it also had a usb controller and a serial port, so it didn't need to loop to plugs (although some of that could happen on the internal side as well)