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.

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.

With this sequencing fix, 3V3 comes up fine (slightly low, 3.2804V, but that's acceptable) and the board is now drawing 207 mA / 2.5W at the input.

And Vtt is now showing zero volts with the regulator disabled, which is what we expect.

With the regulator enabled (and 1V8_IO enabled) we show 900.39 mV on Vtt and 897.33 mV on Vref, while drawing 227 mA (2.7W) at the input).

This is a bit more of a Vref-Vtt delta than I'd like but it shouldn't be enough to cause problems.

Final power rail is 2V5, which runs a lot of analog stuff in the PHY.

This came up fine as well, although also a bit low: 2.4834V.

Now pulling 293 mA (3.5W) at the input.

This is all of the core power rails done. Now I just have to add a few lines of code to release the FPGA and MCU resets and I'll be ready to start bringup of them.

This was a close shave. Almost couldn't fit both JTAG cables next to each other.

I verified non-interference of the board side male connector but forgot the female IDC connectkr overhung on the sides.

Bringup is going pretty well I think.

Maybe could use a bit more kapton tape?

Gradually bringing up firmware on the main MCU. UART, uptime timer, and config variable database are running, about to work on the link to the FPGA.

But first I need to do a bit of independent testing on the FPGA.

Just loaded a test bitstream on the FPGA and verified the LEDs all work. And the supervisor is able to see when the FPGA is up.

Next step, I think, will be getting the MCU and FPGA to talk to each other.

Got a stripped down version of the base FPGA bitstream running.

It's super nice having all of the data from different instrumentation all coming to one place in ngscopeclient so I can have a single dashboard to look at everything.

After fixing a few PEBKAC issues, MCU and FPGA are talking over quad SPI.

But the data coming back is shifted by a nibble or two from what I expect. Not yet sure if timing or logic issue.

Should have put test points on the QSPI bus but silly me thought that since it worked last time, I'd be fine with PHY layer stuff and could just use an ILA on the FPGA...

And they're talking properly! That's it for tonight, I have to be awake in five hours...

I'll probably work on thermal stuff after work, since that affects the health of the rest of the board. The tachometer output of the fan goes to the FPGA (for... reasons) so I need to implement a speed monitoring block and make it output RPM values over QSPI to the MCU.

Then I need to add a PWM generator on the MCU, and bring up an I2C bus to poll the four temperature sensors around the PCB.

Also I found a new design oversight.

I have monitors for the supervisor on every regulator PGOOD pin so I can detect and shut down if a rail starts sagging due to overcurrent etc.

But I don't have an ADC pin on the 12V input so I can't detect a failure of input power and sequence rails off properly. All I can do is wait until one rail trips out of regulation then panic shutdown the rest (without proper sequencing delays since this is indistinguishable from a short).

I2C4 isn't happy. Trying to read the MAC address EEPROM and getting hung up sending an I2C start bit. The register is supposed to be self cleared in hardware and I'm not seeing it ever clear.

So either there's a peripheral setup issue (nothing jumps out at me in a quick register dump) or something is wrong in hardware (SDA or SCL stuck/open).

Unfortunately this bus is on internal and back side routing exclusively (again, should have put a top side test point on... Derp). So I'm gonna have to rip off some tape and invert the board when I get home from work and see what's really going on.

Started a google doc with a live "things to do better next time" list. So far all are minor annoyances or things I can work around without having to bodge the board. (Anyone have a self hosted, lightweight suggestion for this kind of thing? Etherpad or something?)

https://docs.google.com/document/d/10j4HWuMBLfLvX5Notvezs26lcIxuNnWbeJlv_JciUEA/edit?usp=drivesdk

The I2C4 issue smells like a soldering issue so far, but I'll know more when I get home and land probes on the bus.

My main bench scope is out for service still so I'll need to use the 16 GHz monster to troubleshoot my I2C. Miiiiiight be slight overkill...

(I could also use the PicoScope but it's on the other side of the bench, not sure if probes will reach all the way over here)

Back from work and debugging the I2C issues.

I2C1 (temp sensors) is giving NAKs to any bus access while I2C4 (mac addr eeprom) hangs trying to send a start bit.

Probing I2C1 at the pins of the temp sensors shows SDA stuck at 0 while SCL is floating high as expected. Wonder if I have a bad solder connection on the pullups?

Time to pull some tape and cables off the board and get it back under the microscope.

OK, that explains everything.

Misread the alt function table and had PB6-PB9 set to AF4.

Turns out that while AF4 is I2C4 on some other pins, on PB8/PB9 it's... I2C1.

So I had two sets of pins muxed to the same peripheral and Bad Things(tm) happened, including traffic going out the wrong pins (gee, I wonder why it never got acked...)

Yep, this looks more sane.

The FPGA -> MCU QSPI link probably needs some timing tweaks still; it works at 25.6 MHz but when I try to bump it up to 32 or 42.6 MHz I start seeing results shifted by a nibble.

Will troubleshoot that later, I don't need more than 100 Mbps of MCU-FPGA throughput now (if ever).

Next step will be building the fan tachometer in the FPGA, I think.

Tachometer core on the FPGA builds OK but is giving values that are way off the ~5k RPM I measured for the fan with a scope.

Not yet sure why. The tach block integrates N (currently 16) cycles of the waveform, measuring period against a stable reference clock, then converts frequency from Hz to RPM.

I have a dead time (currently 1000 clocks at 187.5 MHz, so 5.3 us) after each toggle for debouncing which might be too short. Or maybe it's a math error converting from Hz to RPM. I'll find out tomorrow.

Turns out that while I did have a small math error (two *pulses* per revolution on the green wire, not two *toggles* per revolution), the main error was actually in my bit-serial divider IP.

Which I had written back in grad school for my thesis, and it worked great on that CPU because I happened to have the inputs stable from when a divide was issued until it retired. The interface spec called for the divider to register the inputs on the first cycle, but one line of code used the unregistered value instead. Oops!

Anyway, I now have working fan tachometers (no PWM outputs yet, so they're always at max RPM), plus I can read the FPGA sensors using the XADC, and the I2C sensors scattered around the board.

The STM32 also has an on-die temp sensor which I'm not using yet, but I think that's the only missing bit.

None of the Ethernet PHYs or power supply components have die temperature sensors on them to my knowledge. The SFP+ may have a sensor on its I2C bus, but I haven't brought that up yet (that will come much later).

Also tweaked a few timing settings on the quad SPI and I'm now getting reliable performance at 42.66 MHz (170.64 Mbps). That's as fast as I can go without either changing my FPGA-side QSPI IP to not require 4x oversampling, or moving it out of the RAM controller clock domain into something faster (which would then necessitate a lot more CDC blocks on the core fabric SFRs).

While the sensors are brought up in that they work and I have functions that read them, there's no commands in the CLI to read them later on (yet). So for now all you can get is single-point measurements during boot.

@jpm Yeah it's https://www.fs.com/products/11552.html?attribute=71429&id=2062755 or something very similar.

It's got DOM, but I haven't read through the relevant part of the spec to get that up yet. I figured I'd do that as part of the broader SFP+ bringup (including the SERDES IP on the FPGA and all of the other stuff).