FPGA Design Flow from Entry to Configuration

An FPGA design is built in stages that run in a fixed order, and each stage exists because the one before it cannot answer the question the next one asks. Code can be simulated but not placed; a netlist can be placed but not routed until the constraints are known; a routed design can be timed but only against the numbers that were declared at the start.

This article walks through an FPGA design flow from design entry to configuration, and points out where the flow touches the board rather than the silicon.

The Stages of an FPGA Design Flow

The flow begins with design entry, moves through functional simulation, synthesis, implementation and timing analysis, and ends with configuration of the physical device and debug on the board. The stages are not merely sequential: a failing timing analysis sends the design back to the constraints or to the code, and a board that misbehaves sends it back to the simulation.

Each stage produces a file that the next one consumes, and the reports produced along the way are what the designer actually reads. A flow that is run without reading the reports is a flow that discovers its problems in the lab, where the cost of a change is measured in days rather than minutes.

Design Entry: HDL Rather Than Schematics

Entry used to mean drawing a schematic of gates and registers, and the tools still support it. For anything beyond a small glue-logic design, the schematic becomes unmanageable, and the work moves to a hardware description language instead. Verilog and VHDL are both in wide use, and the choice between them is usually made by the team rather than by the design.

What matters at this stage is structure. A design split into modules that can be simulated and constrained independently will be far easier to bring up than one written as a single large block, and hierarchical names are what the constraints and the timing reports will refer to later.

Functional Simulation Before Synthesis

Functional simulation, sometimes called behavioural or pre-synthesis simulation, checks that the logic does what the specification says. It runs on the source code, uses a testbench to drive the inputs, and it is the cheapest place in the entire flow to find a mistake.

The limit of functional simulation is that it knows nothing about delay. A design can pass every test at this stage and still fail on hardware, because the simulation assumed that every signal arrived at the same instant. That gap is what the later timing analysis exists to close, and it is the reason the two are used together rather than as substitutes.

Synthesis: Turning Code into a Netlist

Synthesis translates the description into a netlist of gates, memories, registers and other primitives that the target device can implement, and it optimises that netlist against the constraints it has been given. The output is a description of logic rather than a description of placement, and the design at this point still has no location on the die.

The reports from this stage are worth reading for two things: resources, which tell you whether the design fits, and inferred structures, which tell you whether the tool built what you intended. A memory that was inferred as registers rather than as a block memory will still work, and it will consume a large part of the device. Comparing what the tool built with what the design intended is the whole point of reading the report.

Implementation: Map, Place and Route

Implementation is where the netlist is given a physical form. The design is translated and merged into a single design database, the logic is mapped onto the physical resources of the device, and those resources are assigned positions and connected by the routing fabric. Modern tools make these decisions under timing pressure rather than purely for area.

Because the tool is timing driven during this stage, the constraints supplied here are what steer the result, and incremental modes let a mostly working design be improved without discarding the previous placement. The final step of this stage extracts the delay information that the timing analysis will consume.

Static Timing Analysis and Constraints

Static timing analysis examines every path in the design against the required times and reports the ones that miss. It does not need a testbench, because it does not simulate behaviour; it calculates delay along paths and compares the total with the clock period, the setup requirement and the hold requirement at each endpoint. Where a path is reported as failing, the useful question is whether it is a genuine delay problem or a constraint that was never declared.

The analysis is only as good as the constraints. A clock that was never declared, a false path that was not identified, or an input delay that was guessed will all produce a result that is comfortable and wrong. Static timing analysis is usually described as the most important step in the flow, and what it actually tests is the accuracy of the constraints.

Configuration and Board-Level Debug

The last stage produces the configuration data that the device loads at power-up. How it is loaded is a board decision: from a serial flash device on the board, from a processor that writes it, or over a debug interface during development. The mode pins that select the source must be set correctly, and they are frequently the reason a board does not start.

Once the design runs, the debug tools provide the visibility that a logic analyser used to give, and they are the reason that a device with a few spare pins and a spare clock is easier to bring up than one with none. The board side of the same work is described in the notes on high-speed interfaces around an FPGA.

Designing the Board Around the Device

The flow above is a software process, but it depends on board decisions that are made much earlier. The configuration source, the debug interface and the reference clocks are all connections that have to exist before the first bitstream is loaded, and each of them occupies pins whose function is fixed by the device. The same pin-planning exercise appears on every processor-based board, as the notes on core board design for an application processor describe.

Power and decoupling belong to the same list. The device draws current in bursts that follow the switching activity of the design, and the decoupling network is what keeps the supply within specification during those bursts. A board that supports the fastest interfaces will also need the stack and the laminate to match, and the choice of stack-up is where that is settled, and the advantages a multilayer stack brings to high-speed nets apply to this class of board as much as to any other.

FAQ

Is functional simulation still necessary if timing analysis passes? Yes. Timing analysis proves that the paths are fast enough, not that the logic is correct. The two check different things and neither replaces the other.

What causes a design to pass simulation and fail in hardware? Most often an unconstrained path, a clock domain crossing that was not synchronised, or a reset that is released differently in the two cases.

How much device utilisation is reasonable? Enough headroom to route and to time the design without the tools struggling. A device filled to the last lookup table often cannot meet its timing no matter how the constraints are written.