Is the Google coral edge TPU USB compliant? #tensorflow
The documentation is pretty worthless.
The #Google coral support doesn't respond anymore.
The TPU is able to run the demo on my rpi3. The jpeg is analysed and returns the correct ouput. This is due to the rpi3 being USB2.x compliant. It has no USB3 host.
I went dead silent after the initial reply by the coral support team @Google.
They say USB 2 in the virtual machine doesn't work. And I have USB 3 host enabled. Now, USB3 is much more complicated than USB2. I did the bare metal USB 2.x and USB 3.x bringup for device and host of the Movidius Fathom USB stick based on Myriad 2. The enumeration is the first step and this is depending on the host and the OS used on the host side. Second, after enumeration, USB3 has a lot of power saving capabilities. Via a "set feature" descriptor, the host will try to enable the U2 power saving mode. This is what the wirsehark sniffer shows me. The "set feature" is returned as complete. Both U1 and U2 are set feature enabled, a bit before the set feature those two features were cleared. It looks suspicious (Ubuntu 16.04 LTS).
The device descriptor returns the vendor ID, which is GUC, the ASIC developer for Google.
bcdUSB is the USB version it supports, v3 gen 1.
Device class is 0x0 meaning each interface defines its own class.
bcdDevice is version 0x0100.
One configuration reported so let's look at the configuration descriptor.
Wireshark is correct, it reports as not self-powered and no remote wake-up. Let's keep that in mind. Next is the interface descriptor.
It has only device firmware upgrade protocol support (DFU). There are no string descriptors available. Then the configuration is set (configuration is one, see below).
Then a get status to check the status of the interface. Which seems to complete as well.
It is weird to have a device that only supports the firmware upgrade via endpoint 0 (which is the reserved control endpoint in both directions). It has no endpoints for transferring data, for example a picture via a BULK IN and OUT endpoint pair. But we didn't look at the BOS descriptor yet.
The USB standard added Binary Device Object Store descriptors for devices that report a bcsUSB version higher thean 0x200 (see above, the coral eTPU reports 0x0310) so it must request the BOS descriptors from the device. BOS is related to LPM, link power management for USB devices. The first BOS returns the size (0x16 which is 22 bytes) it needs to request the second time. It requests 54 (is 32 + 22 bytes) bytes which is the right size. But the capability it returns is at this moment jibberisch to me.
I suspect that the BOS descriptor needs to clarify it doesn't support LPM at this moment, which probably makes sense at this moment because low power is not a priority when using the eTPU. My best guess is the set feature U1 and U2 should be NACK-ed or made clear it doesn't support it. At this moment, it looks like the device is not USB3.x compliant, it looks like it has been prepared only to work with raspberry pi and not with the actual USB standard in mind. As usual, we see influencers that are receiving those things for free or guys that write about the stick and run a demo give a thumbs up. But this looks like an alpha product that was rushed to the market without the required expertise and extensive experience with the USB protocol. Google is no hardware company but they could at least find the experts that can deliver hardware. They are roasting software engineers to hire the bet of the best, why don't they hire the best in hardware?
Anyway, I am looking forward to Facebook open sourcing their RTL for the open compute hardware. They announced it but it is not released yet. Like Google, their background is not hardware design. My prediction is that the RTL will reveal this as well. Hardware is NOT software, it is a specific, very specific skill set.