Skip to content
julianspeith edited this page Aug 17, 2026 · 7 revisions

The UART example project is the most realistic of the small example netlists: a working serial interface core with a specification you already know. That makes it a good exercise circuit — you can check your reverse engineering results against what a UART is supposed to do.

Requirements

None. This project ships without scripts on purpose and is meant to be worked through with the GUI alone.

The circuit

The design (test_ext_uart) implements a UART core that receives 64 bit and then transmits the exact same 64 bit back. The circuit operates at 100 MHz, the baud rate is set to 9600, and a stop bit is used.

The netlist comprises 407 gates and 409 nets using HAL's example_library:

  • InputsCLK, UART_RX
  • OutputsUART_TX
  • Sequential logic — 258× FFR
  • Combinational logic — 73× LUT4, 20× LUT6, 16× LUT5, 15× LUT3, 14× LUT2, 5× LUT1

Two things stand out immediately, and both are typical for real designs: the circuit is dominated by flip-flops rather than combinational logic, and the netlist is completely flat — all 407 gates sit in the top_module with no hierarchy to guide you.

That ratio is a hint in itself. With a 100 MHz clock and a 9600 baud rate, roughly 10,400 clock cycles pass per transmitted bit, which means a large counter must be present somewhere. Together with a 64 bit shift register for the payload, the receive and transmit state machines, and their bit counters, most of those 258 flip-flops are accounted for before you have looked at a single gate.

Suggested approach

There is no guided script for this project — it is meant as practice. A reasonable path:

  1. Run dataflow analysis to group the 258 flip-flops into registers, and see whether the resulting register sizes match what you predicted above (a wide counter, a 64 bit payload register, a few small state and bit counters).
  2. Look at what drives each recovered register and what it feeds. The baud rate counter should be self-referencing and drive enable signals of other registers; the payload register should form a shift chain.
  3. Isolate the receive and transmit control logic into separate views and try to extract their state machines, as demonstrated in the FSM example.
  4. Simulate the design with a serial frame on UART_RX and confirm that it appears on UART_TX — and that your identified registers hold what you expect while it happens.

A full step-by-step tutorial for this project is still work in progress.

Where to go from here

  • Read up on the tools the approach above calls for: dataflow analysis for the shift registers and counters, Solve FSM for the control logic, and simulation for checking your conclusions against an actual transmission.
  • Try Toy Cipher if you would rather follow a guided script through the same two techniques before applying them here on your own.
  • Try Crypto Trojan once this one holds no surprises. It is the same kind of work at a realistic scale, on a design where you are looking for something that should not be there.

Clone this wiki locally