Sentinal 65X - Prototype 4 Review
Opened this issue · 2 comments
USB Power & Data (U7 / U8)
U8 appears to be improperly configured, with both 3V3OUT and U7 driving the +3.3V rail simultaneously. I suspect you were trying to set up the self-powered configuration in the FT230XS datasheet and accidentally connected 3V3OUT to the +3.3V rail instead of its own net. Based on the datasheet you probably want to connect 3V3OUT, VCCIO, and RESET together and then to a 100nF cap to ground. I suspect this is what C23 was initially supposed to be for. I missed the detail about connecting 3V3OUT to VCC when it's 3.3V - ignore the above.
C23's +3.3V pad appears to be disconnected in the PCB design.
Decoupling on U8 is missing - should be 2x 100nF and 1x 4.7uF, all MLCCs as per Figure 6.2 of the datasheet.
The 27R series termination resistors on USB D+/D- lines are missing. See FT230X datasheet.
The FT230XS has a small amount of ESD protection so you can probably get away without any discrete ESD protection IC, but a TVS clamp on +5V (VBUS) wouldn't hurt.
The regulator layout is kinda loose and you've got pretty long loops with decoupling caps quite far from the things they're decoupling. There was also quite a bit of sketchy routing going on around there with non-ground stuff on the ground layer and unnecessary layer changes. I took the liberty of doing a bit of a tidy-up here since it was easier than trying to go through the details. Before and after:
Essentially I moved the caps closer to the things being decoupled, shifted the +5V trace from VBUS up and the 3.3V regulator right so the power traces are kept away from the USB D+/D- traces (and so the pins have a straight shot to the regulator input caps), did a similar thing with the output caps, then shortened the D+/D- traces significantly and eliminated the layer change on those signals, got rid of the 3V3 trace on the ground layer, and moved the D+/D- crossover trace under the connector to use F and In2 so the ground plane doesn't get broken and both stay referenced to the ground plane on In1. I've left the D-/D+ signals disconnected since you need to add the 27R termination resistors. Also note that I've left C23 in place as if it's a decoupling cap but you'll want to rework that when you fix the 3V3OUT stuff and add the three decoupling caps to U8.
I've attached the tweaked KiCad files :)
Sentinal 65X - Prototype 4 - Tweaked.zip
Data lines
Wherever possible, each via that moves a signal from F or In1 to In3 or B should be accompanied by a ground stitching via placed as close as possible to that via, since the reference plane is changing from In1 to In4. This allows return currents to flow between the two ground planes, and provides a reference plane in the z-axis.
For example, all of these vias go from In2 to In3, which means the ground reference plane swaps from In1 to In4:
And here's how I'd add the reference vias: (sharing a ref via is fine)
Processor
+3.3V pins on the east and south could be routed directly to the decoupling caps. East has a direct route without changing anything. South can be routed directly by shifting the RES trace down slightly.
I'd also consider swapping those 100nF caps for CL05A106MQ5NUNC (10uF 6.3V 0402). They're on JLCPCB Basic Parts, under half a cent each. After derating to 3.3V DC bias it's about 3.5uF. At 8MHz the caps have about 18mΩ of impedance, which is nice and low, mostly due to the smaller package size having lower inductance.
Main RAM
C14 decoupling cap should be moved closer to the +3.3V pin. Again maybe upgrade to CL05A106MQ5NUNC.
System ROM
Maybe upgrade C12 to CL05A106MQ5NUNC.
SD Card Slot
If you're swapping other caps to CL05A106MQ5NUNC, you can save a BOM line by swapping C8 as well.
Clock Generation
Again, probably CL05A106MQ5NUNC on the decoupling. Ideally move the caps so they sit across the +3.3V and GND pins on the ICs, rather than putting vias under the IC pads and under the cap pads.
For example, from this:
We can do this:
VERA Graphics System
Missing decoupling on 5V output.
Cartridge Port
Missing decoupling on 3.3V or 5.0V lines.
Expansion Port
Missing decoupling on 3.3V or 5.0V lines.
Clock Port
Missing decoupling on 3.3V line.
Video DAC & Outputs
Missing decoupling on 3.3V line.
Unnecessary layer change on HSYNC line, could be routed all on In2.
Audio DAC & Output
Missing decoupling caps. Probably some on the module, but I'd stick a 10uF MLCC on the 5V line anyway.
Are A3V3 and AGND disconnected on purpose? The PCM5102 IC datasheet shows them connected to +3.3V and ground, but maybe there's something specific about the GY-PCM5102 module board I don't know?
Controller Ports
Missing decoupling caps.
Glue Logic
Atmel appnote 0484C–09/99 recommends 220nF capacitance with 4nH parasitic inductance at most, so a pair of 100nF 0805s are probably not gonna cut it. I'd recommend replacing C14/C15 for a single CL05B224KO5NNNC 220nF 16V 0402 capacitor.
USB Power & Data (U7 / U8)
U8 appears to be improperly configured, with both 3V3OUT and U7 driving the +3.3V rail simultaneously. I suspect you were trying to set up the self-powered configuration in the FT230XS datasheet and accidentally connected 3V3OUT to the +3.3V rail instead of its own net. Based on the datasheet you probably want to connect 3V3OUT, VCCIO, and RESET together and then to a 100nF cap to ground. I suspect this is what C23 was initially supposed to be for.I missed the detail about connecting 3V3OUT to VCC when it's 3.3V - ignore the above.
I'm still not liking the smell of this section. I've seen problems with a UART's 3V3 LDO line hooked to the host board's 3V3 rail, where a sudden current use spike reliably caused the UART to crash. In this case it may not be a problem due to VCC being 3.3V (the board I had an issue with had VCC connected to USB-VBUS in parallel with a 3.3V LDO), but if anything it would be more correct to use USB-VBUS directly to power the UART because there's no other power supply for the UART (yet?)
You may want to go back to the LM1085 from V4 as the voltage regulator between USB-VBUS and 3V3, because it has a higher current rating than a '1117 and it saves you a BOM line. Alternatively, you could do something like add a buck regulator to v4's power input to bring that down to about 5V (and avoid a lot of heat from the 5V LDO), and power diodes between USB-VBUS and the buck-regulated 5V rail.
Additional thoughts:
3V3OUT
Good idea to use a jumper footprint to choose between the tie-together approach from the self-powered example in the datasheet, and the tie-3V3OUT-to-3V3 approach mentioned further up in the specs. That way you can start out with it not connected to 3V3, then bridge the jumper to connect it if you run into issues.
Voltage Regulators
The 10uF input cap is at the absolute limit of the USB spec for bus capacitance. If it's got 20% tolerance, you're potentially exceeding the spec. If it's a cheaper cap with -20%/+80% tolerance, you're potentially vastly exceeding the spec. I'd recommend swapping it for a 4.7uF electrolytic or tantalum. Probably not best to use an MLCC because its very low ESR means higher inrush current and potential resonance issues when combined with the USB cable's inductance, but you can probably get away with it fine as long as you don't want to sell this as a product (where it'll need to pass EMC). If you do need this to pass conducted EMC, that's a bigger conversation.
The 10uF electrolytic output cap is probably not the best choice now I've had time to mull it over. A pair of 10uF tantalum caps (TAJA106K016RNJ) are a better option, or you could go with a pair of the 10uF MLCCs I recommended (which would be cheaper). This choice gets a bit tricky because AMS1117, LM1117, and AP1117 have different behaviours on this front. Check your LDO's datasheet to see if it mentions being stable with MLCCs only, and what the specific decoupling advice is. AMS1117, for example, says 22uF tantalum is ideal, so 2x 10uF tantalum should be fine. Often LDO vendors recommend doubling the capacitance (e.g. 47uF instead of 22uF) if you're using electrolytics, but you should follow datasheet / appnote guidance here.
It's worth spreadsheeting the current draw for everything on the 3V3 rail, too, to figure out how much power you're going to dissipate in that LDO. Unfortunately this does mean finding out how much juice the CPU realistically pulls despite their hot-garbage datasheet.
Video DAC
The UPduino IOs are used to drive the resistor ladder DAC, but those resistances are quite low so the IO current might be excessive for the FPGA. I wasn't able to find any IO current limit specs for the ICE40UP5K, so I'm not 100% sure. However, in the worst case (input lines 0, 1, and 2 low, and line 3 high, and assuming worst-case 5% tolerance on the resistors) the draw will be 5.47mA with 5V IO or 3.61mA with 3.3V IO. In the absence of information showing that the FPGA can handle that much IO current, it would be a good idea to use a buffer IC (a pair of hex CMOS buffers would do it) on the R0-R3, G0-G3, and B0-B3 lines to ensure that the IOs can provide enough current.
I'm not sure what frequency you're updating the DAC input signals at, so make sure the buffer IC is rated for it. Most modern CMOS buffer ICs should be fine.
It's also worth adding opamp buffers on the red, green, and blue outputs. This will make the outputs immune to leakage current, so you'll get correct R/G/B voltage levels on the SVGA output regardless of what display you plug in. Make sure the opamps are RRIO (rail-to-rail input and output) capable (or at least capable of going right down to 0V), and unity gain stable. Make sure the opamps have sufficient bandwidth and slew rate for the signal update rate.
If you have space, it might be worth adding a separate LDO for powering the output opamps, to make sure they have a nice clean rail. Again follow the decoupling advice on the LDO datasheet. You can get away without this but it adds peace of mind.
I'm also not a fan of the naming of the RGB signals, 'cos R2 (the signal) and R2 (the part) are ambiguous. Maybe prefix the signals with V, e.g. VR1.
USB IOs
Not sure about those 270R on the TXD/RTS lines. I don't see them in the datasheet and I'm not sure what purpose they serve here.
Might be worth adding the TX/RX swap footprint trick to both the TXD/RXD lines on the MCU side and the D+/D- lines on the USB connector side. Use 0603 or 0402 on the D+/D- side to avoid a large impedance discontinuity.
General
There's a lack of testpoints on the PCB. Don't forget to add them for easier debug. I also like adding a large plated ground pad right on the edge of the board somewhere, top and bottom, connected to ground, so I can clip a crocodile clip to the edge of the board really easily while probing.
I also recommend separating critical power and signal paths with SMD jumper pads or 0R footprints at the boundary between different blocks of the circuit. This allows you to isolate and test each block of the circuit sequentially and catch / debug issues early instead of just powering the lot on and praying for no magic smoke. For example I might add a 0R between VUSB and the LDO input, and then again between the LDO and the 3V3 rail. Wherever you think you might benefit from being able to turn one thing on at once, or disable something, or disconnect some signal for debugging. This also allows you to stick a shunt resistor inline with the voltage rails if you want to measure the rail current.