azonenberg

azonenberg, 3 months ago to random

Assembling the trigger crossbar board over lunch.

Not thrilled with the paste print quality, very inconsistent. the top left corner was way too thick as the board flexed during printing, the middle BGA skipped some pads, and the WLCSP in the bottom right was near perfect.

These big boards bend too much in my paste fixture, I need to find a way to prevent that before I do any more boards of this scale.

azonenberg, 10 months ago to random

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.

azonenberg, 1 month ago to random

New thread on my big ongoing embedded project since the other one was getting too big.

To recap, this is a pilot project for a bunch of my future open hardware T&M and networking projects, validating a common platform that a lot of the future stuff is going to run on.

The primary problem it's trying to address is that I have a lot of instrumentation with trigger in/out ports, sometimes at different voltage levels, and I don't always have the same instrument sourcing the trigger every time.

So rather than moving around cables all the time and adding splitters, attenuators, amplifiers, etc. to the trigger signals I decided to make a dedicated device using an old XC7K70T-2FBG484 I had lying around.

Of course, as with any project, there was feature creep.

I'm standardizing on +48V DC for powering all of my future projects as it's high enough to move a lot of power but low enough to be mostly safe to work around live. So I needed to design and validate an intermediate bus converter to bring the 48 down to something like 12 for the rest of the system to use.

The FPGA has four 10G transceiver pairs on it. I used one for 10GbE (not that I need the bandwidth, but I was low on RJ45 ports on this bench and had some free SFP drops) and the rest are hooked up to front panel SMA ports (awaiting cables to go from PCB to panel) to generate PRBSes for instrument deskew.

Since I'm pinning out the transceivers and am planning to build a BERT eventually, I added BERT functionality to the firmware as well (still need to finish a few things but it's mostly usable now).

And since I have transceivers and access to all of the scope triggers, it would be dumb not to build a CDR trigger mode as well. That's in progress.

azonenberg, 6 months ago (edited 6 months ago) to random

Hardware reversing time! Let's have a look at something modern that might be fun to decap and study a bit.

This is a Micron 32GB DDR4 ECC LRDIMM, organized as 2Rx4 (2 ranks, 4 bits per chip, so 18 DRAM chips per rank). It was in active use in one of my servers until it started throwing ECC errors a few months ago.

So now it's microscope food.

azonenberg, 4 months ago to random

Today is a good day.

azonenberg, 4 months ago to random

"You will see the SD boot image in the build_sdimg folder. You can just copy all these filed in that folder into a SD fat partition, And then extract the root file system we provided to the sd card ext4 partition."

WHERE IS THIS ROOT FILESYSTEM YOU PROVIDED? I don't see it anywhere.

Buildroot generates a bunch of stuff in output/target/ but it's missing all of the device nodes etc.

https://github.com/MicroPhase/antsdr_uhd/tree/master/firmware

azonenberg, 8 months ago to random

Back to the Ethernet switch project after a while off. Time to try and figure out what's going on with the MDIO bus on the VSC8512.

azonenberg, 9 months ago to random

Got back from a trip visiting family on the east coast and found my new eBay score had shown up!

MultiLane ML4039-BTP 100G BERT. Four channels of calibrated PRBS generator and receiver up to 30 Gbps per lane. Should be very useful for validating a lot of my high speed projects with SFP+ (and, in the future, SFP28) interfaces and my probes.

Headless half width 2U form factor with IP remote control, perfect for my space constrained lab. The software is Windows only and doesn't work under WINE but I can live with that.

It was listed as "new, open box" and I got it for about a third of MSRP. Just to be on the safe side, let's open it up before plugging it in. It's clearly been used at least a little since there's dust visible on the fan.

Back side of the BERT showing the Ethernet port, USB bringup interface, cooling fan, and power inlet

azonenberg, 6 months ago to random

Components for the 48V IBC came in today. Will be assembling after work!

azonenberg, 3 months ago to random

Starting initial testing to see how in the world I might try to fan out the GTYs of an UltraScale+ B676 package on OSHPark 4 layer.

I don't have the full schematic done, just doing initial layout feasibility checks.

The goal is to hook up "as much as reasonably possible". First non-negotiable requirement is that it has to fit on an OSHPark 4L board and it has to provide minimum power and JTAG connections so I can verify the reballed chip is alive.

After that, anything is a bonus.

Here's an initial quadrant dogbone fanout on 0.5mm legs for all of the power/ground balls in one corner of the GTY area. This will likely not be the final via location.

azonenberg, 6 months ago to random

Board I've been waiting on for a while finally came in.

This is my experiment at (possibly) moving away from the Vishay HML series axial lead resistors as probe tips, in favor of something with an easier supply chain and potentially even better performance.

HML for scale on top of the PCB.

azonenberg, 9 months ago to random

Folks who have done both bare metal (RTOS or just simple event loop/interrupts) and embedded Linux system work: why does everyone seem to think embedded Linux is easier?

Having worked on projects doing both I struggle to see why that's the case. Putting down a big SoC and laying out DDR memory buses. Dealing with u-boot, spending forever compiling kernels and libraries and dependencies and device trees. So much overhead and effort.

I can see it making sense for high end stuff like video processing that needs GPU acceleration, complex GUIs that are eaiser to test in a PC environment using the same GUI toolkit, etc. Things that already need GB of external memory or compute power for the application software itself, so you need that overhead anyway.

But for simpler stuff like a web/ssh management interface on some simple embedded system it's soooo much extra work.

azonenberg, 3 months ago to random

With the 1000baseT1 boards mostly alive, but no progress on decoding until I get the new coupler board, I'm shifting gears to the trigger crossbar.

Building the back side tonight. Probably won't have time to do the front until tomorrow.

I need to figure out a solution for working with larger boards. This thing is maxing out my current stencil fixture. And my dreams are only getting bigger from here.

azonenberg, 1 month ago to random

After a very windy afternoon Puget Sound Energy is now tracking 140 separate outages across the region affecting roughly 22.1K buildings.

Lab is operating on generator power and some equipment shut down when a loose UPS EBM cable resulted in running out of battery before the generator started.

So much for a nice relaxing weekend. Guess it's an excuse to do some hardware maintenance I had been putting off trying to avoid downtime.

azonenberg, 1 month ago to random

Every time you write code like this a Rust developer somewhere cries.

But I can't think of any better way to do a zero-copy IP stack. In this case, I need to be able to go from a UDP packet to the parent IP packet, but the UDPPacket object can't have a pointer to the parent because it's literally just the raw on-the-wire bytes at the correct offset casted to a UDPPacket*.

IPv4Packet* Parent()
{ return reinterpret_cast<IPv4Packet*>(reinterpret_cast<uint8_t*>(this) - sizeof(IPv4Packet)); }

azonenberg, 1 month ago (edited 1 month ago) to random

As someone who's written code at one time or another in C, C++, Verilog, SystemVerilog, VHDL, GLSL, PHP, JavaScript, Pascal, Oz, Java, Salsa, i386 assembly, PIC12 assembly, MIPS assembly, x86-64 assembly, ARM assembly, Prolog, Bash, VBScript, DOS batch files, FEI AutoScript, CMake, and even a few dozen lines of Python years back...

I can confidently say Rust is alien technology.

Maybe one day I'll grok it but today I feel like I sat down in front of a Klingon PC and tried to understand what it was doing.

People say learning an HDL as a software person is a brain twister? This is 10x more confusing than Verilog was.

azonenberg, 8 months ago to random

Anybody have recommendations for industrial automation folks in the Seattle area? Looking for someone to help $dayjob with a very simple VFD programming job that is driving me up the wall.

No PLC, single motor, single drive, just needs to spin at a constant (not 100%) RPM whenever we tell it to run.

azonenberg, 1 month ago to random

New toy! Busy being a dad for a bit but will set it up after she goes to bed.

Closeup of the Stanford Reaearch Systems stamp on the top of the box

azonenberg, 7 months ago to random

Thinking of adding a coding style rule to some of my projects that bans unsized integers (int, short, long).

Char will be allowed for manipulation of strings (since every platform I target has 8 bit characters) but otherwise stdint types only.

Thoughts? Also, is anyone aware of a gcc/clang compiler flag or f/oss linting tool to enforce such a policy?

azonenberg, 9 months ago to random

Do I know any artists interested in drawing some GUI icons for a F/OSS project? Simple vector line art, maybe with an outline/backdrop of some sort common to the entire set.

Hoping to find someone willing to donate time since we don't have much in the way of budget, but I understand time isn't free and if someone offers me a reasonable rate I'll try and scrounge up the cash to make it happen.

azonenberg, 4 months ago to random

@dlharmon What do you know about fast but lightweight FEC (perhaps RS similar to used in newer Ethernet)?

I'm idly musing about ways to squeeze more performance out of DDR interfaces and wondering if it might be possible to use a lighter weight FEC than the standard 64 -> 72 Hamming code in order to gain some resistance to errors but also store an average of >64 bits per DRAM word.

My use case would be for large block transfers so a bigger FEC block is acceptable as long as an FPGA based encoder/decoder can run at full 150+ Gbps line rate.

azonenberg, 3 months ago to random

Testing out the new IQ Demux and Constellation filter blocks in ngscopeclient.

IQ Demux is intended for working with 2D modulations where you have the I and Q values sent consecutively on the same channel. It splits out the interleaved I/Q values to separate channels which you can then feed to the constellation filter.

Of course, the 26 Gbaud PAM4 PRBS I'm looking at here isn't actually a vector modulation, but it's a convenient source of fairly clean test data.

azonenberg, 6 months ago to random

Starting to polish up the lecture for my probing class more and build out the lab as well.

Anyone want to give feedback? Here's the first of ten sections (introduction), which I think is pretty much done.

https://www.antikernel.net/temp/sec01-opener.pdf

azonenberg, 3 months ago to random

Does anyone know if there is a piece of test equipment that:

• Is generally oscilloscope-esque (measures voltage over time)
• Has a ton of channels. Eight or ten minimum, ideally significantly more
• Has high-ish DC input impedance (tens of kΩ) and low AC impedance (50Ω)
• Input range of at least +/- 12V, ideally up to 48V or more
• Fairly low BW specs by scope standards, I need maybe 10 MHz and something under 100 Msps.
• >8 bit vertical resolution would be nice

I don't want to have to build it, but I don't think it exists. A synchronized pair of Teledyne LeCroy WaveRunner 8000HD scopes with RP4060 active power rail probes would absolutely meet the requirement, but be exorbitantly expensive for the lower BW requirement here.

Use case is monitoring and verifying power rail ramp up/down behavior on a complex board that may have 10-20 different rails, each with requirements for ramp rate, on/off ordering, etc.

azonenberg, 4 months ago to random

I'm working on firmware for an embedded device that should be fully deterministic and static memory allocations only (i.e. no dynamic memory allocation).

Is there a reasonable way (using arm-none-eabi-g++, newlib, and GNU ld in particular) to ensure that malloc is never called or even linked into the binary?

In particular, I'm looking to ensure I don't accidentally call any newlib functions like printf that might call malloc under the hood. I've avoided the obvious ones but I'd like an automated check to make sure I don't do any dynamic allocations by accident or in weird corner cases.

Also, does anyone know of good f/oss static analysis tools that can 1) detect if recursion is possible in a given C++ codebase and 2) assuming no recursion, compute a static bound on worst case stack usage?