OVC5 Rev B Hardware

[gbalke]

Using this draft to track fixes/discussions and eventually turn into a PR when discussion resolves.

Schematic Changes

NOTE: These changes will be made without any routing. Routing will come last so as to avoid continuously resolving conflicts.

• [x] Fix Enclustra module mounting holes (180 degrees off)
  • 
• [x] Top stack USB-A does not work, the USB2 differential lanes are swapped (+ / -).
  • 
• [x] Correct board thickness to properly calculate diff pair lenths.
  • 
• [x] USB to FPGA does not register as super speed, RX is wired to RX / TX to TX while they should be swapped.
  • 
• [x] USB3 lanes between FPGA and hub chip have no AC capacitors, they should be added to both TX and RX lanes.
  • Convention is to place caps on TX side. They are already on the FPGA side so only need to add to the USB hub.
  • 
  • 
• [x] Route all trigger / enable / I2C lanes to 1.8V banks (BO and BE), will probably need to reduce the number of GPIOs available on the expansion header to 4.
• [x] The chosen I2C level shifters are not recommended for use with FET based shifters.
  • The TCA9803 explicitly suggests to not pass through multiple level shifters. Some cam boards have on-board shifters and so a different chip should be used. The TCA9416 was recommended. Note that this chip is in preview and not widely available yet.
  • 
• [x] DIP footprint is for a j-lead but gull wing part selected. Switch to j-lead to fit properly.
  • Part: CFS-0300TA Nidec Copal Electronics | Switches | DigiKey
• [x] FFC connectors: currently they are oriented so they require "same side" FFC cables to be used. It seems that most RPi cameras ship with "opposite-side" FFC cables. This is what should be used.
  • The 15-pin connectors are not rotationally symmetric. The 22-pin connectors are. This means the 15-pin connectors will need to be re-routed to be rotated.
  • 
  • 
• [x] Switch capacitors to 0201 to optimize routing on bottom layer

New Features

• [x] Fan Updates
  • [x] I2C Fan controller for reduced noise
  • Something like this? Unfortunately this doesn't output at 12V so it'll probably need to drive a FET which switches the power.
  • FET: https://www.digikey.com/en/products/detail/diodes-incorporated/DMN1260UFA-7B/5027817
  • 
  • [x] Use standard 4-pin (3-pin is likely all that's needed) PC Fan Connector
  • 
  • 
• [x] Switch USB hub chip to a simpler one, USB7216C, if we want to keep type-C upstream connectivity we will need a type-C multiplexer, a good candidate is TUSB1042I.

Layout Changes

• [x] Improve power planes for USB Hub
• [x] Route Super Speed USB lines with ground plane separation and stitching
• [x] Switch Super Speed lines to 5 mil track width + 6 mil spacing
• [x] Look into different width / spacing between MIPI and USB differential pairs. USB needs 90 ohm nominal differential impedance while MIPI needs 100 ohm. It seems that if they were off by 1 mil (i.e. USB is 6/7 and mipi is 5/6 mil width/spacing) they would be 10 ohms apart, ref below.
• [x] Switch USB-C Connector to surface mount only
  • Potential issue with through-hole stubs as noted here: Through-hole connector pins should not stick through the bottom of the board, since this also creates a transmission line stub.

Review Checklist

• [x] All USB Super Speed: routing skew down to about 6ps requires lengths matched to about 1mm
  • [x] Upstream USB-C
  • [x] Downstream FPGA 0
  • [x] Downstream FPGA 1
  • [x] Downstream USB-A 0
  • [x] Downstream USB-A 1
  • [x] The USB hub chip needs a voltage between 1.09V and 1.21V for its digital supply (with 1.15V being usually supplied). We should check the resistance values and tolerances for the 1.2V regulator and make sure we don't go above 1.21V in the worst case scenario.
• [ ] USB7216C Review
  • [ ] HW Checklist: https://ww1.microchip.com/downloads/en/DeviceDoc/USB7216-HW-Design-Checklist-00003286A.pdf

Missing Parts

• TPS2121 is not available and there does not appear to be an alternative.
• TPSM53604RDAR is very hard to source, we did the 2A version for rev A but it might not be enough, especially when plugging demanding USB3 devices. We should monitor the availability of the module and if it keeps not being available in either the 3A or the 4A version consider changing it.

[luca-della-vedova]

I am looking at some of the recent changes and some sparse feedback:

• I saw you that the QWIIC ports are on BO which is set at 1.8V, this was probably a change you forgot to revert (based on the commit history)? The QWIIC description page shows that it runs at 3.3V. It also seems to show that all QWIIC devices have a pullup resistor integrated, it probably doesn't hurt to have another one but just thought I would point that out (didn't know when we designed the first revision).
• I also find the commit history a bit confusing, it says "GPIO back to 1.8V, QWIIC back 3.3V" but from what I see it's the other way around, with GPIO being at 3.3V and QWIIC being at 1.8V.
• I wonder if we still need the 0201 capacitors. They were probably needed before because we were using the BGA package that made routing very challenging, do you think they are still necessary now that we are switching to a normal QFN?
• It would probably be a good time to fix the wrong notation that was present in the first OVC5 schematic, with the USB upstream port (the user facing USB C connector) being labelled as "DS" (downstream).
• I see that, unlike the previous hub, this chip has official guidelines for using an oscillator instead of a crystal as a clock input. I would recommend doing that instead since it would allow us to save quite a lot of space / number of parts (it typically is just a small oscillator and a capacitor, instead of a bulkier crystal, a resistor and two capacitors, with somehow guesstimated values for capacitors).
• Nit, I saw there are a lot of parts leftover from the previous design (i.e. a few RC delays for reset lines, CC resistors, CHIPEN pullup, I2C pullups), we can probably take them away.
• Nit, there is a comment saying DS1 always connected, I think this is not true anymore in this revision.

We should disable the last unused USB2 port with a pullup resistor:

It probably doesn't matter (seems to be only for certification purposes) but if we went for the solution where we connect port 1/2 to the FPGA and port 3/4 to the downstream ports, we could correctly configure the strap to set the non-removable property.

I think we can disable battery charging, but not sure on this one.

For all the PF pins it seems there are a lot of ports that need a weak pull down to GND. I'm not sure what we should choose between I2S and I2C CFG_STRAP, I guess we definitely won't need I2S, I think for maximum flexibility it could be interesting to set it to SMBUS mode and have DNP resistors to the I2C bus that will be connected to all other USB chips. They all work at the same voltage and it would allow the hub to work out of the box but still allow us to configure it in userspace if we wanted to, by populating the DNP resistors.

I saw that you connected both CC lines on the hub's downstream ports to ground through a 100k resistor. I'm not sure what the best way to go here would be. I see that the datasheet recommends having a weak pull-down to GND, however in this case it says that you should "reconfigure the hub to work for a legacy type A port" and that sounds like an additional step that could require proprietary tools (i.e. through a firmware update?). The alternative would be to emulate a CC pin similar to what we did for the previous revision and what they recommend doing in the hardware guide for "embedded devices" Of course there are ways to sidestep this altogether, which are either having an actual type C connection for one of the downstream devices or having the FPGA connect to the type-C port and follow their guideline for embedded devices. We will probably know more at layout / routing time if any of those is a good idea.

[gbalke]

I saw you that the QWIIC ports are on BO which is set at 1.8V, this was probably a change you forgot to revert (based on the commit history)? The QWIIC description page shows that it runs at 3.3V. It also seems to show that all QWIIC devices have a pullup resistor integrated, it probably doesn't hurt to have another one but just thought I would point that out (didn't know when we designed the first revision). I also find the commit history a bit confusing, it says "GPIO back to 1.8V, QWIIC back 3.3V" but from what I see it's the other way around, with GPIO being at 3.3V and QWIIC being at 1.8V.

I think I forgot to save my progress :disappointed: I definitely remember swapping them back.

I wonder if we still need the 0201 capacitors. They were probably needed before because we were using the BGA package that made routing very challenging, do you think they are still necessary now that we are switching to a normal QFN?

Likely don't need them anymore. Nevertheless, it will make routing easier. I will mention that I don't see much work occurring on decoupling caps in pretty much any scenario (I've never had to rework a decoupling cap). I've left all of the non-decoupling caps as 0402 which can we reworked (albeit tricky).

It would probably be a good time to fix the wrong notation that was present in the first OVC5 schematic, with the USB upstream port (the user facing USB C connector) being labelled as "DS" (downstream).

I agree! Will change.

We should disable the last unused USB2 port with a pullup resistor:

:heavy_check_mark:

It probably doesn't matter (seems to be only for certification purposes) but if we went for the solution where we connect port 1/2 to the FPGA and port 3/4 to the downstream ports, we could correctly configure the strap to set the non-removable property.

I didn't want to do that because Port1 is USB-C compatible (which we were thinking about using for an external connection). The only way to enable legacy mode is via the I2C configuration (no way to do it otherwise).

I think we can disable battery charging, but not sure on this one.

I actually found something that tells me we should disable it:

One thing I noticed is that The CFG_NON_REM/CFG_BC_EN are overlapping with the SPI stuff. I'm confused if these still get configured via passives when running in I2C mode.

[codebot]

If we don't strictly need the 0201 to deal with the BGA grid (since we don't have any BGA anymore), I'd suggest to stick with 0402 and larger. The 0201 are kind of a nightmare for the assemblers to deal with, so if we don't need them, I'd suggest to just go 0402. I guess the potential unknown is the AC-coupling (DC-blocking) caps on the SuperSpeed+ lanes, in case somehow (via black magic analysis) it's better for signal integrity to use 0201 instead of 0402 for whatever reason. I haven't read that directly anywhere. Has anyone else?

[gbalke]

If we don't strictly need the 0201 to deal with the BGA grid (since we don't have any BGA anymore), I'd suggest to stick with 0402 and larger. The 0201 are kind of a nightmare for the assemblers to deal with, so if we don't need them, I'd suggest to just go 0402. I guess the potential unknown is the AC-coupling (DC-blocking) caps on the SuperSpeed+ lanes, in case somehow (via black magic analysis) it's better for signal integrity to use 0201 instead of 0402 for whatever reason. I haven't read that directly anywhere. Has anyone else?

If this reply is correct, smaller is better me thinks :smile: (voodoo inductance magikz) https://electronics.stackexchange.com/questions/173691/ac-coupling-capacitors-for-high-speed-differential-interfaces

[codebot]

Thanks Greg for digging into this. There is so much magic here.

This TI doc agrees that 0201 are better for AC-coupling (see page 22): https://www.ti.com/lit/an/slla414/slla414.pdf

Also some interesting stuff about increasing the via anti-pad diameter on page 20.

It seems that PCIe 3.0 (similar speed to USB SuperSpeed+) requires 220 nF caps, not 100 nF like the older/slower ones. I'm trying to chase down an authoritative source for USB SuperSpeed+ to see if its blazing 10 gbps speed also wants 220 nF coupling.

[codebot]

The USB7216 hardware design checklist page 3 says to use 0.1uF AC-coupling caps, so let's just do exactly that :smile: but I agree that 0201 is apparently "better" for mysterious reasons we can't possibly truly understand.

[gbalke]

Alright. I'm going to propose we solve our chicken and egg problem with https://www.digikey.com/en/products/detail/texas-instruments/TS5USBC410YFFT/9554630

We can divert the USB2 input to USB_UART_D+/USB_UART_D- when in debug mode. This will let us use our current solution without issue. I'm looking to answer if USB3 can be established without the presence of USB2... which would let us keep the debug console up while configuring the hub. The other alternative is trust in the ethernet connection (which works just fine right now) and switch the USB2 back to the hub as soon as we get the system booted up and SSH in. This way we don't have to add any additional hardware and can still play with gains on the TUSB1042I. This switch will start on hub mode because it will only be necessary for development/hub/zynq boot debug purposes.

Side note: I feel like this might be the right way because I think this is the exact application described for this device haha

[gbalke]

I implemented the solution that may have stub issues. I'll add a second mux if significant concern arises during review. Beginning layout/placement of all of these new chips/components.

[gbalke]

Thought I should make this very visible: I removed the S25FL064 which was previously providing SPI connected flash for the Cypress Hub. I don't see us using it for the USB7216C :boom::boom::boom::boom::boom:

[gbalke]

Routing plan! Might shift some stuff around but these are the orientations.

NOTE: I think the cypress hub automagically figured out pair swapping. Looks like we'll need to program this one.

PortSwap, which adds per-port programmability to USB differential-pair pin locations. PortSwap allows direct alignment of USB signals (D+/D-) to connectors to avoid uneven trace length or crossing of the USB differential signals on the PCB.

[luca-della-vedova]

NOTE: I think the cypress hub automagically figured out pair swapping. Looks like we'll need to program this one.

PortSwap, which adds per-port programmability to USB differential-pair pin locations. PortSwap allows direct alignment of USB signals (D+/D-) to connectors to avoid uneven trace length or crossing of the USB differential signals on the PCB.

I think they are referring to different signals, the USB3 lane swap is guaranteed by the standard so it's always available, the USB2 lane swap is not and can be programmed in the microchip hub (but not the cypress, as far as I understand).

Anyway other round of review on USB stuff!

Schematics

The high level comment on the multiplexer choice is whether, especially after routing it, you think the introduced complexity is OK compared to the simpler but less convenient solution (bring uart TX / RX to a 2.54mm header and require the use of a USB FTDI dongle for debugging when the USB hub is not working).

I was looking at the footprint for the USB2 multiplexer and it seems a bit off compared to the recommended one (that I believe is this one?), specifically:

• Pad shape, oval in our footprint but seems rectangular in their document (probably doesn't matter that much).
• Pad size is 0.85 in their document, 0.6 in our footprint.
• Pad spacing is 1.9 in their document, 1.6 in our footprint.

I saw you swapped the USB2 lanes on port 6, is this avoidable? We can fix it in firmware by swapping them during the hub configuration stage but it would be great if we can just have it right instead.

I saw you connected the USBEN signals to PF15 and PF17, that map to the control pins for port 1 and 2: However, it seems the ports we are using are actually 1 and 4 (after flexconnect), since 2 and 3 are the embedded ones for the FPGA and have no enable / power switch. It also seems they have an architecture where they use the same pin to enable the switch and monitor overcurrent events through an internal pullup, should probably double check the TSP2561 signals to account for that (right now the overcurrent flag nOVC is unrouted).

We should probably connect the SMBUS signals to a relevant GPIO in the FPGA, just to make sure we don't forget down the line. If I read the datasheet correctly both 3.3V and 1.8V banks should be fine (but I only tested 3.3V so that would be my personal preference). Similar comment for the USB_DEBUG_SWITCH line, just to make sure we don't forget and end up with an unusable mux.

BOM

I saw you selected a very large oscillator (5mm x 3.2mm), a quick search on digikey returned a lot of smaller oscillators available, was there any reason behind the specific model? Random example this from Abracon.

I also noticed that all the 100 nF capacitors in the schematic have been switched from 0402 to 0201, here I'm honestly not sure if it's better to reduce the number of parts in the BOM (and have everything 0201) or have them only where necessary (and keep 0402 wherever the size is not critical).

Placement

Can the placement of the FTDI chip be optimized a bit to shorten the USB traces? It is probably OK if the TX/RX signals to the FPGA have longer traces since they are 115Kbps signals, we should probably care more about the USB signals that are three orders of magnitude faster.

Routing

Not USB related but I am a bit concerned with all the unrouted control signals / I2C lanes from all the MIPI connectors to the other side of the PCB, I hope there is space in the end :sweat_smile:

Via in pads can be a bit tricky to fabricate so we should also try to avoid them, there are a few in the USB-C SMT connector (and it seems that at least one of them, top right, actually does nothing?)

The usual guideline for USB through hole connectors is to enter through the opposite PCB side (i.e. bottom layer), should try to do it for the H0 RX signal ]

We should also try to be as far from the mounting holes / through holes as possible, especially for sensitive signals, for example USB_H1_RX is very close to the through hole of the host connector, VBUS is at minimum distance from two holes.

USB TX capacitors should have pour cutouts below, i.e.:

[to be continued]

[gbalke]

Schematics

The high level comment on the multiplexer choice is whether, especially after routing it, you think the introduced complexity is OK compared to the simpler but less convenient solution (bring uart TX / RX to a 2.54mm header and require the use of a USB FTDI dongle for debugging when the USB hub is not working).

I was hoping to minimize external hardware but I'm starting to feel like this got a bit extra. I think I'll pull it all out and add a dual header to interface with the UART. It's also raising a lot of extra concerns that aren't really worth the effort.

I was looking at the footprint for the USB2 multiplexer and it seems a bit off compared to the recommended one (that I believe is this one?), specifically:

• Pad shape, oval in our footprint but seems rectangular in their document (probably doesn't matter that much).
• Pad size is 0.85 in their document, 0.6 in our footprint.
• Pad spacing is 1.9 in their document, 1.6 in our footprint.

I was doing it off the package directly (didn't realize there was a recommended footprint). I'm making the adjustments to match the recommende. Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX4906EF.pdf https://pdfserv.maximintegrated.com/package_dwgs/21-0164.PDF

I saw you swapped the USB2 lanes on port 6, is this avoidable? We can fix it in firmware by swapping them during the hub configuration stage but it would be great if we can just have it right instead.

Swapped back. It leads to some un-ideal routing but that's okay.

I saw you connected the USBEN signals to PF15 and PF17, that map to the control pins for port 1 and 2: However, it seems the ports we are using are actually 1 and 4 (after flexconnect), since 2 and 3 are the embedded ones for the FPGA and have no enable / power switch. It also seems they have an architecture where they use the same pin to enable the switch and monitor overcurrent events through an internal pullup, should probably double check the TSP2561 signals to account for that (right now the overcurrent flag nOVC is unrouted).

Yup, forgot to swap after the change. I'll double check the overcurrent signaling. It sounds like the upstream connection take over all properties of Downstream 1 after the swap?

We should probably connect the SMBUS signals to a relevant GPIO in the FPGA, just to make sure we don't forget down the line. If I read the datasheet correctly both 3.3V and 1.8V banks should be fine (but I only tested 3.3V so that would be my personal preference).

Routed to 3.3V.

Similar comment for the USB_DEBUG_SWITCH line, just to make sure we don't forget and end up with an unusable mux.

BOM

I saw you selected a very large oscillator (5mm x 3.2mm), a quick search on digikey returned a lot of smaller oscillators available, was there any reason behind the specific model? Random example this from Abracon.

This was a mistake. I noticed it was large only once I started routing and didn't get around to swapping it out for a smaller one. I kind of just hand waved it away as long as it didn't cause routing issues. I'll switch to a smaller once.

I also noticed that all the 100 nF capacitors in the schematic have been switched from 0402 to 0201, here I'm honestly not sure if it's better to reduce the number of parts in the BOM (and have everything 0201) or have them only where necessary (and keep 0402 wherever the size is not critical).

I left all components that might need adjusting as 0402 or larger. I didn't see a reason to have decoupling caps be anything bigger than 0201 or whatever their smallest size is. I recall the argument being that it made manufacturing more difficult. We already have about 14 necessary 0201 caps for the signal lines, in total there are 51. Idk whether or not we should expect that to work out.

Placement

Can the placement of the FTDI chip be optimized a bit to shorten the USB traces? It is probably OK if the TX/RX signals to the FPGA have longer traces since they are 115Kbps signals, we should probably care more about the USB signals that are three orders of magnitude faster.

Routing

Not USB related but I am a bit concerned with all the unrouted control signals / I2C lanes from all the MIPI connectors to the other side of the PCB, I hope there is space in the end

Similar concern here. I am still trying to figure out how best to route these.

Via in pads can be a bit tricky to fabricate so we should also try to avoid them, there are a few in the USB-C SMT connector (and it seems that at least one of them, top right, actually does nothing?)

Fixed.

The usual guideline for USB through hole connectors is to enter through the opposite PCB side (i.e. bottom layer), should try to do it for the H0 RX signal ]

Fixed.

We should also try to be as far from the mounting holes / through holes as possible, especially for sensitive signals, for example USB_H1_RX is very close to the through hole of the host connector, VBUS is at minimum distance from two holes.

Adjusted USB_H1_RX but uncertain what you mean by VBUS? I haven't moved these at all since the previous revision.

USB TX capacitors should have pour cutouts below, i.e.:

Fixed!

[luca-della-vedova]

Yup, forgot to swap after the change. I'll double check the overcurrent signaling. It sounds like the upstream connection take over all properties of Downstream 1 after the swap?

That is a good question and I'm honestly not 100% sure yet

I left all components that might need adjusting as 0402 or larger. I didn't see a reason to have decoupling caps be anything bigger than 0201 or whatever their smallest size is. I recall the argument being that it made manufacturing more difficult. We already have about 14 necessary 0201 caps for the signal lines, in total there are 51. Idk whether or not we should expect that to work out.

Yea I'm fine either way to be honest, just thought I'd bring that up. Adjusted USB_H1_RX but uncertain what you mean by VBUS? I haven't moved these at all since the previous revision.

I meant the VBUS on the USB-C connector, which is very close to two mounting holes.

A few more mixed schematics related review (since routing is not finished yet I'll skip minor things like skew / length tuning, clearances etc).

I saw that you are connecting the FPGA clock and data to a 1.8V -> 3.3V level shifter:

From what I can see in the Enclustra module schematic we have a few available 3.3V GPIOs that also happen to be a lot closer to the fan connector (i.e. A15 / A17), maybe we can use those and get rid of the level shifter?

I admittedly didn't look much into the fan controller but I see it uses SMBUS on the clock / data lines. SMBUS is very closely related to I2C and I think it will need the same type of pullups on the data / clock lines otherwise the interface won't work.

Minor thing but I noticed you routed the TX/RX to a separate pin header on the top, if the space over there is needed for routing I think we can ditch two GPIOs on the bottom header and just route it there, but if space is not a concern it's probably OK. Also on a related note I think it might need a reference ground as well for the FTDI probes, otherwise when connecting an adapter we might need to connect the ground all the way to the other end of the PCB where the GPIO header is.

Also with the change that the fan now requires 12V I wonder whether we should still keep the whole "power from USB-C through the multiplexer" idea or not. The TPS2121 power multiplexer keeps being impossible to source, and I am honestly not sure if it was to be available and the OVC was plugged just with a USB-C cable, if it would be able to be fully functional (i.e. run the FPGA, a few imagers, as well as a few devices off the USB host ports). I don't have a real recommendation here, I'm conflicted between removing the TPS2121 altogether, adding a net tie (so we don't need manual soldering if the chip is not available), or leave it the current way in case it becomes available again, what do you think? Also do you know how much current the "average" motherboard can supply through a USB-C connector?

Super minor but we can move CAM0 and CAM3 trigger to the unused A85 / A87 pin and reduce the length of all the routes a bit.

[luca-della-vedova]

Also I managed to get the flexconnect to finally work with the hub chip. In order to work both the ports to be flexed must have their VBUS high. I can 1000% see how changing the default US port from being connected to a host port to being connected to the FPGA and with a hard-wired high VBUS would be challenging though. From my understanding I think it should be OK and the way the USBEN lines work the VBUS should be high unless the VBUS switch detects an overcurrent event and pulls it low (by connecting nOVC to the power switch enable line), but another pair of eyes on the specs would be great!

In my experiments with flexconnect I actually connected the old upstream port to a power bank and it seems to work, so the only requirement seems to be that VBUS is powered.

[gbalke]

Adjusted USB_H1_RX but uncertain what you mean by VBUS? I haven't moved these at all since the previous revision.

I meant the VBUS on the USB-C connector, which is very close to two mounting holes.

Got it. Fixed.

I saw that you are connecting the FPGA clock and data to a 1.8V -> 3.3V level shifter:

From what I can see in the Enclustra module schematic we have a few available 3.3V GPIOs that also happen to be a lot closer to the fan connector (i.e. A15 / A17), maybe we can use those and get rid of the level shifter?

Oopsies. I think I already moved it to a 3V3 gpio and forgot to remove the level shifter. It's been removed!

I admittedly didn't look much into the fan controller but I see it uses SMBUS on the clock / data lines. SMBUS is very closely related to I2C and I think it will need the same type of pullups on the data / clock lines otherwise the interface won't work.

Fixed.

Minor thing but I noticed you routed the TX/RX to a separate pin header on the top, if the space over there is needed for routing I think we can ditch two GPIOs on the bottom header and just route it there, but if space is not a concern it's probably OK. Also on a related note I think it might need a reference ground as well for the FTDI probes, otherwise when connecting an adapter we might need to connect the ground all the way to the other end of the PCB where the GPIO header is.

I'll add a third pin. I think it should fit at the top of the board so we can maintain one GPIO/camera.

Also with the change that the fan now requires 12V I wonder whether we should still keep the whole "power from USB-C through the multiplexer" idea or not. The TPS2121 power multiplexer keeps being impossible to source, and I am honestly not sure if it was to be available and the OVC was plugged just with a USB-C cable, if it would be able to be fully functional (i.e. run the FPGA, a few imagers, as well as a few devices off the USB host ports). I don't have a real recommendation here, I'm conflicted between removing the TPS2121 altogether, adding a net tie (so we don't need manual soldering if the chip is not available), or leave it the current way in case it becomes available again, what do you think? Also do you know how much current the "average" motherboard can supply through a USB-C connector?

At most I'd guess what's mentioned as CDP in this article: https://www.cmd-ltd.com/advice-centre/usb-chargers-and-power-modules/usb-and-power-module-product-help/usb-charger-faqs/

Given that that only provides 5V 1.5A, I don't know how it will perform. The power supplies we've been using are 12V 1.5-3A which supplies a ton of power. The TPSM53604RDA supplies up to 4A which is 20W at 5V. I can benchmark the supply draw if we want to know for sure if we can supply off of 7.5 Watts. I'd still guess we want margin for error to avoid brownouts so I'll say we want to derate 20%? Should only draw 6W constant current.

Super minor but we can move CAM0 and CAM3 trigger to the unused A85 / A87 pin and reduce the length of all the routes a bit.

Don't think this matters much. It would make sense to swap the GPIO/Trigger pins though. Would be able to shorten all of them quite a bit.

[gbalke]

Finished routing and skew corrections. Last things to check:

• [ ] Should there be ground stitches on all on-board super-speed traces?
• [ ] Should spacing be increased on diff pair signals (following this guide):
• [ ] How should VBUS/USBEN connect to allow the chip to work before configuring flexconnect?
• [ ] Should the TPS2121 footprint be removed or simply bridge VREG to +5V?

[luca-della-vedova]

I think there are a few quite large parts from the first few posts that still need to be addressed:

First of all the thickness of the differential pairs for impedance control, I saw that the USB pairs are 6/7 mil width spacing, which addresses the first part of the impedance matching comment but the MIPI lanes are still 7/8 mil. This would make the impedance control of this board actually worse than the previous one since it seems that higher width brings lower impedance so we would go from having everything at 90 Ohm even though USB needs 90 and MIPI needs 100 (rev A) to having USB at 90 and MIPI around 80 (rev B), so that is about 20% mismatch, up from 10% in rev A, which starts to be quite a bit. I think it might be a bit disruptive but hopefully making the MIPI traces smaller will also help in crowding and helping with the 5x width rule for inter-pair spacing that you highlighted.

The nOVC / enable lines for the USB power switch, it seems they can be shorted together and all pullup resistors removed since the pin has internal pullups and just monitors for the switch pulling it low:

If space allows it might be worth itwas working on the floor/wall textures, exporting now to add stitching vias to the USB lanes going to the host connector since those are also Gen2 capable, also it seems that there is some available space on top and they could be spaced further from each other more (i.e. the left-most could "turn earlier", the right-most could "turn later" to use more space).

I would generally try to be careful when placing vias inside the FPGA module connector. In the connector's page they recommend 1.1mm of keepout under the connector, again I didn't add it since it would have prevented us from routing the same trace (which I think it should be OK). This keepout is being violated with several nets, mostly on the bottom connector, i.e.:

I also noticed that the CONN1 / CONN2 dummy symbols used for BOM reasons are gone from the schematic, is this intended?

We can also clean up the grounds in the top connector a bit and put one via per pin:

I'm not sure what the guidelines are for skew matching traces but I generally try to keep them not too long / tall to avoid the impedance mismatch due to the spacing between the traces changing (hope this makes sense!) For example I'd avoid the red type and do the blue instead (those are the FPGA lanes), but again I'm not too sure what the :

I'd try to avoid using skew tuning serpentines when we can avoid it in MIPI traces (we can tune the length at the connector level), i.e. top and bottom in the following pic (for the top just make the other trace's loop shorter to match the length, for the bottom you can also shorten the other trace): For the following you can also make the trace do a small loop at the connector level and remove the serpentine:

We can probably move all the larger ICs (fan driver and FTDI chip to the top layer), from what I can see the FTDI chip USB trace would become longer (probably OK, the FPGA USB2 traces are a lot longer and seem to work fine in Rev A), also it would reduce disruption on the bottom layer for the fan driver since we are using it as a 5V plane (i.e. it could be placed next to C78). If we reduce the cuts on the bottom plane I think we can also move the 12V lane from an inner layer to the bottom plane since the plane only feeds the bottom GPIO 5V pin now and that's probably not very high current.

I see that the 5V plane has a "finger" that is not needed anymore (I suspect it was needed in rev A for the FTDI chip power supply), it can probably be shrinked:

[Again to be continued, don't have time do any more reviewing today <.<]

[gbalke]

First of all the thickness of the differential pairs for impedance control, I saw that the USB pairs are 6/7 mil width spacing, which addresses the first part of the impedance matching comment but the MIPI lanes are still 7/8 mil. This would make the impedance control of this board actually worse than the previous one since it seems that higher width brings lower impedance so we would go from having everything at 90 Ohm even though USB needs 90 and MIPI needs 100 (rev A) to having USB at 90 and MIPI around 80 (rev B), so that is about 20% mismatch, up from 10% in rev A, which starts to be quite a bit. I think it might be a bit disruptive but hopefully making the MIPI traces smaller will also help in crowding and helping with the 5x width rule for inter-pair spacing that you highlighted.

Ack. My bad. I'll fix this in a dedicated commit. Also if the MIPI width/spacing hasn't changed and I fixed USB, it should only be better? I am confused by this maths.

The nOVC / enable lines for the USB power switch, it seems they can be shorted together and all pullup resistors removed since the pin has internal pullups and just monitors for the switch pulling it low:

Agreed. Fixed.

If space allows it might be worth itwas working on the floor/wall textures, exporting now to add stitching vias to the USB lanes going to the host connector since those are also Gen2 capable, also it seems that there is some available space on top and they could be spaced further from each other more (i.e. the left-most could "turn earlier", the right-most could "turn later" to use more space).

Sounds like a good plan! Not sure how to handle stitches under the shield? Should I remove them?

I would generally try to be careful when placing vias inside the FPGA module connector. In the connector's page they recommend 1.1mm of keepout under the connector, again I didn't add it since it would have prevented us from routing the same trace (which I think it should be OK). This keepout is being violated with several nets, mostly on the bottom connector, i.e.:

Tried my best to adjust what I could:

I also noticed that the CONN1 / CONN2 dummy symbols used for BOM reasons are gone from the schematic, is this intended?

No idea why those disappeared... Might've been an accidental delete. Added them back.

We can also clean up the grounds in the top connector a bit and put one via per pin:

Done.

I'm not sure what the guidelines are for skew matching traces but I generally try to keep them not too long / tall to avoid the impedance mismatch due to the spacing between the traces changing (hope this makes sense!) For example I'd avoid the red type and do the blue instead (those are the FPGA lanes), but again I'm not too sure what the :

Fixed.

I'd try to avoid using skew tuning serpentines when we can avoid it in MIPI traces (we can tune the length at the connector level), i.e. top and bottom in the following pic (for the top just make the other trace's loop shorter to match the length, for the bottom you can also shorten the other trace): For the following you can also make the trace do a small loop at the connector level and remove the serpentine:

Got it, will make sure not to introduce these when re-routing all the MIPI lanes for 5/6.

We can probably move all the larger ICs (fan driver and FTDI chip to the top layer), from what I can see the FTDI chip USB trace would become longer (probably OK, the FPGA USB2 traces are a lot longer and seem to work fine in Rev A), also it would reduce disruption on the bottom layer for the fan driver since we are using it as a 5V plane (i.e. it could be placed next to C78). If we reduce the cuts on the bottom plane I think we can also move the 12V lane from an inner layer to the bottom plane since the plane only feeds the bottom GPIO 5V pin now and that's probably not very high current.

Fixed.

I see that the 5V plane has a "finger" that is not needed anymore (I suspect it was needed in rev A for the FTDI chip power supply), it can probably be shrinked:

Removed.

[luca-della-vedova]

There are quite a lot of DRC violations, most of them are due to the new clearance rule being set to 5 mil but some of them are due to lines not being fully routed (CAM0 I2C), unnecessary vias (5V via for the FTDI chip) and GND pads not being connected (at least for the FPGA module, we can ignore the error for the TPSM chip). Also it seems that adding stitching vias to the USB host port disrupted the solid plane under the shield, I'm not sure how to go there, maybe remove the vias under the shield or make them more sparse so there is still a reasonably solid copper region?

I also remember we discussed adding a large 0R resistor under the TPS2121 chip that we can populate at fabrication time to bypass the chip and avoid having to manually bridge the pads if the chip is unavailable.

Nit: It seems the 1V2 plane on layer 3 (to supply the USB chip) could be shrinked a bit on the west side of the PCB, this would allow more space for the 5V plane that might have to bring a few amps of current. For now because of its geometry all the current goes throw a very narrow (0.5mm) bottleneck close to the connector. Maybe the stitching vias can also be made a bit more sparse to allow the plane inbetween?

I'd try to add a ground via closer to these bypass capacitors, right now the ground return current path is quite long (to the top left of the screenshot):

Super nit, maybe follow the same placement convention for these bypass capacitors? (GND being on the inside of the chip, closest to the vias):

I'm not sure whether we should be more cautious with the USB hub power supply, as the checklist item:

The USB hub chip needs a voltage between 1.09V and 1.21V for its digital supply (with 1.15V being usually supplied). We should check the resistance values and tolerances for the 1.2V regulator and make sure we don't go above 1.21V in the worst case scenario.

The nominal voltage now seems to be 1.2V and bad luck on tolerances could put us above 1.2V. I had a look at other components and it seems that if we went for the next available value for the second feedback resistor (357k) we would have a nominal voltage of about 1.185V, hopefully good enough to be safe and not too low to mess up the MIPI FPGA banks. Otherwise we could try precision resistors (0.1%) but there is still tolerance on the regulator's voltage reference that might bring us above 1.21V.

I was looking at the diode for the fan controller, I think the symbol should be SGD based on the datasheet. Also the part seems to be out of stock in Digikey, can we find a compatible replacement? There should be plenty.

With DRC and these issues fixed IMHO we can generate gerbers go for fab!

[gbalke]

There are quite a lot of DRC violations, most of them are due to the new clearance rule being set to 5 mil but some of them are due to lines not being fully routed (CAM0 I2C), unnecessary vias (5V via for the FTDI chip) and GND pads not being connected (at least for the FPGA module, we can ignore the error for the TPSM chip).

YIKES. I forgot to clear these up. Good catch. Sorry for saying it was ready without resolving these :cry:. I managed to get everything routed with the 5mil rules!!!

Also it seems that adding stitching vias to the USB host port disrupted the solid plane under the shield, I'm not sure how to go there, maybe remove the vias under the shield or make them more sparse so there is still a reasonably solid copper region?

I was curious about this myself. I double checked around for how dense/sparse stitching should be and it seems like the cypress suggestions is not necessarily the de-facto. Most of what I see suggests only to use stitching vias on either side of a via. I doubt Cypress is crazy so I am still going to leave in some of these stitching vias as a Faraday cage can't hurt but I'll definitely reduce the number of vias dramatically which should help with the pours.

I also remember we discussed adding a large 0R resistor under the TPS2121 chip that we can populate at fabrication time to bypass the chip and avoid having to manually bridge the pads if the chip is unavailable.

Yes. Completely forgot :sob:. Added.

Nit: It seems the 1V2 plane on layer 3 (to supply the USB chip) could be shrinked a bit on the west side of the PCB, this would allow more space for the 5V plane that might have to bring a few amps of current. For now because of its geometry all the current goes throw a very narrow (0.5mm) bottleneck close to the connector. Maybe the stitching vias can also be made a bit more sparse to allow the plane inbetween?

Fixed by making the vias more sparse and adjusting 1V2/5V plane.

I'd try to add a ground via closer to these bypass capacitors, right now the ground return current path is quite long (to the top left of the screenshot):

Added a few.

Super nit, maybe follow the same placement convention for these bypass capacitors? (GND being on the inside of the chip, closest to the vias):

Fixed.

I'm not sure whether we should be more cautious with the USB hub power supply, as the checklist item:

The USB hub chip needs a voltage between 1.09V and 1.21V for its digital supply (with 1.15V being usually supplied). We should check the resistance values and tolerances for the 1.2V regulator and make sure we don't go above 1.21V in the worst case scenario.

The nominal voltage now seems to be 1.2V and bad luck on tolerances could put us above 1.2V. I had a look at other components and it seems that if we went for the next available value for the second feedback resistor (357k) we would have a nominal voltage of about 1.185V, hopefully good enough to be safe and not too low to mess up the MIPI FPGA banks. Otherwise we could try precision resistors (0.1%) but there is still tolerance on the regulator's voltage reference that might bring us above 1.21V.

According to table 5/6 of this guide, the MIPI D-PHY spec suggests 1.14 -1.26 as the bounds of operation. Given this, I think we're okay to use 1.85V for the bank. As for the second resistor calculatiopnMath checks out:

>>> Vout=1.185
>>> Ra=348000
>>> Rb=(Ra*0.6)/(Vout-0.6)
>>> Rb
356923.0769230769

I was looking at the diode for the fan controller, I think the symbol should be SGD based on the datasheet. Also the part seems to be out of stock in Digikey, can we find a compatible replacement? There should be plenty.

From context, I believe you meant the FET. I'm replacing it with: https://www.digikey.com/en/products/detail/toshiba-semiconductor-and-storage/SSM3K2615R-LF/5403445 which is in stock! I also noticed that the previous part selected didn't support 3.3V operation which is what the fan controller outputs.

With DRC and these issues fixed IMHO we can generate gerbers go for fab!

Yay! I've addressed all of these issues. All that's left is to add the top-side reset buttons and replace the FTDI chip.

[luca-della-vedova]

Alright I did another round and thought I'd do the changes to avoid going too much into minor nitpicks.

Summary of the changes:

• Check the skew of all MIPI / USB differential pairs. The USB and MIPI pairs needed a fair bit of tuning. Didn't bother too much into Ethernet / USB2 since they are a lot more tolerant. I also changed ethernet diff pairs from 7/8 to 5/6 since it's also nominally 100 Ohm, the same as MIPI (it would have been about 80+ Ohm otherwise I believe).
• Minor cleanups to the camera GPIOs, including changing a few pin assignments to simplify routing, for example switch SCL / SDA, move the fan / user DIP gpios a bit and the software button.
• General GPIO routing cleanup / increase spacing among lines.
• Assign the hardware reset button to the 12V -> 5V regulator so that the whole board is shut down (instead of only the 3.3V regulator).
• Changed the 0201 capacitor from a Samsung part to a Walsin part. We use it for up to 5V and because of derating using a 6.3V capacitor is not great (i.e found the picture below on the Murata website):
• Tried to reduce the length of traces in the bottom layer overlapping the 5V plane, to make sure we get a good power distribution to the FPGA module (it might carry 1-2A).
• Updated and tuned all the lengths for MIPI traces, some of them were off by 7-8mm.

Feel free to give it another round of tunings / check then, when you are satisfied, generate the fabrication archives and we can [squash] merge and send this for fabrication.

[gbalke]

Assign the hardware reset button to the 12V -> 5V regulator so that the whole board is shut down (instead of only the 3.3V regulator).

I didn't do this because if we populate the TPS2121, there will still be a path to supply 5V through the USB connection. This will only reset the system fully while the board is incomplete or USB is disconnected.

[luca-della-vedova]

Assign the hardware reset button to the 12V -> 5V regulator so that the whole board is shut down (instead of only the 3.3V regulator).

I didn't do this because if we populate the TPS2121, there will still be a path to supply 5V through the USB connection. This will only reset the system fully while the board is incomplete or USB is disconnected.

To be honest the more time goes on the more I am getting worried that it's not really sustainable to power over USB because of the high current requirements, I guess for now since TPS2121 will most likely be out of stock for the next year we are good but it's true that we should think about it. I think a way to deal with it could be to have an open drain buffer chip that monitors the power button and, when pushed, it drives low both the TPS2121 OV2 port (that will mark VBUS as invalid) and the voltage regulator (to stop regulating 12V -> 5V).

[gbalke]

Forgot to post this along with my small push:

Only made 2 small changes:

• Fixed skew on ethernet
• Fixed DRC with U7 Silkscreen (used to be under R11)

There were some minor inconsistencies with trace length when I scanned the spreadsheet but it nothing big enough to cause any issues.

Not sure what's going on with the USB2 line up top but it's not super speed so :shrug: