The closest COTS hardware I could find to match my thoughts is the Red Pitaya (linked here). It has a Xilinx Zynq FPGA with dual core ARM processor, dual 14 bit 125MHz ADC and dual 16 bit 125 MHz DAC; potentially a complete radio on a single, credit card sized board. It doesn't have a display interface - instead it uses a web server to a PC, tablet or phone for display.
Pavel Demin has created some SDR applications for the Red Pitaya, so I will have a good starting point (link). One of those is an HPSDR compatible transceiver, mimicing the Metis interface. Another is a complete standalone radio. So I set about following Pavel's example code, intending to load, compile and dabble with each of the examples in turn.
The next problem is: I've never used Linux. Unfortunately for me, all SDR software development seems to be Linux based. I tried using Ubuntu linux in a virtual machine in my laptop; unfortunately the laptop really didn't have enough memory and wasn't upgradeable so I purchased a second hand core i5 laptop from ebay, and installed Ubuntu natively. But going through the compile process - that rebuilt an application, and the PC, and the linux environment for the embedded processor, was heavy going and no one set of instructions was quite right. I needed a simpler learning curve.
I have an old HPSDR board set (Ozy, Penelope, Mercury) with USB interface that I'd bought secondhand, but done nothing with. I looked at the Linux code available (GHPSDR3, GHPSDR3-Alex) but never made them work. I suspect that the vintage of Ozy/Mercury/Penelope meant the protocol wasn't correct. I could get the USB boards working with PowerSDR mrx, but they stopped working after a few minutes... eventually I found something telling me to replace the polysilicon fuses with a piece of wire, because they are known to be under-rated.
The I found pihpsdr, by John Melton G0ORX. This runs on a Raspberry PI2 or newer, and provides the signal processing and user interface for a radio with sample rates up to 9600 or possibly 192000 samples/second. This runs on a processor board costing £30, but with accessible IO and John has interfaced pushbuttons and rotary encoders. Add a touch screen LCD and you have the basis of a radio with touchscreen display AND "proper" knobs and buttons for an affordable price. The only catch: it supports ethernet interfaced HPSDR, but not USB.
Then I found code for "Ozy_Metis_Rpi_Gateway" on the HPSDR code SVN site. That builds a program "ozymetis" that claims to interface USB hardware to ethernet. After a lot of messing around I was able to build and run it on a raspberry PI mk 1, where it flatly refused to work with USB transfer failures. On-line advice was that libusb-1.0 is stable, but not on early RPI units. So I bought a Raspberry pi 3, and the code did run on that when connected to PowerSDRmrx on the PC. I was also able to run it on my laptop. Unfortunately, pihpsdr wouldn't work through it (discovery was OK but no sample data flow).
Christmas week, so some time at home.... I downloaded and learned Wireshark and could look in detail at the ethernet packets. That told me two things: The "START" packet only came out from the raspberry PI after 8 data packets; and the data packets had different control byte settings. The first issue might simply be because UDP packets aren't guaranteed to arrive in the order they were sent; the latter definitely points to different behaviour in the SDR software.
OK, a few changes to the data handling in ozymetis sorted out the first problem. I made a "quick fix" to change the C1-C4 control bytes when C0 is 0; after that pihpsdr worked. I've tidied it up and given it command line options for ethernet interface and whether on not to modify the control data packets. In getting this far, I've learned something about programming under Linux; accessing USB; and I know the USB and "old" HPSDR ethernet protocols reasonably well. It looks likely that different radio programs would need different "fixes" in the protocol converter; so it's unlikely to be a widely reusable generic program.
If I were to be cynical, I could suggest that using recognised international standards for the data interface (eg VITA49.1) might have avoided a lot of this.
My next step is to try to add native USB support into pihpsdr. At the end of that, I'll be well down the road of learning how to do business in a non Windows world. I still haven't got started on the signal processing yet!