UFP, DisplayPort only, no USB SS, not captive cable - Is mux required?

Hi Diego,

Thanks for the reply. Can you point me to where this is detailed in the Type C spec? (I downloaded the whole thing and searched through it, but couldn't find a specific reference)

Also would you happen to know the 'why' behind it? Is it for cable orientation, or some other reason?

Thanks,

Jonathan

Hi Diego,

Thanks for the detailed follow-up. It seems like it might be a 'soft spec' in that it would be advised for the UFP to have the multiplexer, to ensure it's capable of properly routing all DP signals regardless of source crosspoint capability. Perhaps this will be more directly addressed in future spec revisions.

Until then, I'll consider a mux like HD3SS460 'required' for this DP-only use case, for maximum interoperability with DFPs.

Jonathan

Jonathan,

In all of your replies, I see you asking for the reason behind the rule or you point out the maybe this is a "soft spec."

The reason behind the rule is very simple, and this is definitely a hard & fast rule as opposed to a "soft spec" or a suggestion.

Consider the following 2 cases:

1. DisplayPort/USB Dongle that connects directly to a laptop w/ a Type-C plug (aka "captive cable")
   • From the dongle's perspective, the orientation of the cable is always the same because it is the cable
   • There are only 2 ways to plug the dongle into the laptop, the laptop detects the orientation and automatically muxes the signals appropriately
   • In this case, a SuperSpeed mux like the HD3SS460 is not needed
2. DisplayPort/USB Dock that connects to a laptop through a Type-C cable that is inserted into a Type-C receptacle on both ends
   • From the dock's perspective, the cable can be inserted in either orientation because the Type-C cable is reversible on both ends
   • In total, there a 4 different orientations that a user can insert the cable, so even when the cable is plugged in right-side up on the laptop it may be plugged upside-down on the dock. In this case, the laptop has no need to mux, but the dock does
   • In this case, a SuperSpeed mux like the HD3SS460 is needed

Please refer to page 109 of the USB Type-C spec for a description and diagram that explains this more clearly.

 

Hi Brian,

Thanks for your timely reply, as I was still investigating this. After reading through the referenced spec, I can see how a UFP port (non-captive) without a mux would have to accept the high speed lanes in whatever configuration the cable orientation created.

However, I've been told that there are many DisplayPort receivers that are capable of muxing the lane order internally (so which pins lane 1-4 data come in on are unimportant).

If that's the case, can you think of any other spec/interoperability-driven reasons why the mux would be required? Let me be clear that I'm not asking for a blessing on not using a mux, as that's clearly non-standard, but just for the sake of digging more into the why.

It looks like we may be past Type C-specific spec, and have to refer to 3.1 spec in general, based on this line on page 110 of the Type C spec: "The functional requirements for implementing SuperSpeed USB data bus routing for the USB Type-C receptacle are not included in the scope of this specification."

Table 6-21 of the USB 3.1 spec (page 195) shows that the minimum Rx DC common mode impedance during reset and power down (when the lanes should be high-Z) is 25 kohm. So as long as the DisplayPort receiver has the lanes sufficiently high-Z when the port is unconfigured, that should not violate that particular spec. I searched through the 3.1 spec for other instances of 'impedance' and 'multiplexer' and didn't find much else in the physical layer sections, but admittedly it's a big document that I'm largely unfamiliar with.

Thanks for the help,

Jonathan

Jonathan,

What you are referring to here may exist: "I've been told that there are many DisplayPort receivers that are capable of muxing the lane order internally (so which pins lane 1-4 data come in on are unimportant)"

In my experience, the only Video/Data Tx/Rx IC that can do this internally is the Intel Alpine Ridge chip for ThunderBolt3 applications, which supports the full TBT spec (DPort + PCIe) plus USB2/3 over 2 independent Type-C Ports. The TPS65982 is currently the only approved USB-C/PD Port Controller that is a companion chip to Alpine Ridge.

The full data path is simply 1 Alpine Ridge (AR) + 2x TPS65982s (1 for each port), where the SuperSpeed signals go directly from AR to the ports and the FullSpeed signals are muxed appropriately through the TPS65982's. Even in this case, though, the TPS65982 is responsible for informing AR what Data connection is present and the polarity of the Type-C Cable.

I'm sure there are others Video/Data IC's like Alpine Ridge in development or already on the market, I just don't have any vendors or part #'s to recommend because TBT3 is the leader in this space and was first to market.

I am not the authority on the USB3 Spec or Electrical Requirments for SuperSpeed signals, so I cannot provide much insight into Table 6.21

SS mux is not needed for captive cable w/ plug or plug only implementations.  Only needed for receptacle implementations.

Mux may be needed for USB2 path but it would be implementation specific.  Please also note that billboard is required for Alt mode devices.(which may require muxing)

Hi Brian, Yoon,

Thanks for weighing in, and providing some additional context. Since I've taken the question a bit further than the initial post's scope, and it looks like we'd need to really start talking in specific terms about the downstream chipset, I'll go ahead and close this discussion.

Jonathan