What kind of PLL is used to recover the clock from E.G. USB 2.0 data stream
TL;DR: The terms you need to know are PHY, SERDES, and serial transceiver.
I don't think the answer to &quot;what kind of PLL&quot; would be helpful, since anyone wanting to use USB 2 in their design wouldn't be ordinarily building a clock recovery circuit from scratch, and thus there's no need to bother with PLLs or anything such unless you're designing silicon or otherwise need/want to implement the physical layer from scratch.
Typically, the function that implements the physical layer of some communication protocol is called a PHY. You can get PHYs as stand-alone chips, or built into FPGAs, ASICs and microcontrollers. So, if you have an FPGA without a built-in USB 2 PHY, you can get an external one for a couple bucks (e.g. TUSB1210). You can use such PHYs without implementing the entirety of the USB stack, of course. Same goes for Ethernet PHYs, although those don't support bidirectional communication over a single twisted pair. On the other hand, Ethernet twisted pair cabling in your speed range is so ubiquitous and cheap that using it may actually be cheaper than something custom, especially if you need potentially long cables.
The big advantage of using a PHY for a widely used consumer serial protocol like USB  is that it's cheap. You can go faster by using specialized single-chip SERDES functions. SERDES stands for SERializer/DESerializer. They are faster but not as cost efficient. For example, DS92LV16 would do what you want: you can connect the transmitter and receiver together on each end, RS-485 style, and use the transmitter/receiver power-down controls in half-duplex mode. The minimum data rate on that device, though, is 50MByte/s, i.e. it needs a 16-bit word clock of at least 25MHz, up to 80MHz. The bit rate is up to 2.56Gbps. This particular one needs a &quot;rough&quot; reference clock on both ends, i.e. if you decide to use 25MHz word clock, you will need a 25MHz reference clock on both ends of the connection from a local source, but it doesn't need to be terribly accurate: the PLL compensates for up to +/-5% absolute clock frequency error between transmitter and receiver.
And finally, you'd definitely want to consider the on-board serial transceivers that may be available in the FPGA proper. Don't let the name mislead you: they are usually gigabit speed devices, not much related to asynchronous UARTs or anything like that. These days, there plenty of affordable FPGAs with built-in transceivers that can be used exactly for what you intend. Using an external PHY or SERDES would make sense if you wanted to limit yourself to FPGAs without built-in serial transceivers (for whatever reason), and/or wanted to add a bit of a retro feel to the device. Finally, using a USB 2 HS PHY with the board laid out for OTG operation may allow you to use some ad-hoc protocol for the time being, but eventually support actual OTG operating mode once you get it implemented (in the firmware of the CPU/core and the bitstream). This may be useful in some cases to extend product functionality while keeping the same board design, but would require careful attention to the requirements of USB 2 OTG spec to ensure that the board itself would support necessary functionality (power switching and such).