Need to associate USB HS and SS physical interfaces

[jadonk]

The HS and SS physical interfaces don't have independent controllers. We'll need to wire things up closer to the AI SK EVM.

1. For the Type-C, we'll need to move one of the SuperSpeed physical connections over to it, because it is useless when not associated with the HighSpeed physical connection. This also means considering cable-swapping and CC signals. There is feedback on the previous BeagleBone AI solution that might be worth considering. I'll try to dig it up.
2. For the 2xType-A, we'll need to add a 3-port SuperSpeed hub.
3. HighSpeed hub will need to be connected as a downstream to the SuperSpeed port.

Related:

• USB 3.0 does not work #4
• TYPE-C USB device not work #6

[FionaYu20180326]

We discussed this before starting schematic design. We chosen USB2.0 HUB because the board size is too big. And cost for USB3.0 HUB is $3.2 on TI store. USB2.0 we use now is $1.5.
We can change to USB3.0 but the board size should be bigger. There are extra power circuit for USB3.0.

[FionaYu20180326]

About USB3.0 Type-C, TI TDA4VM Edge AI Kit have 2 Type-C connectors. One is only for power and one only for data. If we want to have one 3.0 Type-C connector for both power and data, the design is hard for us, we need more extra time to do research.

[jadonk]

Why should the power be so much higher for the hub itself, rather than the ports? The hub device it self is so power hungry? Unfortunately, there are only 2 USB controllers, so the idea did not work. Dual-role USB on the Type-C connector and HS USB host over the headers are requirements, but a single Type-A connector could be fine. Would a 2-port superspeed hub (TUSB8020B) be any more space/cost effective? It seems there is part inventory as well.

It seems both TUSB8041 and TUSB8020B consume up to about 400mA1.1V and 50-100mA3.3V when having 1 SuperSpeed and 1 HighSpeed downstream ports. Is that enough to drive significant needs for power management?

[JunqingXin]

@jadonk Hi Jason, do you want add USB3.0 HUB like this?

[mvduin]

Note that a power-sink-only port can only negotiate device data role initially and requires Data Role Swap (via PD signalling) to support host role. Therefore if it is desired that the USB-C port supports host role (e.g. for connecting to a charging dock) then the TUSB321/322 does not suffice, something that supports PD signalling would be needed like the TPS25750D or TPS65987D. See also beagleboard/beaglebone-ai#56

[JunqingXin]

There are two Type C connectors in TI's demo, one for power in the board only without USB signal, the other is USB3.0 DRP (Dual Role Port), can power out when used as DFP, but can not power in when used as UFP.

[mvduin]

the other is USB3.0 DRP (Dual Role Port), can power out when used as DFP, but can not power in when used as UFP.

Well it will have power sink role as UFP, it just won't use any of that power (other than to charge the capacitors on VBUS_5V0_TYPEC). And of course it also can't take on power source role as UFP (like a dock) since that would require a PD-capable type-c controller (to perform Power Swap if initial-UFP or Data Role Swap if initial-DFP).

[jadonk]

For immediate release, I simply cannot come up with a solution. What happens if we limit everything to high-speed? beagleboard/BeagleBoard-DeviceTrees#44

[jadonk]

The right design would do USB-PD signalling to perform a data role swap, but would not provide power via Type-C. There is no need for a second Type-C connector. Unsure if the design can be simplified enough to fit in the existing ~100x80 footprint. A SuperSpeed hub would still be required.

[mvduin]

If you use a high-speed hub for the downstream ports then it would become especially important to support host role (through PD data role swap) on the USB-C port since it would be the only available superspeed port.

[FionaYu20180326]

Any conclusion about how to re-design?

[jadonk]

@mvduin The proposal is to use a SuperSpeed hub and 2x Type-A superspeed ports now. Any suggestion for a PD device that will just say we are a power sink with dual-role data?

[jadonk]

TPS66120 ?

[jadonk]

@FionaYu20180326 FYI, this is how I got the AM5729 to work as a SuperSpeed host over the Type-C connector: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/885254/beagle-3p-bbone-ai-usb-3-0-support-through-usb---c-on-bb--ai-board?tisearch=e2e-sitesearch&keymatch=BBONE-AI%20usb%20kridner#

[mvduin]

@jadonk That however violates the standard and is absolutely not guaranteed to work. The type-C controller negotiated device role for the BBAI and host role for the attached hub so forcing the usb controller into host mode is a protocol violation (and possibly risks a drive conflict? depending on how the usb3 signalling works exactly, haven't dug into that). The reason it works is because your hub itself doesn't implement a dual-role port properly and instead is always in device data-role.

[jadonk]

Proposal:

• Type-A port, M.2 and header:
  • Add 4-port SuperSpeed hub to USB1 HS/SS as uplink (Seeed choose best SERDES)
  • Use HS/SS downlink connections to 2x Type-A ports
  • Use HS-only downlink connections for M.2
  • Use HS-only downlink connections for header
• Type-C port:
  • Add TPS66120 for PD to identify as a power sink at all times
  • Add HD3SS3220RNHR (same as AM5729-based BBAI) for CC/cable-swap to handle dual-role mode
  • Use USB0 HS/SS with no hub in the middle (Seeed choose best SERDES)

Alternate proposal if size/cost cannot fit (no host mode on Type-C) (still need to verify this is possible):

• Type-A port, M.2 and header:
  • Add 4-port SuperSpeed hub to USB1 HS/SS as uplink (Seeed choose best SERDES)
  • Use HS/SS downlink connections to 2x Type-A ports
  • Use HS-only downlink connections for M.2
  • Use HS-only downlink connections for header
• Type-C port:
  • Add TPS66120 for PD to identify as a power sink at all times
  • No need to handle CC/cable-swap as we'll always be on the downlink side (device, never dual-role or host)
  • Use USB0 HS/SS with no hub or switch in the middle, only ESD protection (Seeed choose best SERDES)

[mvduin]

I'm confused here, neither the TPS66120 nor the HD3SS3220RNHR is a PD controller. I mentioned two type-C controllers with PD support (and more specifically data role swap) in an earlier comment, TPS25750D and TPS65987D.

BTW I saw in the TDA4VM TRM that the superspeed lanes can be swapped in software so that part doesn't require an external mux, assuming this mechanism works.

[jadonk]

Those PD controllers are source/sink. Is there a cheaper sink-only PD controller? Are there any with stock in the TI store?

[jadonk]

I'd searched for PD devices for power sink function, but failed to set the type to PD controller.

Unfortunately, it seems there is 0 stock on any suitable PD controllers: https://www.ti.com/interface/usb/type-c-and-power-delivery/products.html#p1241=PD%20controller&p3109=Sink&sort=p3318;desc

[mvduin]

Yeah TI doesn't seem to have Type-C PD controller without integrated source or source/sink power path, or at least I didn't find any. I recall that last time I searched for type-C PD solutions in TI's catalog I had even more trouble finding anything suitable. The TPS25750D seems to be fairly cheap though, cheaper than the HD3SS3220. Stock seems to be a problem with just about every IC on the planet right now. TI has no stock of the HD3SS3220 either.

[mvduin]

Note that I haven't studied these parts in much detail beyond checking for PD data role swap support. I don't know if there are still unpleasant surprises hidden in the datasheet. The TPS25750 does at least state it is also "optimized" for "power consumer only (sink)" applications in addition to source-only and source/sink applications. Might source-support not a benefit anyway, given that there's also a 5V DC jack to power the board? That would allow connecting low-power usb3 devices (including self-powered hubs lacking PD support on their upstream port) to the type-C port that do not share bandwidth with the type-A ports.

[jadonk]

OK, to lock down a proposal I can actually get executed, let me make this the official proposal:

• Type-A port, M.2 and header:
  • Add 4-port SuperSpeed hub to USB1 HS/SS as uplink (Seeed choose best SERDES)
  • Use HS/SS downlink connections to 2x Type-A ports
  • Use HS-only downlink connections for M.2
  • Use HS-only downlink connections for header
• Type-C port:
  • Assume we'll always work as downlink and ignore the dual-role issue for now, since we have 2x Type-A SuperSpeed ports
  • Use USB0 HS/SS with no hub or switch in the middle, only ESD protection
  • Connect SS SERDES to each side of the cable such that we can define the cable-swap behavior by software
  • Continue to connect HS to both sides of the cable
  • Continue to do simple hardware pull-up/down for CC/PD based on sufficient current from base USB 3 specification