luna

RF) implements a full USB stack including USB3 support, with enough abstraction that you can create a USB-serial converter inside your FPGA using two I/Os for full-speed USB and wire it into the rest of your project in about ten lines of Python[1]. [0]: https://github.com/greatscottgadgets/luna [1]: https://github.com/greatscottgadgets/luna/blob/master/exampl... Migen, the Python-based project nMigen is based off, has been around for longer and has some large projects, such as LiteX[2] which uses Migen to glue together entire SoCs, including peripheral cores such as GigE, DDR3/4, SATA, PCIe, etc, all written in Migen, and is pretty widely used. It also pulls in Verilog/VHDL designs (such as many of its CPU core choices) since it's easy to pull in those from the Python side. [2]: https://github.com/enjoy-digital/litex/

eems unlikely. 2. Open-source firmware or gateware implementation of a USB PD controller that supports entering/exiting alternate modes properly. Inspired by Kate Temkin's LUNA project [1]. I got the impression that PD was out of scope for LUNA, at least for the time being, but it would be really nice to have both a USB and PD stack that could be integrated onto a small, inexpensive chip without the proprietary mess. The motivation for this was wanting to design a split keyboard with a USB Type-C cable connecting the two halves instead of the usual TRRS cable, and discovering that USB alternate modes are a horror show. [1] https://github.com/greatscottgadgets/luna 3. Wi-Fi from scratch. This would essentially be a book (like Linux From Scratch) where you incrementally design the hardware needed to speak Wi-Fi, culminating in something that looks like Computer <-> Linux driver <-> FPGA <-> IQ modulator <-> antenna, allowing you to talk over 802.11g at one of the lower speed coding rates (BPSK or QPSK). 4. Firewalled IoT Hub. A Raspberry Pi that hosts an Wi-Fi AP for untrusted IoT devices. By default, clients on this AP can't see each other and can't access the Internet. The hub hosts a web interface on the primary network that allows you to send commands to your IoT devices, manage firmware updates, control network access rules, etc. 5. Discrete RISC-V CPU on a dinner-plate sized PCB, dressed up to look like a silicon die. Essentially Robert Baruch's LMARV-1 [2] in Monster6502 [3] form-factor. It would be neat to be able to design the CPU in an HDL and then use a yosys backend that can synthesize it as a netlist of either discrete transistors or 7400-style logic. After seeing Robert's design progress, this is starting to seem infeasible, but Olof Kindgren's SERV core is pretty tiny and might just fit. Other people have already discussed doing something like this [4]. [2] https://github.com/RobertBaruch/riscv-reboot [3] https://monster6502.com/ [4] https://twitter.com/BruceHoult/status/1310747415075459073 6. Low power Linux + Wi-Fi SoM. There's a power consumption gulf between microcontroller and application processor based embedded systems, and no good options if you want to add Wi-Fi to a project, don't want to consume a lot of power, and want a battle-hardened networking stack. I think a good solution to this problem might be to use a low-power application processor (like a Cortex-A7) and build a Linux system for it that is aggressive about sleep states and using DMA to transfer data from other parts of the system while the processor is asleep. The system would basically only wake up for mandatory housekeeping and to fire off network bursts. Like a Raspberry Pi, but instead of the default system image giving you a desktop, it'd give you a super minimal system that lends itself to running a single program with a standard, easy way to configure when to sleep/wake, what to buffer up while asleep, and when to trigger network events.