This year I've considered, tested (and am still testing) a few ASIC solutions for 480 Mbps USB galvanic isolation, and I plan to write a detailed article about it, but here's a quick summary. TI's new ISOUSB211 ASIC is going to be the real game-changer, solves the problem completely, and it will also make my entire year's experiments, described below, almost meaningless. If you just want a working 480 Mbps USB 2 solution, don't read this post, just wait for TI's ISOUSB211.
- There are ASICs specifically made for this purpose, for example the Silanna USBB. But they are not available on the open market, so they practically don't exist. On the other hand, I found there are some useful USB ASICs you can actually buy, they're designed for cable length extension. But these chips can be abused for galvanic isolation, with an important caveat: device compatibility and performance is not guaranteed (more on that later).
* WCH CH317 (both CH317Q & CH317L): USB 2.0 extension ASIC via Ethernet. Made by the same company, WCH, known for its CH341 USB serial chips. The CH317 ASIC has a custom USB controller, the USB traffic is converted to Ethernet (but not TCP/IP) traffic in its proprietary protocol and sent to the on-chip Ethernet MAC, then it outputs the data via Gigabit Ethernet's RGMII interface. Just connect a Gigabit Ethernet PHY, and you're good to go. The chip on the far-side converts Ethernet to USB. The Ethernet transformer is for galvanic isolation. If that's not enough, you can also use Ethernet PHY with fiber-optics support for optical galvanic isolation, or - since it's standard Ethernet data in RGMII - even an FPGA for handling it in your own way.
---(USB)---> CH317 ---(RGMII)---> Ethernet PHY ---> Transformer ---> Ethernet cable
Result: Bad performance, no faster than 80-100 Mbps. So while USB 2 HS is technically supported, usefulness is very limited. Basically only usable for flash drives. Don't buy any device based on the CH317.
Why? An educated guess is that USB 2.0 HS is not designed for long-distance communication in mind, but this chip is designed for up-to-kilometer extension, so it possibly uses some underhanded tricks to work around the problem - basically emulating a USB device on the near-side based on the data from the from far side, and vice verse. For example, if the far-side is not ready yet, the near-side may simply fake a NAK to trick the host to wait longer. Obviously such emulation can't be perfect, which limits compatibility, and also with a serious performance penalty.
* Norelsys NS1021: USB 2.0 extension ASIC via CAT-5e/coax/phone line/USB cable. This ASIC has likely a custom USB controller with proprietary protocol, its output is a single-pair of true differential & DC-balanced signal, which then can be sent for transmission over single-pair phone line, CAT-6, or coax. Because it's truly differential, an AC-coupling capacitor or RF transformer can be used for isolation. The variant NS1021E, uses two differential pairs, so a 100 Mbps Ethernet transformer can be used. Full performance is advertised by the company, likely because it's only designed for a 50-meters extension, so it's is much less invasive to the USB logic than CH317.
A potential limitation is that the output uses either full or half-duplex signaling (unsure, not documented), so the signal is bidirectional, not unidirectional, so again, same problem just like USB 2 HS traffic itself - you can't treat it as a standard digital signal output and hook it up to a standard differential transceiver like an FPGA or a SFP+ module, which limits your option. Ethernet or RF transformers cannot be relied upon for isolating serious voltages or high-frequency noises (but at least for the noise, the signal is now truly differential, you can just use common-mode chokes to suppress it).
Result: work in progress.
- USB 3.0 isolation
* VL670/VL671 USB-3 to USB-2 transaction translation ASIC.
There's also a way to solve this problem indirectly, by first creating an isolated pure USB-3 port (USB 3 is a system of its own with its own SSTX/SSRX connections, it's only backward compatible with USB 2 because the USB standard requires all USB 3 port to include the D+/D- connection to a legacy USB 2 controller, so theoretically you can have USB 3 without USB 2 support, which is what we're doing here).
Then, we use the VL670/VL671 USB-3 to USB-2 ASIC to provide USB-2 support. The VL670/VL671 translates the legacy USB 2.0 traffic and transparently upgrades the device to an USB 3.0 SuperSpeed device by emulation. Just like a USB extension controller, this is not a perfect solution, device compatibility is limited due to imperfect emulation. But can be useful.
Why USB 3? Because it's much easier than USB-2.
USB 2 HS (480 Mbps) uses a nonstandard differential signaling scheme that is not truly differential - it also has single-ended signals like Single Ended Zero, essentially making USB 2 HS incompatible with standard differential transceivers, so you must use a USB 2 PHY and work at logic level rather than electrical level. Worse, the signaling has been further bastardized by using half-duplexing, the D+/D- signals are bidirectional, so you actually have to design a USB controller to read the protocol to do bus arbitration. The protocol, due to its synchronous and half-duplex nature, also has timing constricts that can be hard to meet.
On the other hand, USB 3 is much simpler. It uses two pairs of unidirectional, 8b/10b encoded, CML-like differential signals, and operates asynchronously. This type of signal is commonly found in almost all high-speed digital systems. For example, you can literally just run the USB 3 signal into an SFP+ 10 Gigabit Ethernet optical transceiver (an SFP+ 10 Gigabit Ethernet transceiver is protocol-agnostic, it can be used to transmit any differential signal), and bingo, an isolated USB 3 port. Even better, it's fiber-optics, it can easily isolate 10 kV or more, including fast transients. (well, full-spec compliance, with proper support of power management is difficult, but a port that somewhat "works" to a certain degree for many applications is easy to create).
Result: Successful. Almost done by now. VL670/VL671 was a success. Compatibility is good enough for my purposes. the USB 3 to SFP+ transceiver is work in progress, but an early prototype was almost a success. Implementing full-spec compliance, with proper support of power management was originally my long-term goal.
Also attached are two considered but discarded solution.
- The first solution is using a USB 2 PHY, the analog side is D+/D-, and the logic side is the ULPI or UTMI, which is basically a parallel digital data bus, and hook it up to a FPGA. Then use the FPGA to forward its logical status to another FPGA and its USB 2 PHY. Communicate and synchronize the status of both FPGAs with high-speed SERDES, isolate the parallel SERDES interface with high-speed digital isolators. But this is also difficult and it's only an option if you're an USB expert (I'm not), it means you're basically designing a custom USB controller. Also, theoretically, the second FPGA and the SERDES are not necessary, perhaps you can use a single FPGA, two USB PHYs, and put isolation on the ULPI/UTMI interface instead. But this data bus has more serious timing constraints and I'm not sure how practical it is.
Result: idea considered but discarded, difficult and expensive, but can be an option for USB experts. Some industrial products use this solution.
- The second possible solution is Inter-Chip USB or HSIC. It's basically USB but uses LVCMOS logic without analog PHY, avoiding the analog transceiver headache entirely. There are also USB-to-HSIC hub chips to convert USB to HSIC and vice verse. It looked promising and seemed to make things much easier at first glance, I felt like one can just put relatively dumb logic at the HSIC interface without caring too much about the protocol at all. But HSIC is still uses bidirectional, half-duplex signaling, so you still need to create a USB controller to read the protocol, do bus arbitration, with the USB and HSIC-bus latency constraints.
Result: idea considered but discarded.