Reworked all the bridges on the ESD diodes that I found during initial visual inspection, and tidied up a few bulk caps.
Did continuity tests to sanity check on each power rail and nothing is shorted.
Gonna start populating the front side after the little one goes to sleep. Should go faster than the back since it's mostly large ICs not hundreds of 0402s.
I usually begin top side assembly with large but flat components like BGAs so I don't risk knocking tiny stuff around while placing them. Then smaller passives and ICs, and tall capacitors and connectors last.
This FPGA is the single most expensive component I've ever put on a board. Shipping an entire tray for one chip might be slight overkill though...
Out of the oven, BGAs all look good under side view optical microscopy (best I can do without X-ray).
Two 0402s needed touchup with an iron due to poor wetting; they were 33 ohm resistors from a reel I've had since 2014 so they might be starting to oxidize too much for my ROL0 flux to handle.
Tomorrow I'll populate the through hole connectors then start the bringup process.
All soldered up and ready to start bringup!
Later today after my little lab assistant goes to bed, that is. She's still a year or two from being ready to take readings off test points for me... Being able to speak in full sentences is probably a prerequisite.
These are just quick phone pics, I'll do some beauty shots with the A7R and macro lens later.
Fit testing the thermal solution. Looks mostly good, but not permanently mounting it yet. If i find problems early on it'll be easier to rework without a heatsink in the way.
I provisioned for two fans but we'll start with one and see how it goes.
The QDR-II+ heatsink is somewhat sheltered by the RS232 jack and probably won't see much airflow bit heatsinking it was more of a "just in case" vs the FPGA and main PHY which will definitely need it. So i think I'll be OK.
Kid is asleep so it's back to the lab for me.
After a bit of cable management we've got the first signs of life out of the board.
Applied 12V power to the input and it's drawing 3.6 mA. This is normal and expected, as all power rails are supposed to be off at this point other than the raw input and the 3.3V standby rail driven by an LDO to power the supervisor.
Next step is to put some code on the supervisor and start bringing up more power rails.
Spent a little while updating my STM32 peripheral library for the L031 (this was my first design using it) but I now have the PLL active and a blinky running at 16 MHz from flash.
Now to get a serial console up so I can get some more debug output besides a single LED...
Ok, UART is alive. Next step is to bring up a timer, then I'll have enough stuff working on the supervisor that I can begin actual power rail testing.
Can you tell I spend a lot of time in IDA? :P
Timer and logging framework are up. Ready to actually move forward with bringup.
So far the only rails that are active are 12V0_RAW (unregulated 12V prior to the main load switch) and 3V3_SB (3.3V standby for the supervisor), which is *very* in spec - averaging 3.30027V.
Next rail is 12V0, the core 12V power feed for all of the other DC-DC converters. This is driven by a load switch which limits slew rate so that I don't pull too much inrush current.
This is the first rail that's under software control from the supervisor.
It came up just fine and measures 11.9979V. Total power draw from the input climbed to 17 mA which doesn't sound unreasonable for five big DC-DC bricks.
Next is 1V0, the core power supply for the FPGA, QSGMII PHY, and SGMII PHYs. This is a big one with a lot of load on it, so lots of room for something to go wrong.
It came up perfectly as well, sitting at about 1.00015V. Overall input power draw is around 100 mA at 12V so an extra 83 mA. Assuming 90% conversion efficiency this means the board is pulling about 896 mA on 1V0 at idle!
In the interests of limiting potential damage to the expensive prototype if there's a short, the supervisor is pretty aggressive with timing and rail monitoring. If it commands a rail to come up and it fails to give PGOOD after 5 ms, it will automatically panic and shut down all power, then print a diagnostic message to the UART.
Unfortunately, the streak has come to an end with 1V2 which failed to come up within the (admittedly aggressive) 2 ms timeout. The automatic shutdown did its job and I don't think anything fried.
Next step: toss some probes down and see what's going on with that rail.
Looks like the 2ms timeout might just be too aggressive. It seems like the rail (blue) is coming up just fine then the MCU gets antsy and shuts it down before it's come up all the way.
But hey, it was a good test of my protections!
1V8 is next. This is the core rail for the QDR-II+ SRAM and also runs (through a load switch which is currently off) most of the single ended digital I/Os on the board.
It came up fine, measures 1.792V, and the board is pulling 135 mA from the 12V input.
Still performing nominally but I need to be up early-ish tomorrow to do family weekend things so this is probably as far as I'm going to get.
Tomorrow I need to bring up the 1V8_IO, 2V5, 3V3, and Vref/Vtt rails and verify that all of the analog rails filtered off the core ones have correct voltages.
Then I can hook up to the JTAG on the main MCU and the FPGA, load some blinkies, and begin the fun part of the bringup process!
But first, time to open a support case with STMicro for the six datasheet errata I found while bringing up the supervisor firmware.
Just *once* I want to do a design with a new digital chip of nontrivial complexity and not have to do this. Plz?
Time to bring up another rail. 1V8_IO is slightly lower than 1V8 (1.7886V) due to voltage drop across the load switch, but this is well within acceptable limits.
Pulling 188.9 mA (2.3W) on the 12V input.
Tried to bring up Vref / Vtt for the QDR-II+ but I'm seeing 1.8V instead of 900 mV which isn't good.
This is <= VCCIO so I don't think I damaged any of the input buffers on the RAM. (The FPGA is definitely fine since these pins aren't even configured as Vref inputs yet and the bank is powered by 1.8V).
But I either have a PCB assembly problem or something wrong in the schematic. Time to do some digging...
Not great, seeing 1.8V on Vtt even with the Vtt regulator disabled (but with 1V8_IO on).
With 1V8_IO disabled but 1V8 on, I'm also seeing 1.8V on Vtt. But Vref isn't showing much of anything in that state.
Continuity check does *not* show any shorts from 1V8 or 1V8_IO to Vtt, innnteresting.
The Vref and Vtt rails are coming from a LP2996A (U18).
Here's the relevant schematic.
Yep, LP2996 datasheet says that AVIN is supposed to come up first.
This is a bit of a conundrum because the FPGA has VCCAUX driven by 1V8 and VCCO driven by 3V3.
And it wants VCCAUX to come up before VCCO.
But we're allowed to do the opposite (VCCO > VCCAUX + 2.625V) for up to Tvvco2vccaux (300-800ms depending on temperature) per power cycle, with a total of 240K power cycles. This might lead to some glitching on 3.3V GPIOs on the FPGA but I think that will be OK in this use case.
Yay for fixing hardware problems in software! I'll just bring up 3.3V before 1.8 and we should be OK.
For LATENTRED I'll switch AVIN to run on 3V3_SB at which point everything should be OK.
@emeb STM32L031.
Mostly reserved blocks not being the size the datasheet said they were (important, because I use these sizes for padding blocks in linker scripts to make sure each SFR is at the right offset).
How have you found ST support?
After dealing with Microchip's policy of "we won't support you if you're not using our drivers", I'm kinda dreading writing up this DMA descriptor issue...
@azonenberg Thanks a lot for the writeup, I deeply enjoyed it!
Looking forward to the follow-ups, after a well-deserved break with your family :)
@QuaternionCats That's exactly what I do in stm32-cpp.
https://github.com/azonenberg/stm32-cpp/blob/master/devices/link/stm32l031.ld
@biggestsonicfan I do *not* need something to slip or get snagged and yeet a >$2K prototype I spent three days assembling across the lab and onto a concrete floor.
Tape is cheap.
Also, once I start doing SI verification I'm going to have multiple very expensive differential probes soldered to it.
@wackyvorlon 14x 10/100/1000baseT + 1x 10Gbase-R SFP+ managed Ethernet switch. FPGA based fabric (so fully open source packet datapath) rather than using a switch ASIC.
This is a scaled down prototype for a planned 24 port 1U version.
@wackyvorlon Because I can? Lol. That, and my Cisco 24 port edge switches are getting a bit long in the tooth and I need more baseT ports on my main lab bench.
A homebrew switch has been on my projects list since 2012 or so. My first board was a 4 port switch built around a 25k cell Spartan-6 but a combination of board design issues, lack of FPGA space, lack of experience, and lack of proper test equipment meant it never worked.
Over the years I've built various bits and bobs, got better at FPGA design, and got better test equipment so I can actually test it.
@wackyvorlon https://www.digikey.com/en/products/detail/amd/XC7K160T-2FBG484C/3911021
Currently sells for $435 although I ordered it back in 2021 so price may have been a bit different then.
Putting it in the toaster oven was still a bit nerve wracking no matter how many times i double checked.
@azonenberg Just ran across this FPGA. I had no idea ones this expensive even existed…
https://www.digikey.ca/en/products/detail/amd/XC7K410T-2FFG900I/3543163
@wackyvorlon You think that's big? Look up the XCVU9P lol.
Needless to say I won't be using one in a design any time soon
@wackyvorlon ASIC R&D mostly. If you're spending many $M on a new SoC or GPU design, spending a few bucks on prototyping hardware is not going to break the bank.
Also, Digikey markups for expensive chips in low volume are insane. The devkit for that $50K chip is like $8K so I have to assume they charge big clients even less than that per chip. Expensive, but if you're Qualcomm or Apple or Nvidia you can easily afford racks full of them to support a big project.
@azonenberg @wackyvorlon XCVU57P goes brrrr 😬
„Hey, eh, Boss, that strange new BGA chip, I broke that while soldering, is that an issue?“ 😹
@wackyvorlon Yeah it's the biggest FPGA I've used in a design.
I own larger ones (an XC7A200T on an AC701 dev board, an XC7A200T in inventory that I haven't made a board for, and a pair of XCAU25P's also in inventory), and have used an XCVU9P on somebody else's dev board, but haven't done a board design for any of those yet.
Spec wise the XC7K160T has 101400 LUT6s, 202800 flipflops, 600 DSP slices (25x18 bit multiplier plus some extra stuff for efficient FIR filter implementation), 325 36 Kbit SRAM blocks, sixteen PLLs, and up to eight 12.5 Gbps SERDES lanes and 400 GPIOs. The package I'm using on this board "only" pins out four of the SERDES (max 10 Gbps in this speed grade), and 285 GPIOs.
Not at all enormous by professional FPGA standards, but roughly 20x the logic capacity of, and significantly faster than, an ice40hx8k.
Andrew Zonenberg
Eric Brombaugh
Matt Keeter
Martin Roukala (né Peres)
Tom Verbeure
Tavy, Counterfeit Consciousness
I love this, so I
biggestsonicfan
Alyssa🏳️⚧️
Manawyrm | Sarah