I almost hesitate to say anything, but the constant scope creep (that he readily admits in the blog) is starting to feel like a real obstacle to getting anything done. It's fun to see all of the theorizing about 96-port switches with $11K of FPGAs, but it would be fantastic if something like the simple 4-port switch design could be spun out as an open source project that people could iterate on.
I've also been following his solder-in probe projects for years ( https://www.antikernel.net/products.html ). There was a small Kickstarter and some reviews, but now the one distributor has 404s on the product pages and there are a lot of "coming soon" labels attached to all the different products and variations. Again, it would be fantastic if just one of those projects was available in distribution semi-reliably.
(EDIT: clarification, the plan had been 96 ports total since at least 2015, since that's what I had in existing Cisco switching. The major scope creep over that time was deciding that 2x 48 port switches with a bigger FPGA would be a more power efficient, easier to build, and generally superior design to 4x 24 port)
All that's left hardware wise is to design the main logic board with the FPGA, processor, and SFPs, plus the mechanical and thermal design of the 1U chassis. I've been focusing on firmware due to the tariff situation and wasn't planning on spinning the production-ish hardware for quite a while.
I don't plan any further scope changes now that I've e.g. already put in the production line card PCB order and mostly finalized the fabric architecture. I'm just holding off on the final logic board design until I'm sure about, for example, whether I'll want external packet buffer SRAM like LATENTPINK had or if I'll be fine with the KU5P's internal memory resourecs.
As far as the probes go, yes the antikernel.net site is way out of date and I've been too busy to refresh it.
* The AKL-PT1 did a kickstarter and I shipped probes to backers, but I stopped selling them because the fixed tip/ground spacing was too awkward and made it difficult to use.
* The AKL-PT2 (first gen solder in probe) was for sale for a while but extremely fragile, only 4 GHz bandwidth, and also had fixed signal/ground spacing.
* A few in-between designs were total flops and never reached the point of shipping a single unit
* The AKL-PT5 (second gen solder in probe) is >16 GHz bandwidth and has a flexible resistor based solder-in tip and a much nicer form factor. R&D is done but I ran into supply chain problems with the specialized resistor it needs (9 month lead time, poor yield, etc). I think I've mostly worked around those issues and I have a PVT run of a hundred units in the pipeline now. Fingers crossed they'll be hitting Digikey in the next 6-12 months.
You can just get something like a Realtek single-chip switch IC and put it on a PCB. Low-port-count unmanaged switches are cheap commodity products already.
In low volume when you combine several custom multilayer boards, custom powder-coated sheet metal work, etc even if you allow for the practically-free recycled FPGA this is going to probably end up being a $5-10K project. The last custom one-off 1U I did from ProtoCase was like $800ish just for the enclosure, and that was before the recent tariff hikes.
> A line-rate, flexible, and open platform for research, and classroom experimentation. More than 3,500 NetFPGA systems have been deployed at over 300 institutions in over 60 countries around the world.
Of course I understand that having custom switch engine is far more satisfying to do.
Also, I explicitly do not want to run embedded Linux. I much prefer bare metal on the control plane (I ended up writing a bare metal sshd because I couldn't find one that supported no-malloc, no-OS operation)
And one of the architectural plans of this project is a completely separate control/data plane where the processor can't see fabric packets and has a physically separate management interface.
Re: initial specs for the (4 port) OpenWRT One, which is built on Banana Pi's, which supports U-boot: https://www.cnx-software.com/2024/01/12/openwrt-one-ap-24-xy... .. https://openwrt.org/toh/openwrt/one:
> The non-open-source components include the 2.5GbE PHY and WiFi firmware with blobs running on separate cores that are independent of the main SoC where OpenWrt is running. The DRAM calibration routines are closed-source binaries as well.
Software for FPGA switch, probe, and GHz oscilloscope projects?
/? inurl:awesome vivado https://www.google.com/search?q=inurl%3Aawesome+vivado :
awesome-hdl: https://github.com/drom/awesome-hdl :
sphinx-hwt:
d3-wave probably won't do GHz in realtime. https://github.com/Nic30/d3-wave
Pyqtgraph probably can't realtime plot GHz probe data without resampling either?
pyqtgraph: https://github.com/pyqtgraph/pyqtgraph
The hwtLib README says Vivado supports IP-XACT format.
hwtLib: https://github.com/Nic30/hwtLib :
> hwtLib is the library of hardware components writen using hwt library. Any component can be exported as Xilinx Vivado (IP-exact) or Quartus IPcore using IpPackager or as raw Verilog / VHDL / SystemC code and constraints by to_rtl() function. Target language is specified by keyword parameter serializer.
IP-XACT: https://en.wikipedia.org/wiki/IP-XACT
hwtlib docs > hwtLib.peripheral.ethernet package: https://hwtlib.readthedocs.io/en/latest/hwtLib.peripheral.et...
hwtLib.peripheral.uart package: https://hwtlib.readthedocs.io/en/latest/hwtLib.peripheral.ua...
It looks like there are CRC implementations in hwtlib. Which CRC or hash does U-boot use for firmware flashing? https://www.google.com/search?q=Which+CRC+or+hash+does+U-boo... ... Looks like CRC32 like .zip files but not .tar.gz files.
U-boot: https://github.com/u-boot/u-boot
OpenWRT docs > "Failsafe mode, factory reset, and recovery mode": https://openwrt.org/docs/guide-user/troubleshooting/failsafe...
Open vSwitch: https://en.wikipedia.org/wiki/Open_vSwitch :
> Open vSwitch can operate both as a software-based network switch running within a virtual machine (VM) hypervisor, and as the control stack for dedicated switching hardware; as a result, it has been ported to multiple virtualization platforms, switching chipsets, and networking hardware accelerators.[7]
"Porting Open vSwitch to New Software or Hardware": https://docs.openvswitch.org/en/latest/topics/porting/
awesome-open-source-hardware: https://github.com/aolofsson/awesome-opensource-hardware
awesome-open-hardware: https://github.com/delftopenhardware/awesome-open-hardware :
> Journal of Open Hardware (JOH), HardwareX Journal,
Must be nice to know enough to be sure that your sketchy hardware isn't backdoored. I cannot imagine buying random network hardware from a sketchy source. Though I'm sure that if I had the author's chops, I wouldn't be too worried.
More broadly, network hardware is where the keyest vulnerabilities are. Open source network hardware is interesting from that perspective. You do not want random bad actor open source contributors adding backdoors.
The STM32s have a small boot "ROM" burned into a write-protected region of flash but I have it jumpered so I boot from main user flash, not the bootloader.
I did a quick silicon overview of them (just out of curiosity... they came new from Digikey so I have no reason to believe they're fishy).
STM32H735: top metal only https://siliconpr0n.org/map/st/stm32h735/azonenberg_mz_mit20..., deeper dive planned but haven't had a chance
STM32L431: did a full teardown https://serd.es/2025/01/02/STM32L431-teardown.html
The 12-port PHYs are a fused-down version of a switch chip so there is a MIPS core on there, but to the best of my knowledge in the switch SKU it doesn't actually run (e.g. its RAM bus is NC and the IO power rail is grounded).
The FPGA is completely programmed from the bitstream I control. Tampering with a random resold FPGA to add some kind of backdoor is extraordinarily difficult and unlikely, it's the kind of thing you would see done as a targeted attack rather than just dumping FPGAs into the secondary market and hoping that a juicy intelligence target buys them rather than some guy tinkering around with open source projects.
And, if I ever get the slightest hint that there is something fishy about silicon I bought from a sketchy overseas source, I'm gonna take it into the lab at work and go to town. I do semiconductor reverse engineering at my day job and am the absolute last person anyone should try to sneak backdoored chips past. It's going to end up getting dissected inside a SEM and turn into an awesome talk at REcon or something.
While it would be slightly annoying to have my side projects disrupted, having a living breathing nation-state silicon backdoor show up in my lab would be a dream come true. I'd be ordering as many more chips as I could from the same seller and instrumenting it in every way possible, practicing on non-backdoored chips to make absolutely certain I didn't damage any of the spicy ones while studying the altered circuits, etc.
You'd either have to add an enormous amount of logic or have extremely detailed a priori knowledge of exactly what someone was going to use it for (down to what functions each pin was being used for). Making it meet the original factory performance and timing specs would be immensely difficult.
The best idea I had was that you could add some logic inside the transceiver IP that would understand common networking line codes and then bridge packets with certain magic header values over to an ICAP or something, so that you could enable an unauthenticated partial reconfig over IP channel.
But when you have lots of different line codes out there and don't know the bus width or configuration the user is going to have now suddenly you have to implement half a dozen different PCSes inside your fork of the GTY IP without changing the layout enough to fail timing or change the bump map enough to be visible to someone looking at the substrate or...
Small stuff like adding bypasses to bitstream encryption I could see, but nothing that would be a major risk to something like this.
purpleidea•4h ago
We need fewer proprietary interfaces for such an important part of networking.