Various optimizations to schematic and layout

Various edits to schematic and layout to address concerns raised in issue #6

Hey! I didn't see this before. In my opinion this is not a good implementation of the daughterboard for several reasons.

(1) The ESD chip is misused in every single aspect

(1.1) Schematic

The TPD device used is meant for high-speed, low capacitance ESD filtering. It is not meant for VBUS filtering, and using it with VBUS here is potentially hazardous to the IC and to the motherboard the daughterboard is attached to. Not only this, by removing the other pins, you are missing a connection, under-using the component, and missing its pass-thtough quality, further mis-using it.

(1.2) PCB

This design does nothing for the ESD protection because for both VBUS and the data lines, the traces are not set in a way that perturbations are filtered; instead they go directly to the JST connector. The TPD chip does nothing for you here. This is simply badly routed.

(1.3) What I think should be done

The big defect of C3 is the usage of two different devices, one for USB ESD filtering and another one for VBUS filtering, where a device that integrates both could be used. In issue #6 I argued that this is not a huge addition in components cost, and the available space makes it near impossible to effectively route an SOT-23-6 component.

In issue #6 , you recommend usage of devices like the USBLC-6 which integrate high-speed USB 2.0 ESD capabilities and power TVS. This would have been fine to use, but then again, I justify the usage of the TPD due to the very small available space.

I do take the criticism for the bidirectional TVS, which should have been unidirectional. You could have changed that.

(2) Signal integrity

The proficient use of vias here, breaking the GND pour apart, is really concerning. This makes the EMI performance of the DB significantly worse. In C3, I made the utmost effort to keep the ground pour as integer as possible.

The USB data lines here are hugely misrouted. Not only you routed VBUS and the data lines under the USB, which is a big nono as the soldermask cannot be trusted as an insulator, the data lines are grossly assymetrical: DN has two vias where DP has naught, and the DN trace varies along the way, which is a huge source of reflection.

I did run eye diagram tests with C3 and it performed very well on the technical side, both ESD and transmission-wise.

(3) Ground loops

The GNDPWR trace, which we can define as a "raw ground" polluted with EMI and ESD, was routed in C3 as a single connection point. This is meant to achieve two things: ground the enclosure, offering ESD and EMI protection, and avoid ground loops. What you did was connect all four screw points, which might solve the EMI/ESD but allows for the loops.

In a perturbatory event like a static discharge, waves propagate through material in a limited speed in such way that we have an electrical field gradient and, therefore, a voltage gradient; this is specially important because the most used metals for cases, brass and aluminum, are not particularly good conductors. This means that in such an event, different points of the case space material have different potentials (voltages) and, by connecting all of them, you offer low-impedance paths to which those different voltages can interact, generating unintended currents that travel inside the case material, called ground loops, which not only reduce greatly the EMI performance of the protection but also generate high current spikes. The fact that they are loops also generate self-inductance, addint to EMI. I also get that it is a little uncomfortable that I connected the GNDPWR and GND of the USB connector together, but that is perfectly fine as long as all perturbations are taken care of.

(4) GND current delivery

The ground path that is offered to the JST is not a good one. It arrives from the ESD chip, with a 6 mil thickness, and from a 20/12 mil via . I honestly doubt that those paths are able to conduct the required 0.5A witout long-term stability issues.}

EDIT: by the way, please hit me up on Discord so we can design a new iteration

Since you wanted critique on the design, here goes. I'm far from an expert, but I have blown up enough stuff from ESD to know what tends to work and what decidedly doesn't.

I totally agree with Gondolindrim that the use of the ESD chip is flawed here. But I also agree with you that separating the two grounds and having a single point of contact is a good idea.

I'd probably want to use NUP4114 or similar, and explicitly connect the high side to VCC (VBUS). I'd also prefer to 'chain' the two circuits of the protection chip, as that makes the dissipation more effective and the routing clean.

cutout unified

Quick and dirty attempt. The main drawback here is that the only way I could make this work was by inverting the pins on the JST.

When mentioning that the use of the ESD chip is flawed, do you mean how it is connected (that is, wiring power lines to a data pin) or where it is placed and how traces are routed? While I can't see any fundamental reason why an ESD pin would be adequate to protect a data line but not a power line, I can concede that it isn't explicitly labeled for such use in the datasheet, and the use of NUP4114 is certainly less contentious from that point of view.

If the use of the ESD chip is considered flawed in terms of placement and trace routing, I will agree that it does create a stub which is not ideal from a signal integrity standpoint. However, we also already have a less-than-ideal stub of similar length at the USB connector (i.e. the connection to pin A7), and what I have for ESD protection is no worse.

As far as ability to actually protect against ESD, I will presume there is no disagreement in ability to clamp an ESD transient based on my placement and trace routing--but if that is not the case, let know why you think it would not work so I can understand better what the concern is.

Regarding chaining of the two circuits of the ESD chip, I don't feel strongly either way, so my only question is "why"? If the thought is that it provides more dissipation/protection against ESD, then that raises the question of what level of ESD protection is desired or required, when the cost is increased data line capacitance. (Note: I am presuming here--without test data--that TVS protection within a single NUP4114 is well-matched and will share current and power equally when wired in parallel). Also, there are no examples of such paralleling being done in the datasheet. That said, big picture....in the absence of some other requirement (for either data rate, signal integrity, or ESD protection level), I would suggest that either approach is both valid and better than nothing. This is something I could go either way about.

Now the most interesting part: yes, the circuit layout does become much much simpler if we can swap the data pins on the JST connector. However, unless you know of a way to obtain a reverse JST connector (where you plug the connector in upside-down relative to the typical/standard connector), this amounts to a breaking change, as you mention in your latest comment on the issue. Swap the pins, and you no longer have the same electrical interface as other Unified daughterboard...incompatibility. And if you put the JST connector on the bottom of the board, then you no longer have a compatible physical envelope...incompatibility: keyboards designed for a flat-bottomed Unified C won't be able to use it. So there is the rub: can we fit a NUP4114 between the two connectors with the vias necessary to successfully route the connections? I can try with the NUP4114, but to avoid via-in-pad, my solution with the TPD4E05U06DQAR was to just move it off to the side. Short of getting a custom connector made (an upside-down JST), I haven't come up with an ideal approach. I would suggest that if a pin swap does happen, it should happen in lock-step with some other mutually-exclusive breaking change, like using 5-pin JST connectors, just to make the non-backwards-compatibility physically obvious.

When mentioning that the use of the ESD chip is flawed, do you mean how it is connected (that is, wiring power lines to a data pin) or where it is placed and how traces are routed? While I can't see any fundamental reason why an ESD pin would be adequate to protect a data line but not a power line, I can concede that it isn't explicitly labeled for such use in the datasheet, and the use of NUP4114 is certainly less contentious from that point of view.

If the use of the ESD chip is considered flawed in terms of placement and trace routing, I will agree that it does create a stub which is not ideal from a signal integrity standpoint. However, we also already have a less-than-ideal stub of similar length at the USB connector (i.e. the connection to pin A7), and what I have for ESD protection is no worse.

I totally agree that we have stubs on the data lines no matter what we do to some extent, but in your implementation they were a bit too much for my liking. I'm not saying my way is the right way, but I think we can find a workable compromise somewhere.

As for the way you protected the VCC line, it probably does sort of what you want it too, but the point of using the NUP chip instead is that it doesn't just protect the VCC, but also uses VCC as a reference for the other TVS diodes, biasing them and reducing capacitance for each diode. Ie, you get protection on all lines, and make the whole thing more efficient in one go.

As far as ability to actually protect against ESD, I will presume there is no disagreement in ability to clamp an ESD transient based on my placement and trace routing--but if that is not the case, let know why you think it would not work so I can understand better what the concern is.

Regarding chaining of the two circuits of the ESD chip, I don't feel strongly either way, so my only question is "why"? If the thought is that it provides more dissipation/protection against ESD, then that raises the question of what level of ESD protection is desired or required, when the cost is increased data line capacitance. (Note: I am presuming here--without test data--that TVS protection within a single NUP4114 is well-matched and will share current and power equally when wired in parallel). Also, there are no examples of such paralleling being done in the datasheet. That said, big picture....in the absence of some other requirement (for either data rate, signal integrity, or ESD protection level), I would suggest that either approach is both valid and better than nothing. This is something I could go either way about.

Doubling up on the USB data lines isn't mentioned in any datasheet AFAIK, but that's the way I was taught to do it by my mentor with years of experience, with the only expressed reasoning that if you have a diode, its better connected than not. And while I really haven't put more thought into understanding it than that, having practically tested both scenarios on an otherwise identical circuit with an ESD gun, it did in fact survive 'more' with no other negative effects that I could find or measure in any meaningful way.

You are entirely correct that there should be more capacitance on the data lines, but with the correct TVS chip and proper biasing, I haven't really found it to be an issue, and in many cases the capacitance is even lower with the bias, than with a single TVS and no bias.

Now the most interesting part: yes, the circuit layout does become much much simpler if we can swap the data pins on the JST connector. However, unless you know of a way to obtain a reverse JST connector (where you plug the connector in upside-down relative to the typical/standard connector), this amounts to a breaking change, as you mention in your latest comment on the issue. Swap the pins, and you no longer have the same electrical interface as other Unified daughterboard...incompatibility. And if you put the JST connector on the bottom of the board, then you no longer have a compatible physical envelope...incompatibility: keyboards designed for a flat-bottomed Unified C won't be able to use it. So there is the rub: can we fit a NUP4114 between the two connectors with the vias necessary to successfully route the connections? I can try with the NUP4114, but to avoid via-in-pad, my solution with the TPD4E05U06DQAR was to just move it off to the side. Short of getting a custom connector made (an upside-down JST), I haven't come up with an ideal approach. I would suggest that if a pin swap does happen, it should happen in lock-step with some other mutually-exclusive breaking change, like using 5-pin JST connectors, just to make the non-backwards-compatibility physically obvious.

I'm fully aware that my changes there was changing things that would end up being incompatible. Hence why I jumped into this discussion, as I couldn't decide which way was the right way even in my own reasoning. As I said, I like the idea of a unified design and attracting as many designers as possible into using it, but I feel the current design is holding back too much on the most important parts, ie protection and signal performance vs being compatible and catering to users plugging things in the wrong way (as per Gondolindrim reply) which I agree is also important, but secondary to the other design goals.

I hadn't though of using a 5-pin JST, but that's probably a great way to separate the two designs and make it obvious.

Unified-Daughterboard / UDB-C-Legacy