Register-Transfer Level (RTL) is an abstraction used in digital design that describes a circuit in terms of the flow of data between registers and the logic operations performed on that data between clock edges. RTL descriptions are the most common input to synthesis tools, which translate them into gate-level netlists targeting FPGAs or ASICs.
In practice
RTL is the dominant design entry method for non-trivial digital logic on FPGAs and ASICs, though HLS and IP-based flows are also used in some domains. Designers write RTL in Verilog or VHDL, describing registers (typically as clocked always/process blocks) and the combinational logic that feeds them. Synthesis tools such as Xilinx Vivado, Intel Quartus, and Synopsys Design Compiler interpret this description and map it onto the target technology's primitives — LUTs, flip-flops, carry chains, and hard blocks on FPGAs; standard cells in an ASIC flow.
A key discipline of RTL design is keeping combinational and sequential logic clearly separated. Mixing them carelessly — for example, inferring latches unintentionally by leaving signals unassigned in some branches of combinational logic — produces synthesis results that differ from simulation, a common source of bugs. The blog post "Inside the Spartan-6: Using LUTs to optimize circuits" illustrates how understanding the underlying FPGA fabric helps guide RTL decisions that map efficiently to hardware.
RTL sits between two other abstraction levels: behavioral description (which may not be synthesizable) and gate-level netlist (which is the output of synthesis). Writing at the RTL level means the designer is responsible for the register structure and pipeline stages, while leaving low-level gate mapping to the tool. For resource-constrained designs, understanding how RTL constructs map to hardware — as covered in "Use Microprogramming to Save Resources and Increase Functionality" and "Fit Sixteen (or more) Asynchronous Serial Receivers into the Area of a Standard UART Receiver" — is often necessary to meet area and timing goals.
RTL simulation is performed before synthesis to verify functional behavior. Because simulation runs on the RTL model rather than the gate netlist, it is faster and easier to debug, but it can miss timing-related issues such as metastability and hold violations that only appear after place-and-route. Post-synthesis and post-implementation (timing) simulation are available but tend to be used less frequently due to their longer runtime and higher simulation complexity, though practice varies by team and project phase.
Frequently asked
What makes a piece of HDL code 'RTL' as opposed to just 'behavioral'?
RTL code explicitly describes registers (clocked
flip-flops) and the
combinational logic between them in a way that
synthesis tools can directly map to hardware. Behavioral code may use constructs like delays (#10 in
Verilog), dynamic memory allocation, or high-level loops that simulators can execute but synthesizers cannot translate into gates. The line is somewhat tool-dependent, but as a practical rule: if your synthesis tool accepts it without warnings and produces the expected hardware, it is RTL.
Does writing RTL mean you are working at a low level of abstraction?
RTL is mid-level. It is higher than gate-level or transistor-level design, but lower than
high-level synthesis (HLS) where you might describe an algorithm in C/C++ and let the tool determine the register structure. Most production
FPGA and
ASIC designs are still written at the RTL level because it gives designers direct control over pipelining, resource sharing, and interface timing.
What is the relationship between RTL and a clock?
In most practical flows, RTL is written in a synchronous style: data moves between registers on clock edges, and the
combinational logic between registers must settle within one clock period to meet timing. Asynchronous RTL design is possible but significantly harder to synthesize correctly and to verify. Most
FPGA and
ASIC synthesis flows assume and enforce a synchronous, clocked structure.
Can RTL be simulated before being synthesized?
Yes. RTL
simulation is typically the first verification step. Tools such as ModelSim, Xcelium, VCS, and the free open-source simulator Icarus
Verilog can simulate RTL directly. This catches functional bugs quickly and cheaply. Timing issues that depend on actual gate delays require post-
synthesis or post-implementation simulation with back-annotated Standard Delay Format (SDF) files, which is a later and more expensive step.
Why do embedded software developers need to understand RTL?
Embedded developers who work with FPGAs — either as the sole designer or alongside an
HDL engineer — need to read and sometimes write RTL to implement peripherals, co-processors, or custom interfaces. Understanding RTL also helps when integrating soft-core processors (such as a
MicroBlaze or RISC-V core), configuring IP blocks, or diagnosing problems at the hardware-software boundary. Blog posts like 'StrangeCPU #2. Sliding Window Token Machines' and 'PC and SP for a small CPU' show how CPU microarchitecture concepts translate directly into RTL design decisions.
Differentiators vs similar concepts
RTL is often confused with
HDL (Hardware Description Language) itself. HDL is the language (
Verilog,
VHDL,
SystemVerilog); RTL is the abstraction level at which the HDL is written. You can write non-synthesizable behavioral HDL, gate-level HDL, or RTL-level HDL — all in the same language. Separately, RTL is sometimes contrasted with
HLS (High-Level
Synthesis), where an algorithm written in C/C++ is automatically scheduled into a pipelined RTL structure by a tool such as Vitis HLS or Catapult. HLS raises the abstraction above RTL but produces RTL as its output.
