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
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.

- 777
- 3
- 7
-
3Nice 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. – placeholder May 12 '13 at 21:36
-
1,,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. – Al Bundy Apr 02 '19 at 06: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 ;
end
else begin
a <= k ;
end
end
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
);
Combinatorial
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] )
);

- 357
- 5
- 17

- 1,180
- 6
- 11
-
If one were to design a circuit as `MyReg[7..1] := MyReg[6..0]; MyReg[0] := SerInput; MyReg.Clk = SerClk; MyReg[7..0].AR = !InBus[7..0] & Load; MyReg[7..0].AP = InBus[7..0] & Load;` (an asynchronous parallel-load shift register which could be implemented on a Xilinx 9536 CPLD using blocks with async reset/preset) would that be considered RTL or gate-level? – supercat May 14 '13 at 17:01
-
1RTL, 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. – pre_randomize May 14 '13 at 20:41
-
1You 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. – supercat May 14 '13 at 20:50
-
1Sorry 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. – pre_randomize May 15 '13 at 07:38
-
1Certainly 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. – supercat May 15 '13 at 15:05
-
1Suppose 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). – supercat May 15 '13 at 15:20
-
@supercat I have not come across 74HC74 before I assume we are talking about a Dual (2-bit), Set, Reset, posedge clk flip-flop. Which part of it concerns you? set reset ? or the dual? From the diagrams I have seen the dual is just two 1 bit flip flops. If it is the set-reset it can be implied in rtl and the set-reset flip-flop primitive would be used at synthesis. Or I have missed you point? – pre_randomize May 17 '13 at 07:07
-
If one is using hardware whose flip flops do not have asynchronous set/reset capability, it's possible to synthesize such behavior, but I don't know of any way to synthesize such behavior without exploiting race conditions, which will respond correctly to all legitimately-timed input conditions that should cause it to change state, and will ignore (without output glitches or metastability) input transitions, regardless of timing, which should unambiguously not cause it to change state [e.g. illegitimately-timed clock pulses at times when D matches Q] – supercat May 17 '13 at 14:38
-
For example, if one had flops with async reset but not async set, one could use one flop to capture the state of D, some logic to capture whether "set" or "clear" was driven last, a flop to indicate whether "set" and/or "clear" have been driven since the last clock pulse, and a mux to select either the D latch or the set/clear latch. Such an approach would work correctly in the steady-state, but could have output glitches when switching between reporting D-flop or RS-latch data. Hazard avoidance logic on the output may help, but I don't know if it would fix everything. – supercat May 17 '13 at 14:46
-
I think we are talking about code portability aspect of RTL, but if you are trying to imply a set-reset-flip-flop when your base library does not have one and HOPING the synthesis tool can magic one up, then yes that will lead to problems. I would hope the synthesis tool would raise a warning about that. What RTL gives you is the ability to change libraries/Foundries re-synthesis and get the same functional design. – pre_randomize May 17 '13 at 15:07
-
It is actually quite rare for me to come across such requirements. Some low latency, low clock speed interfaces require one or two set-resets but I have never used more that, the other couple of thousand are normal D-Types. – pre_randomize May 17 '13 at 15:09
-
Returning to my original question, if part of one's device needs to behave like a flop with async set/reset (e.g. because it interacts with things in the outside world that expect such behavior), would specifying things in terms of "MyLatch.D gets this; MyLatch.clk gets this; MyLatch.AR gets this; etc." be considered a gate-level or register-transfer-level specification? Also, behaviorally, is there a way of specifying under what conditions the outputs of a circuit are allowed to glitch and under what conditions they must remain stable? – supercat May 17 '13 at 15:50
-
1How are you creating `MyLatch` is it an instantiated base cell or an implied latch. If you instantiate the gate it is gate level If you imply it, it is RTL. The gate level library will have timing associated with it for modelling race conditions/glitches etc. RTL simulations run with ideal components. – pre_randomize May 17 '13 at 21:55