@azonenberg@ioc.exchange
@azonenberg@ioc.exchange avatar

azonenberg

@azonenberg@ioc.exchange

Security and open source at the hardware/software interface. Embedded sec @ IOActive. Lead dev of ngscopeclient/libscopehal. GHz probe designer. Open source networking hardware. "So others may live"

Toots searchable on tootfinder.

This profile is from a federated server and may be incomplete. Browse more on the original instance.

azonenberg, to random
@azonenberg@ioc.exchange avatar

Finished layout of one of the two power pour layers, added a bunch of ground stitching vias and a shield ring attached to chassis ground around the perimeter. Also fixed a bunch of DRC errors related to the RAM (meanders slightly too close together etc).

KiCAD layout screenshot showing stitching vias

azonenberg,
@azonenberg@ioc.exchange avatar

Almost bedtime... but first, kicking off a Sonnet sim to run overnight. Lots of SI tuning still to do before the board is finalized.

This is one of the ESD diodes on the baseT lines. Traces come in on the top, drop down to the bottom, go through the diode, then go up to layer 3 and travel to the RJ45 there.

I want to make sure the differential pair layer transition is good, and also see if I might need a ground plane cutout under the ESD diode footprint to reduce excess capacitance.

This is probably overkill for 1000baseT but as long as I'm simulating all of the faster stuff, why not do this too?

Sonnet 3D render of the layout being simulated, from a different angle

azonenberg,
@azonenberg@ioc.exchange avatar

@jduncanator I have a separate part, with a mechanical (M) refdes for the heatsink, then just place both footprints at the same coordinates.

This seems to make sense to me, since they're two physical components assembled at different times, so two BOM lines etc. makes sense.

The same is true for the SFP+ connector / cage, that's also a two-parter.

azonenberg,
@azonenberg@ioc.exchange avatar

Return loss looks pretty decent, kicked off a second sim with cutouts under the pads just to see if it'll make much of a difference.

azonenberg,
@azonenberg@ioc.exchange avatar

@gsuberland Yep.

I don't have any coupling components on the RAM so no worries there, the RGMII is slow.

The baseT is also pretty slow but is a long distance connection with potentially weak signals so I do want to optimize it to the extent practical to ensure good performance with long cables etc.

Other than that, I have AC coupling caps on the SGMII (1.25 Gbps), QSGMII (5 Gbps), and then the connector footprint for the SFP+ (10.3125 Gbps), all of which will likely need cutouts simulated.

azonenberg,
@azonenberg@ioc.exchange avatar

@gsuberland I generally don't have those going off board in a high risk environment.

I didn't include them on the SATA sniffer because that was intended to be used only in an ESD controlled lab, not a general purpose tool.

The only off board interfaces I have here other than debug and baseT is the SFP+, and the ESD risk there is minimal because you have a big shield cage connected to chassis ground making contact waaaaay before any of the high speed data lines. So I didn't put any protection there either.

The baseT is potentially going to long range plant cables that travel outside the controlled lab, so I might well end up wearing a polyester sweater and standing on a hardwood floor while plugging a cable into the far end.

azonenberg,
@azonenberg@ioc.exchange avatar

@moonwick I'm using them specifically for power rail test points because I have a probe designed to mate with them, the Teledyne LeCroy RP4030 (https://cdn.teledynelecroy.com/files/pdf/active-voltage-rail-probe-datasheet.pdf)

azonenberg,
@azonenberg@ioc.exchange avatar

@moonwick You can get most of the benefits with two separate setups you switch between:

  1. U.FL -> SMA + SMA -> banana cables, to do precision voltage measurements with a DMM

  2. U.FL -> SMA + SMA DC block to oscilloscope with 50 ohm termination, to measure ripple without overloading the scope input or loading down the power supply excessively with 50 ohms to ground

What this won't show you is mid-frequency stuff, like a rail sagging under a slow change in load.

But I only have one RP4030 and I have used this technique with good success to monitor noise on multiple rails when the RP4030 was in use for another rail.

azonenberg,
@azonenberg@ioc.exchange avatar

Sim is still running (I didn't exactly optimize, it's got lots of round curves causing very fine meshing in spots where it probably doesn't matter) but the cutouts seem to give about a 5 dB improvement in return loss over the frequency bands of interest for 1000baseT (10 MHz to 1 GHz in this simulation).

Probably not a huge difference given that it was pretty good already, but why not? It won't hurt.

Sonnet 3D model (upside down for clarity) of the geometry being simulated showing ground plane cutouts
Sonnet current density plot showing return current at 1 GHz in layer 7 ground plane under differential pairs, traveling around plane cutouts
Sonnet current density plot showing 3D current flow through vias and return current under ESD diode footprint

kwf, to random
@kwf@social.afront.org avatar

All other arguments about TLS vs plain HTTP for Linux update downloads aside, I'll point out that Manjaro uses TLS to download updates, and this is bottlenecking the performance on our T620 plus 10Gbps #MicroMirror nodes.

CPU tops out around 3Gbps for thousands of tiny requests using TLS 1.3.

azonenberg,
@azonenberg@ioc.exchange avatar

@gsuberland @kwf It might be: if they're using cron for scheduling, I don't think the crontab file format supports sub minute granularity.

azonenberg,
@azonenberg@ioc.exchange avatar

@gsuberland @kwf (although you could add a random <60 second sleep to the command cron runs, I guess)

azonenberg, to random
@azonenberg@ioc.exchange avatar

I should probably get to bed, but I finished the QDR length matching! Had to swap one signal in a tight spot to a different layer, but it all fit with +14.8 / -11.4 ps max skew.

This is well within tolerance: the Xilinx MIG guidelines call for 15ps D/Q and 50ps C/A at Fmax, and I'll be running this 450 MHz rated QDR-II+ a bit slower than spec (375 - 425 MHz most likely) so I have even more timing margin.

QDR-II+ layout, layer 3
QDR-II+ layout, layer 6
QDR-II+ layout, layer 1

azonenberg,
@azonenberg@ioc.exchange avatar

@vincentb Probably because you're modeling different geometry than I'm actually using :)

On the stackup I'm using, the conductor is 35 μm thick (you have 35+35 = 70) and covered by 40 μm of soldermask with Dk of 3.5 (you show no soldermask, I'm not sure if Saturn can model that).

You do seem to have the substrate right (75 μm of TU872SLK with Er of 3.9).

My Sonnet simulation of the layer shows a bit of low frequency ripple then converging to around 123 ps for a 20mm long line.

azonenberg,
@azonenberg@ioc.exchange avatar

@vincentb Yeah I'm using the same stackup that I used on the sniffer for this board.

And yes, the soldermask can have a significant impact in some cases because it's essentially turning the microstrip into something closer to a stripline (dielectric on sides/top).

You can also see a big impact in loss from mask for similar reasons, a lot of the field ends up in it.

azonenberg, to random
@azonenberg@ioc.exchange avatar

Starting to look more like a proper high speed design!

All of the QDR-II+ tracks on layers 1 and 8 are skew matched and good to go. Still have to do the inner layers, which might be an adventure...

Screenshot of spreadsheet showing most of C/A bus plus a few D lines correctly length matched

azonenberg, to random
@azonenberg@ioc.exchange avatar

Got all of the pinout, package skew, and velocity factor data entered into my spreadsheet for the QDR-II+.

So far things are... not great. The longest traces are over 200ps too long and the shortest are nearly 100ps too short.

The target tolerance is +/- 15ps for the D/Q bus and 50ps for the C/A bus. So I've got some work to do....

Maybe one day KiCAD will get useful time domain skew matching tools. The current setup is useless because it works in distance units, so there's no way to account for things like different velocity factors for different layers. And while it supports package skew in distance units, every vendor I've ever seen reporting package skew does so in time units.

azonenberg,
@azonenberg@ioc.exchange avatar

Couldn't figure out how to make Q32/Q33 any shorter so I had to make the capture clock longer to compensate.

Which means the whole rest of the Q bus is now way too short and I have to lengthen that, but hey, it's easier to add length than remove it!

KiCAD screenshot of the back side of the board showing length matched traces

azonenberg,
@azonenberg@ioc.exchange avatar

@tenerya Kicad can do matching to a target length no problem, it's had this capability for ages.

And it can sort of account for layer thicknesses of vias if you enter that info in the stackup manager, but it doesn't calculate velocity factor or allow you to account for package time delays properly.

So I just made my own libreoffice sheet from scratch. Input the package delays from Vivado, the current trace lengths, and a bunch of formulas and it spits out the target length for each trace relative to its parent clock. If the constraints are impossible to route, make the clock longer and try again.

azonenberg, to random
@azonenberg@ioc.exchange avatar

Fully routed! Just need to do a bunch of zone fills, ground plane cutouts, length matching, and more.

Still a couple days of work at the current pace probably.

azonenberg, to random
@azonenberg@ioc.exchange avatar

It's that time of year again! The saline cartridges for my eye wash expired at the end of May (thankfully unused) and it's time to put in new ones.

But first, I need to drain the old ones. Easiest way to do that is to activate it and just let the 15 minute flush run to completion.

Closeup of the eye wash nozzle assembly showing the spray of saline
Two replacement saline cartridges: large mylar bags of fluid with a cardboard shell for structural support

azonenberg,
@azonenberg@ioc.exchange avatar

This is a pretty clever design, the pusher plates on top of the fluid reservoir are attached to the drain pan at the base of the unit. So as the tanks drain, the fluid pressure remains almost constant until they're fully exhausted.

azonenberg,
@azonenberg@ioc.exchange avatar

Top down view of the pusher plate assembly showing nearly drained cartridges

azonenberg, to random
@azonenberg@ioc.exchange avatar

Almost done with initial routing. 74 nets left, mostly related to FPGA bulk decoupling capacitance and the Vtt / Vref LDO.

Then it'll be time for the fun of length matching the QDR. As of now, some of the lines are as short as 20 mm and others as long as 51 mm, so there's definitely some work to be done there!

bikerglen, to random
@bikerglen@mastodon.social avatar

Time to fly! 🛩️ 🚲 https://hackaday.com/2023/06/03/bike-rides-played-back-via-aircraft-altitude-indicator/

azonenberg,
@azonenberg@ioc.exchange avatar

@bikerglen The logical next step is to mount the altimeter on your bicycle to give you a live reading, so you can watch the altimeter twirling as you roll down the hill. Right?

isis, to random

good morning! time for me to go searching the forest for someone whom a missing persons police report has been filed and who may be having a mental health crisis and see what i can do to help :(

azonenberg,
@azonenberg@ioc.exchange avatar

@isis Quite a few of the folks in our unit have wildland FF experience too, there's a lot of overlap I guess.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • megavids
  • thenastyranch
  • rosin
  • GTA5RPClips
  • osvaldo12
  • love
  • Youngstown
  • slotface
  • khanakhh
  • everett
  • kavyap
  • mdbf
  • DreamBathrooms
  • ngwrru68w68
  • provamag3
  • magazineikmin
  • InstantRegret
  • normalnudes
  • tacticalgear
  • cubers
  • ethstaker
  • modclub
  • cisconetworking
  • Durango
  • anitta
  • Leos
  • tester
  • JUstTest
  • All magazines
    •