What is the main difference between RTL and HDL? To be honest I searched / googled it yet people are divided in their opinions. I remember one saying that HDL is the computer language used to describe a digital circuit and when it is synthesizable, then it is considered RTL.


2 Answers 2


HDL is the catch all name for all hardware definition languages (Verilog, VHDL, etc.) in the same way Object Oriented can refer to C++, Java, etc.

RTL on the other hand is a way of describing a circuit.

You write your RTL level code in an HDL language which then gets translated (by synthesis tools) to gate level description in the same HDL language or whatever your target device/process will take.

Let me give you an example. Here is a line of Verilog (HDL) describing a mux in RTL:

assign mux_out = (sel) ? din_1 : din_0;

Your synthesis tool can take that and convert it to a set of logic gates, or just a mux macro that is supported by your end device. For example it might instantiate a mux macro

mux u3 (mux_out, din_1, din_0);

In both cases you can feed the same inputs to the block (RTL, or gate-level) and your output should be the same. In fact there are tools that check the output of your synthesis against your RTL code to make sure the tool didn't accidental optimize or change something during synthesis that caused a mismatch. This is called Formal Verification.

For a variety of reasons, interoperability, ease of change, understandability you write your description of the digital circuit as RTL, instead of gate-level.

  • 3
    \$\begingroup\$ Nice answer, just a further refinement ... RTL assumes a given design style - logic cloud, register, logic cloud , register etc. which implies synchronous (clocked) design. IF you were coding in your hdl for clockless (asyncronous) design your synthesis tool might use something other than RTL. \$\endgroup\$ Commented May 12, 2013 at 21:36
  • 1
    \$\begingroup\$ ,,In fact there are tools that check the output of your synthesis against your RTL code to make sure the tool didn't accidental optimize or change something during synthesis that caused a mismatch. This is called Formal Verification.'' No, this is not. This is called Logic Equivalence Checking or Formal Equivalence Checking. The Formal Verification is rather process of proving (using mathematical methods, without simulation/test benches) that your hardware description really describes the behavior it was intended to describe. \$\endgroup\$
    – Al Bundy
    Commented Apr 2, 2019 at 6:50

HDL (Hardware description Language) is the type of language used, Verilog/VHDL versus a non-HDL javascript.

RTL (Register-transfer level) is a level of abstraction that you are writing in. The three levels I refer to are Behavioural, RTL, Gate-level.

Behavioral has the highest layer of abstraction which describes the overall behavior and is often not synthesizable, but is useful for verification.

RTL describes the hardware you want by implying logic. defining flip-flops, latches and how data is transfered between them. This is synthesizable, synthesis may alter/optimize the logic used but not behavior. Switching muxes for gates etc some times inverting signals to better optimize the design.

Verilog RTL implying a flip-flop:

logic a;              //logic is SystemVerilog, could be a 'reg'
logic k;              // Driven by RTL not shown
always @(posedge clk or negede rst_n) begin
  if (~rst_n) begin
    a <= 'b0 ;
  else begin
    a <= k ;

Combinatorial Bitwise operators :

logic [1:0] n;
logic [1:0] m;
logic [1:0] result;

assign result = n & m ;

Gate level is a design using the base logic gates (NAND, NOR, AND, OR, MUX, FLIP-FLOP). It does not need to be synthesized or is the output from synthesis. This has the lowest level of abstraction. it is the logic gates that you will use on the chip, but it lacks positional information.

Gate level Verilog (same function as above):

wire a;
wire k;
DFFRX1 dffrx1_i0 (
  .Q (a),   //Output
  .QN( ),   //Inverted output not used
  .D (k),   //Input
  .CK(clk), //Clk
  .RN(rst_n)// Active Low Async Reset


wire [1:0] n;
wire [1:0] m;
wire [1:0] result;

AND2X1 and2x1_i0 (
  .Y( result[0]),
  .A( n[0]     ),
  .B( m[0]     )
AND2X1 and2x1_i1 (
  .Y( result[1]),
  .A( n[1]     ),
  .B( m[1]     )
  • 1
    \$\begingroup\$ RTL, gate level would look like AND(.a(),.b()) OR(.a(),.b()) purely logic gates being hooked up. I am under the impression that RTL is anything you intend to synthesise, even combinatorial circuits as you are still describing the change in data, but not the logic gates directly. \$\endgroup\$ Commented May 14, 2013 at 20:41
  • 1
    \$\begingroup\$ You included "flip-flop" in your list of base logic gates; since they are a primitive in some topologies, I figured that might be intentional. Writing a behavioral spec for things which combine asynchronous and synchronous behavior seems harder than specifying the behavior in terms of flip flop inputs, clocks, async-preset, and async-reset pins. \$\endgroup\$
    – supercat
    Commented May 14, 2013 at 20:50
  • 1
    \$\begingroup\$ Sorry I do not follow, Will try to clarify. RTL implies a flip-flop. Gate-level instantiates a flip-flop. For simple circuits then hooking up a bunch of logic gates might be simple. but may not be power area efficient. An Atom Processor has 47 million transistors which is around 10 million NAND2 equivalents. Would you want to define and debug 10 million hand wired gates ? This is the advantage of abstracting a little bit we can study and debug the intended behaviour. \$\endgroup\$ Commented May 15, 2013 at 7:38
  • 1
    \$\begingroup\$ Certainly for parts of a circuit higher-level descriptions are helpful. On the other hand, it would seem that trying to specify the behavior of a flip flop with asynchronous set/clear inputs would be more complicated and less intuitive than simply saying "use one". Perhaps a more detailed behavioral description would be helpful on hardware that doesn't have such a primitive, since there are different ways one might try to mimic the primitive on hardware that lacks it; the methods have different costs and slightly different behaviors. \$\endgroup\$
    – supercat
    Commented May 15, 2013 at 15:05
  • 1
    \$\begingroup\$ Suppose one were trying to specify a 74HC74 in an HDL. There are a variety of ways one could synthesize such a device using a combination of combinatorial logic, synch-only flops, and transparent latches, but I can't figure any implementation which doesn't either involve race conditions or create behavioral anomalies which would not exist with hardware primitives (e.g. if D and Q are high, a runt pulse on CP or /SD should have no effect, but in the implementations I can figure such pulses could cause metastability and/or an output glitch). \$\endgroup\$
    – supercat
    Commented May 15, 2013 at 15:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.