The blocks

IOBs (input/output blocks) sit behind each physical pin and form a ring around the edge of the chip. They set the pin's direction, drive strength, slew rate and voltage standard, and each one has its own flip-flops, so a signal can be latched right at the pin. Drive strength isn't voltage, though. A 3.3 V pin driving a 5 V part like a WS2812 LED strip still needs a level shifter.

CLBs (configurable logic blocks) are where the logic happens, and there are no AND or OR gates in them as such. A LUT is a tiny truth table that stores the output for every input combination, so one LUT4 can implement any boolean function of four inputs. Next to the LUTs are D flip-flops for state and a carry chain that lets adders ripple between neighbouring cells without going out to the slower general routing.

All of that configuration lives in SRAM, which forgets everything when the power goes off. The compiled bitstream is kept in flash and loaded into the SRAM at power-up. The Tang Nano 9K's Gowin GW1NR-9 has the flash built in, so a design is running almost as soon as the board gets power.

What a blinker turns into

module led_blink (
    input  wire clk,
    output reg  led
);
    reg [23:0] counter = 0;

    always @(posedge clk) begin
        counter <= counter + 1'b1;
        led     <= counter[23];
    end
endmodule

When the tools synthesize this, counter becomes 24 flip-flops, the + 1'b1 becomes LUTs plus the carry chain, and led is a register driving a pin, so it can go in that pin's IOB flip-flop. Which pin, and at what voltage, comes from a separate constraints file.

The post also lists the GW1NR-9's resources (8,640 LUT4s, 6,480 flip-flops, 26 block RAMs and 10 DSP multipliers), links the two Gowin documents I used, and looks at what has changed since that EEVblog video came out in 2013: power, $15 to $20 boards, free and open-source tools such as Yosys and nextpnr, and hard IP in the silicon.

https://edu.parthsinha.com/posts/understanding-fpga/

I later used the same board to build a small RISC-V computer, written up as a five-part series starting here: https://edu.parthsinha.com/posts/riscv-soc-1-toolchain-and-blink/

If you came to FPGAs from microcontrollers, what took you longest to unlearn?

The five parts

• Part 1: an open-source toolchain and a blinking counter. What synthesis, place and route, bitstreams and constraint files are, then a six-line counter that drives six LEDs. It uses 33 of the chip's 8,640 LUT4s.
• Part 2: a UART from scratch. Baud rates, mid-bit sampling and synchronizers, then a transmitter and receiver in about 40 lines of Verilog, tested in simulation first and then echoing typed characters on the board.
• Part 3: a PicoRV32 CPU running C. RV32IMC, memory-mapped I/O and linker scripts. The firmware is baked into the bitstream, so there's no bootloader. CPU, RAM and UART together take 47% of the LUTs and close timing at 51 MHz against a 27 MHz clock.
• Part 4: a hardware accelerator, 46× faster than C. A memory-mapped xorshift32 block that runs one step per clock, plus a small shell with peek, poke and bench commands.
• Part 5: an HDMI text console. Pixel clocks, video timing and TMDS encoding, then a 90×30 text display that mirrors the shell. It scrolls by changing one register instead of copying the screen.

The 46× number

On the board, bench 1000 took 50,015 cycles in C and 1,066 cycles on the accelerator, with identical results. The accelerator itself does one step per clock, so about 66 of those cycles are the cost of talking to it over the bus. That also means a single step at a time would be slower in hardware than in software. The speedup only shows up when each call does enough work.

What's not done yet

Parts 1 to 4 run on the board. Part 5 passes its simulation tests and builds a bitstream, but I haven't connected it to a monitor yet, so how it looks on a real screen is still unknown.

Things that went wrong

Each part has the problems I hit along the way. A few of them: on Linux, ModemManager kept probing the board's serial port, so the shell received its own output back as typed commands. A testbench passed even though the design was broken, and I only found out by feeding it bad input on purpose. And the first HDMI bitstream failed to pack until I switched from true LVDS buffers to emulated ones.

The code is on GitHub, with one folder per part: https://github.com/sinhaparth5/tangnano9k-riscv-soc

If LUTs and flip-flops are new to you, start with my notes on what's inside an FPGA: https://edu.parthsinha.com/posts/understanding-fpga/

If you've put a soft CPU on a small FPGA, what did you add after the UART?

Why ordinary integer math doesn't work

AES needs two things from byte arithmetic. Every result has to be another byte (0x00 to 0xFF), and every nonzero byte needs a multiplicative inverse, because the S-box is built from inverses. Integers mod 256 give you the first but not the second. No even number has an inverse mod 256, since 2·x is always even and so never equals 1.

A field with 256 elements has both properties, and GF(2⁸) is that field.

What GF(2⁸) does with a byte

Each byte is read as a polynomial whose coefficients are its bits. 0x57 = 01010111 is x⁶ + x⁴ + x² + x + 1.

Addition works coefficient by coefficient mod 2, which is just XOR: 0xD1 + 0x15 = 0xC4, with no carries.

Multiplication is polynomial multiplication followed by reduction modulo the AES polynomial x⁸ + x⁴ + x³ + x + 1 (0x11B). This is where xtime comes from. Multiplying by x shifts left one bit, and if a bit falls off the top, x⁸ gets replaced by x⁴ + x³ + x + 1, which means XOR with 0x1B.

To multiply 0x57 by 0x83, you keep doubling 0x57 and XOR in the copies where 0x83 has a 1 bit:

So 0x57 · 0x83 = 0xC1. The two rows with ⊕ 0x11B are the reductions: the shift pushed a 1 into bit 8, and XORing with 0x11B clears it.

The post has this as an interactive widget. You type any two bytes, then play it or step through one bit at a time, and a bit strip shows each shift, each XOR with 0x11B and each update to the result.

The rest of the post builds groups and fields from scratch. It has GF(7) and GF(2³) tables you can check by hand, the 0x57 · 0x83 long division, extended Euclid for inverses (0x53⁻¹ = 0xCA), and a short Python gf_mul. Part 2 uses all of this to build AES-128 layer by layer and checks it against the FIPS 197 test vector.

Part 1, Galois fields: https://edu.parthsinha.com/posts/galois-fields-for-aes/

Part 2, AES layer by layer: https://edu.parthsinha.com/posts/aes-structure-and-layers/

When you learned AES, which took longer to click: MixColumns or the S-box?