We are accustomed to seeing RISC-V implementations in Verilog or VHDL, but [Low Level JavaScript] has one in TypeScript. Before you dismiss it as a mere emulator, know that the project relies on gateware-ts, a conversion between TypeScript and Verilog. From there, you can actually put the CPU on an FPGA. You can see the launch video below and there is one development video as well as, presumably, more to come.
We aren’t sure if many FPGA designers will be willing to switch to TypeScript. But if you are comfortable with it, it might open up FPGA development without having to learn as much of a new language.
A recent trend has been to convert high-level constructs into FPGA code like Verilog or VHDL. Silice goes the other way: it converts very hardware-specific concepts to Verilog and aims to be a more expressive and easier to use language.
Why Silice? The project’s web page enumerates its design goals:
A clean, simple syntax that clearly exposes the flow of operations and where clock cycles are spent.
Precise rules regarding flow control (loops, calls) and their clock cycle consumption.
Familiar hardware constructs such as always blocks, instantiation, expression tracking (wires).
An optional flow-control oriented design style (automatic FSM generation), that naturally integrates within a design: while, break, subroutines.
The possibility to easily describe pipelines.
Automatically takes care of creating flip-flops for variables, with automatic pruning (e.g. const or bindings).
Generic interfaces and grouped IOs for easy reuse and modular designs.
Generic circuits that can be instantiated and reused easily.
Explicit clock domains and reset signals.
Familiar syntax with both C and Verilog inspired elements.
Inter-operates with Verilog, allowing to import and reuse existing modules.
Digital filters are always an interesting topic, and they are especially attractive with FPGAs. [Pabolo] has been working with them in a series of blog posts. The latest covers an 8th order FIR filter in Verilog. He covers some math, which you can find in many places, but he also shows how an implementation maps to DSP slices in a device. Then to reduce the number of slices, he illustrates folding which trades delay time for slice usage.
Folding takes a multi-stage parallel multiplication and breaks it into fewer multiplications done over a longer period of time. This reuses slices to reduce the number required for high-order filters.
We were always envious of Star Trek, for its computers. No programming needed. Just tell the computer what you want and it does it. Of course, HAL-9000 had the same interface and that didn’t work out so well. Some researchers at NYU have taken a natural language machine learning system — GPT-2 — and taught it to generate Verilog code for use in FPGA systems. Ironically, they called it DAVE (Deriving Automatically Verilog from English). Sounds great, but we have to wonder if it is more than a parlor trick. You can try it yourself if you like.
For example, DAVE can take input like “Given inputs a and b, take the nor of these and return the result in c.” Fine. A more complex example from the paper isn’t quite so easy to puzzle out:
Write a 6-bit register ‘ar’ with input
defined as ‘gv’ modulo ‘lj’, enable ‘q’, synchronous
reset ‘r’ defined as ‘yxo’ greater than or equal to ‘m’,
and clock ‘p’. A vault door has three active-low secret
switch pressed sensors ‘et’, ‘lz’, ‘l’. Write combinatorial
logic for a active-high lock ‘s’ which opens when all of
the switches are pressed. Write a 6-bit register ‘w’ with
input ‘se’ and ‘md’, enable ‘mmx’, synchronous reset
‘nc’ defined as ‘tfs’ greater than ‘w’, and clock ‘xx’.
For most people, adding WiFi to a project means grabbing something like an ESP8266 or an ESP32. But if you are developing your own design on an FPGA, that means adding another package. If you are targeting Linux, the OpenWifi project has a good start at providing WiFi in Verilog. There are examples for many development boards and advice for porting to your own target on GitHub. You can also see one of the developers, [Xianjun Jiao], demonstrate the whole thing in the video below.
The demo uses a Xilinx Zynq, so the Linux backend runs on the Arm processor that is on the same chip as the FPGA doing the software-defined radio. We’ll warn you that this project is not for the faint of heart. If you want to understand the code, you’ll have to dig into a lot of WiFi trivia.
There’s a lot of argument over which was the first modern computer to be built. There’s room for debate, but EDSAC — the work of Dr. Maurice Wilkes — certainly was among the first. While we’ve seen simulators before, [hrvach’s] FPGA-based simulator for the MiSTer platform has a lot going for it. Check out the video, below.
So much of what we take for granted today was first developed on the EDSAC. For example, the “Wheeler jump” (named after graduate student David Wheeler) was the origin of the idea of a subroutine.
After trying out hardware hacking using an FPGA to interface with target hardware, [Grazfather] was inspired to try using the iCEBreaker (one of the many hobbyist FPGAs to have recently flooded the market) to build a UART-controllable glitcher for the Olimex LPC-P1343.
FPGA Modules (The cmd module intercepts what the host computer sends over UART, the resetter holds the reset line until the target is reset, the delay starts counting on reset and waits for a configured number of cycles before sending its signal, the trigger waits for the delay to finish before telling the pulse module to send a pulse, and the pulse works similar to the delay module and outputs to the power multiplexer.)
When the target board boots up, the bootROM reads the flash and determines whether the UART goes to a shell and if the shell can be used to read out the flash. This is meant for developing firmware and debugging it in the bootloader, only flashing a version when the firmware is production-ready. The vulnerability is that only a specific value read from address 0x2FC and the state of a few pins can lock the bootloader in the expected way, and any other value at the address causes the bootROM to consider the device unlocked. Essentially, the mechanism is the opposite of how a lock ought to work.
The goal is to get the CPU to misread the flash at the precise moment it is meant to be reading the specific value, then jumping to the bootloader in the unlocked state. The FPGA can be used as a tool between the host machine and target board, communicating via UART. The FGPA can support configuring the delay between resetting the target board and pulsing a ‘glitch voltage’, as well as resetting the target board and activating the glitch. The primary reasons for using the FPGA over a different microcontroller are that the FPGA allows for precise timing (83.3ns precision) and removes worries about jitters (a Raspberry Pi might have side effects from OS scheduling and other processes and microcontrollers might have interrupts messing up the timing).
The logic analyzer view
To simulate the various modules, [Grazfather] used Icarus Verilog as well as GTKWave to observe the waveforms generated. A separate logic analyzer observes the effects on real hardware.
With enough time, it is possible to brute force any combination of delay and width until you get a dump of the flash you’re not meant to read. You can check out how the width of the pulse gets wider until the max, when the delay is incremented and the width values are tried again.
