FPGA Design Workflow: From Synthesis to Device Programming

Hello, and welcome to the first lesson. This opening module establishes the practical open-source workflow you will use throughout the course on the iCEBreaker: starting with RTL, turning it into a physical configuration for an iCE40 FPGA, then programming and observing real hardware.

For this lesson, the goal is not to memorize commands yet. Instead, build a reliable mental model of what each stage proves, what it produces, and what it cannot guarantee. That distinction makes later build logs and failures much easier to diagnose.

By the end, you should be able to explain the roles of synthesis, place-and-route, static timing analysis, bitstream generation, and device programming in one coherent workflow.

---

The central idea: RTL is a specification, not FPGA configuration

A SystemVerilog or Verilog module describes intended digital behavior: registers update on clock edges, combinational logic calculates values, and ports interact with the outside world. It does not say which physical lookup table implements an expression, where that lookup table sits in the FPGA, or which programmable wires connect it to its neighbours.

An FPGA has a fixed physical fabric consisting of:

• configurable logic cells, including LUTs and flip-flops;
• dedicated hardware such as block RAM or carry chains;
• I/O cells connected to package pins;
• a large grid of programmable routing resources.

The toolchain must translate your abstract RTL into settings for all of those physical resources.

This is the useful high-level sequence:

1. Synthesis converts RTL into a technology-mapped logical design.
2. Place-and-route assigns that design to actual FPGA resources and programmable wires.
3. Static timing analysis checks whether the routed design can meet its clocking requirements.
4. Bitstream generation encodes the final physical configuration into a device-specific file.
5. Device programming transfers that configuration to the FPGA or its configuration flash.

Each step consumes a more concrete representation of the design than the one before it.

---

1. Synthesis: RTL becomes FPGA-oriented logic

Synthesis takes your HDL source and determines a network of hardware primitives that realizes its behavior. In this course’s open-source flow, Yosys performs synthesis.

For example, consider this conceptual RTL:

always_ff @(posedge clk) begin
    if (enable)
        count <= count + 1'b1;
end

Synthesis recognizes the essential hardware structure:

• a bank of flip-flops holding count;
• an adder that computes the next count;
• selection logic that either retains the old value or loads the incremented value;
• a clock connection to the flip-flops.

It also performs optimizations. If part of the expression is constant, unused, or logically redundant, Yosys may remove or simplify it. Synthesis is therefore not a line-by-line “compilation” of HDL. It preserves the intended hardware behavior while choosing an efficient logical implementation.

For an iCE40 target, synthesis maps the design toward resources the device actually offers: LUTs, flip-flops, RAM blocks, I/O cells, and particular forms of arithmetic support. Its output is typically a technology-mapped netlist, often represented as JSON for the nextpnr flow.

What a successful synthesis run tells you

It tells you that, at least from the tool’s perspective:

• the RTL parsed and elaborated;
• the requested top-level module was found;
• the logic could be mapped to available types of FPGA resources;
• obvious issues, such as an undriven signal or unsupported construct, may have been reported.

It does not tell you:

• whether ports are assigned to the right physical pins;
• whether the logic fits into the selected chip;
• whether the routed design meets a clock frequency;
• whether the programmed board behaves as intended.

A synthesis warning deserves attention even when the build continues. A warning that an output is driven by a constant, for example, might be expected for an intentionally unused LED; it might also reveal that control logic was optimized away.

---

2. Place-and-route: logic becomes a physical circuit

After synthesis, your design is a collection of logical cells and nets. It is not yet a realizable layout on a particular FPGA part.

Place-and-route, often abbreviated PnR, is the stage that turns the logical design into a physical one. In the iCE40 flow, this is handled by nextpnr-ice40.

The backend diagram below provides a useful conceptual view. The left side contains reusable workflow functions such as placement, routing, and timing analysis. The right side contains architecture-specific knowledge: the iCE40 device database tells the tools which resources exist, how they connect, and what delays they have.

Packing

Before placement, the tool may perform packing: grouping synthesized logical elements into the physical structures offered by the device.

An FPGA logic tile is not simply an unlimited collection of independent gates. It has specific internal structures and rules. For example, a physical logic cell may combine a LUT with a flip-flop in certain permitted ways. Packing makes the netlist conform to these architecture-level rules.

A useful principle is:

Synthesis decides what logical resources are needed. Packing and placement decide how those resources can legally inhabit this FPGA.

Placement

Placement assigns every logical cell to a legal physical location.

A LUT is assigned to a particular logic cell. A RAM inference is assigned to a particular block-RAM site. A top-level output is associated with an I/O cell that is connected to the requested package pin.

Placement affects performance. Two cells that communicate frequently should usually be physically close, especially if their connection is timing-critical. But the placer must also obey many constraints: no two cells can occupy the same location, specialized blocks have limited locations, and I/O must match the board’s wiring.

Routing

Routing selects the actual programmable connections between placed resources.

The iCE40 fabric contains fixed wire segments and programmable interconnect points (PIPs). Configuring a PIP selectively connects wire segments. Routing must find legal paths for every net without creating conflicts with other nets.

A physical net is not just a logical statement such as “connect counter[0] to this adder input.” It becomes a particular sequence of metal segments and programmable switches inside the FPGA. That path has real delay, capacitance, and fan-out implications.

This is why two builds of logically identical RTL can have different timing results after a small unrelated change: a change can alter placement and routing choices across the design.

---

3. Static timing analysis: can the physical design run reliably?

A synchronous circuit only works if each register receives stable input data before its next active clock edge.

For a register-to-register path, the main timing budget includes:

• clock-to-output delay from the launching flip-flop;
• combinational logic delay through LUTs, carry logic, and other cells;
• routing delay through the FPGA fabric;
• setup time required by the receiving flip-flop.

A simplified setup-time condition is:

$$T_{\text{clock}}\ge t_{\text{clock to Q}}+t_{\text{logic}}+t_{\text{route}}+t_{\text{setup}}$$

Real timing analysis also considers clock uncertainty, skew, and device-specific timing models. The central idea remains the same: data launched at one clock edge must arrive sufficiently early for capture at the next edge.

Suppose a path has:

• $t_{\text{clock to Q}}=0.8\text{ ns}$
• logic plus routing delay of $12.0\text{ ns}$
• $t_{\text{setup}}=1.2\text{ ns}$

For a $20\text{ ns}$ clock period, corresponding to $50\text{ MHz}$, the setup slack is:

$$\text{slack}=20.0\text{ ns}-(0.8\text{ ns}+12.0\text{ ns}+1.2\text{ ns})=6.0\text{ ns}$$

Positive slack means the path meets that requirement, with margin. Negative slack means it misses the deadline. A timing failure may appear to work on a particular board at room temperature, but it is not a reliable design: device variation, voltage, temperature, or a later routing change can make it fail.

Why it is called static

Static timing analysis (STA) examines timing paths using timing models. Unlike simulation, it does not require you to provide input test vectors or run the design over time. It asks a structural question:

Given the implemented hardware and declared timing requirements, what is the slowest possible timing path?

This makes STA complementary to simulation:

Method	Primary question answered	Depends on chosen stimulus?
Simulation	Does the RTL behave correctly in the scenarios tested?	Yes
Static timing analysis	Can registered paths meet declared timing requirements?	No
Hardware test	Does this programmed board exhibit the expected observable behavior?	Yes, and only for what you observe

None replaces the others.

For the iCE40 open-source ecosystem, timing analysis may be integrated into the implementation flow and reported by nextpnr, or performed with an associated tool such as icetime. The exact tool boundary matters less than the discipline: define the clocks and interfaces correctly, then read the timing report rather than assuming a successful bitstream is fast enough.

---

4. Bitstream generation: encode the physical configuration

Once the design is placed, routed, and accepted for the intended timing requirements, the final physical configuration must be encoded for the target device.

This is the job of bitstream generation.

For the Project IceStorm flow, nextpnr commonly produces an ASCII configuration representation, often with an .asc extension. icepack converts that representation into a binary configuration image, commonly with a .bin extension.

The bitstream contains device-specific configuration bits that determine, among other things:

• LUT truth tables;
• whether and how flip-flops are used;
• the state of routing PIPs;
• I/O configuration;
• configuration of supported dedicated resources.

A bitstream is therefore not a generic executable file. It is a configuration image for a particular FPGA architecture and usually a particular device family and package. A bitstream built for an iCE40 device cannot be programmed into an unrelated FPGA family.

This is also why the device database is so important. The place-and-route and bitstream-generation stages must know the exact resources and configuration encoding of the target FPGA.

---

5. Device programming: make the board use the bitstream

Device programming transfers the bitstream to hardware.

For iCE40 development boards, there are commonly two closely related possibilities:

• configure the FPGA’s volatile configuration memory for the current powered session;
• write the bitstream to external SPI flash so the FPGA loads it automatically at power-up.

The iCEBreaker includes an iCE40 FPGA and board-level configuration hardware. In the practical build lesson, you will use iceprog to program the appropriate target and verify the result on the board. The exact programming option affects persistence: a configuration loaded only into volatile FPGA memory disappears when power is removed, whereas a configuration stored in flash can be reloaded on boot.

A successful programming message means the host-to-board transfer completed. It is important evidence, but it is not full functional verification. A programmed board might still be wrong because of:

• an incorrect pin assignment;
• active-low LED or button wiring misunderstood in RTL;
• an incorrect clock frequency assumption;
• a timing failure;
• a logic bug that simulation did not expose.

That is why practical FPGA work uses a chain of evidence: simulation, reports, programming confirmation, and observable board behavior.

---

Reading build results as a diagnostic boundary

When a build fails, locate the first stage that fails. This simple habit prevents wasted debugging.

Stage	Typical question	Common failure category
Synthesis	Can the RTL be elaborated and mapped logically?	syntax error, missing module, unsupported construct, invalid parameters
Place-and-route	Can this specific FPGA legally host and connect the design?	incorrect device, resource overflow, invalid pin constraint, unroutable design
Static timing analysis	Can the implemented design meet its timing requirements?	missing clock definition, unconstrained paths, negative slack
Bitstream generation	Can the routed configuration be encoded for this device?	incompatible target or malformed implementation output
Programming	Can the host transfer the image to the board?	cable, permissions, board selection, power, programmer connection
Board test	Does the actual system behave as intended?	wiring polarity, functional RTL error, timing issue, external electrical issue

One practical rule is worth carrying into every future lesson:

A build is not complete merely because it produced a .bin file. It is complete when the design has passed the relevant checks for logic, constraints, timing, programming, and observed behavior.

---

Key takeaways

• Synthesis transforms RTL into an FPGA-oriented logical netlist; in this course, Yosys performs that role.
• Place-and-route maps that netlist onto real FPGA resources and routing; nextpnr performs this architecture-specific implementation work.
• Static timing analysis uses physical delays and timing requirements to determine whether register-to-register paths meet deadlines. It is not simulation.
• Bitstream generation converts the implemented device configuration into a binary image; icepack is the key iCE40 utility here.
• Device programming transfers that image to the FPGA or its configuration flash; iceprog provides this connection to the physical board.
• A failure’s location in the workflow is a powerful first clue about its cause.

Next, you will move from this mental model to a concrete minimal iCEBreaker project: invoke Yosys, nextpnr-ice40, icepack, and iceprog, then observe a known design on real hardware.