Conversation

Notices

1. Embed this notice
   Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Wednesday, 27-Mar-2024 03:36:12 JST Andrew Zonenberg

   Top side 0201 on the output didn't change output ripple at all (319 mV) but dropped input to the lowest it's ever been (32.6). Huh.

   Let's try an 0402 0.47 on the top right near the output cap.

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Wednesday, 27-Mar-2024 03:36:09 JST Andrew Zonenberg

     in reply to

     Board is cleaned up and back on the bench.

     Tried out the CDR trigger input for the first time and I'm getting flatlined output. Not sure what happened there.

     But it's a pretty low priority for debug because I have so many other things to do and I already have a differential CDR trigger capability in hardware (no firmware to implement it, but it's there when I have time). The single ended was really just a bonus.

     I'm not having good luck with comparators on this project though...

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Wednesday, 27-Mar-2024 03:36:09 JST Andrew Zonenberg

     in reply to

     Aaaand I'm not getting signals on several of the input channels and the DAC Vref looks bad.

     Thinking back, I don't think I ever solved the problem of DAC0 not giving valid output.

     So cleaning the board might have been a bit premature, the DAC might still need rework...

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Wednesday, 27-Mar-2024 03:36:10 JST Andrew Zonenberg

     in reply to

     Nope, two more 0402s on the output piggybacked above the bulk cap did zilch. Probably too much inductance for them to help.

     I guess I'll have to live with a 3.4x reduction from the original ripple. Improved, if not as far as I'd like.

     This is the last planned rework.

     So I'm gonna pull the board and give it a nice scrub in some SWAS to deflux, then set it back up on the bench and focus on firmware dev from here on out.

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Wednesday, 27-Mar-2024 03:36:10 JST Andrew Zonenberg

     in reply to

     Have a few chores to do but when I'm done it's cleanup time.

     This is the best flux remover I've found for no-clean fluxes, but it's not particularly good for you (10-30% tetrahydrofurfuyl alcohol).

     The stuff is stinky enough that after rereading the SDS I've decided to stop using it outside the fume hood.

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Wednesday, 27-Mar-2024 03:36:11 JST Andrew Zonenberg

     in reply to

     The capacitive tower of babel is growing. I'm about to add my third cap to the second story.

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Wednesday, 27-Mar-2024 03:36:11 JST Andrew Zonenberg

     in reply to

     And with that, ripple is down to 171 mV p-p.

     Still not *great* but I'm tempted to stop soon. It seems like I'm hitting diminishing returns of what I can do without a re-layout of the supply.

     Maybe one or two more, though. After lunch.

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Wednesday, 27-Mar-2024 03:36:12 JST Andrew Zonenberg

     in reply to

     That helped a lot. Output ripple now 236 mV. Let's see if I can find space for another.

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Wednesday, 27-Mar-2024 03:36:38 JST Andrew Zonenberg

     in reply to

     Ok so it looks like the slow startup after the link comes up is because my IP stack never sends an ARP query for the default gateway.

     So it just sits there not sending any packets until a gratuitous ARP or broadcast from the gateway's IP shows up.

     That should get fixed.

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Wednesday, 27-Mar-2024 03:36:39 JST Andrew Zonenberg

     in reply to

     I'm somewhat impressed. These two random 36" KF047 cables I had lying around are phase matched tightly enough that the ML4039-BTP BERT can send a 10.3125 Gbps PRBS15, with totally guesstimated FFE settings, to the Kintex-7 GTX with a very low BER (zero errors in the minute or so that I felt like waiting).

     I guess now I have to implement all of the glue I need to support proper BERT operation now. Like runtime configurable rates (ideally DRP to dynamically tweak PLL configuration but we'll see how that goes), eye scan, inversion, etc.

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Wednesday, 27-Mar-2024 03:36:39 JST Andrew Zonenberg

     in reply to

     Pretty soon I'm going to be ready to start building a scopehal driver for this thing, the firmware feature set is coming together.

     Still some instability on the Ethernet or TCP/IP side (not yet sure if FPGA or MCU is at fault) but that's orthogonal to the application firmware and I'm on a roll here so I think I'll keep it up.

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Wednesday, 27-Mar-2024 03:36:39 JST Andrew Zonenberg

     in reply to

     And I think that's TX-side BERT functionality done, other than rate control (it's fixed 10.3125 Gbps right now... sub-rate to divide by 2/4/8/16 will be straightforward but hitting nice round lower rates will require some DRP fun since the QPLL is fixed 10.3125 for 10GbE in the same quad).

     This is probably complete enough feature set wise that I can start building the scopehal driver. There's no RX over SCPI yet, but that will come later.

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Wednesday, 27-Mar-2024 03:36:40 JST Andrew Zonenberg

     in reply to

     So much for thinking I was done with rework, lol.

     But I think this actually *will* be the last rework considering I've now validated pretty much everything hardware wise.

     Famous last words.

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Wednesday, 27-Mar-2024 03:36:40 JST Andrew Zonenberg

     in reply to

     Anyway it's getting late enough I don't want to do any fine soldering but I am going to start work on getting the BERT functionality up.

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Wednesday, 27-Mar-2024 03:36:41 JST Andrew Zonenberg

     in reply to

     There's some strange hangs in the MCU firmware where sometimes it takes longer than expected to process a SCPI command, and it seems to take a while to start responding to ping when first powered up. So still debug to do on that front too.

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Wednesday, 27-Mar-2024 03:36:41 JST Andrew Zonenberg

     in reply to

     Reflowed the DAC and now it's definitely improved.

     IN2/3 is flatlined despite having valid input and Vref looking correct.

     Probably a solder defect, these are ones that I reworked early on and it looked good visually but I didn't do a functionality check yet as I didn't have the necessary firmware done.

     Also definitely need to debug why the firmware suddenly stops responding when I'm sending it SCPI commands, then is fine when I reconnect.

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Wednesday, 27-Mar-2024 03:36:42 JST Andrew Zonenberg

     in reply to

     Oh, and the crossbar itself is done and working and you can set mux selectors via SCPI.

     The CDR trigger needs more hardware debug. The SFP+ links up and should be able to receive frames, but the arbitration logic for deciding whether to send frames to the SFP+ or the RGMII MAC isn't done yet so right now I hard code sending to RGMII.

     The BERT/pattern generator ports are working and spitting out hardcoded PRBS15, but I don't have any firmware/gateware to control swing, pattern, inversion, FFE taps, or the receiver yet.

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Wednesday, 27-Mar-2024 03:36:42 JST Andrew Zonenberg

     in reply to

     As far as hardware goes, since this board seems to have had a lot of solder issues, let's just go through and validate every single one of the IO ports.

     IN0...IN7 are nonfunctional due to the DAC being flatlined; all testing on them will have to be tabled until I rework the DAC that I somehow forgot to do earlier. I swear I had got to it... this is what happens when you're doing bringup in between parenting a toddler I guess lol. I should keep better notes.

     All of the unbuffered outputs (OUT0-3) work.

     All of the buffered unidirectional outputs (OUT4-7) work.

     All of the bidir IOs (IO8-11) work as both inputs and outputs.

     I strongly suspect the inputs on 0...7 will work fine once I fix the DAC. Guessing just bad soldering since the SPI bus to it looks fine. Just mad I didn't do that already as I thought I had finished the rework...

   • Embed this notice
     Andrew Zonenberg (azonenberg@ioc.exchange)'s status on Wednesday, 27-Mar-2024 03:36:43 JST Andrew Zonenberg

     in reply to

     In the meantime, let me at least validate all of the other stuff I can before decabling *again*.

     FPGA and MCU firmware seems to be at MVP level (that's "minimum viable prototype", as in all core functionality needed for operation has been demonstrated but not necessarily fully debugged).

     In particular, I can plug the device into a 10/100/1000baseT LAN (the SFP+ side still needs more work but it's functional without that) and it comes up on a hard coded IP address because I haven't got around to adding UART console commands to change that. It's reachable via SSH using a hard coded username and password and gives you a shell equivalent to what you get from the UART.

     There's a SCPI server on port 5025 that provides commands to change direction of bidirectional ports, set threshold of inputs, and set swing of outputs.