# Difference between RTL and Behavioral verilog

Can someone tell me what is the difference between RTL and behavioral Verilog code? Is there any clear cut demarcation between designs at these two levels?

Behavioral code is higher-level and usually can't be synthesized. Constructs like loops, delays, and "initial" statements are behavioral.

RTL code is lower-level and is intended to be synthesized. It defines a circuit as a combination of interconnected registers and the operations performed on signals between those registers.

• loops can be used in rtl code provided the number of iterations is limited. Some tools also support the use of intital blocks to specify power up conditions. – Peter Green Dec 22 '15 at 0:35
• This question/ response was actually the first response Google gave me – Drewster Feb 5 '19 at 20:13

"Register transfer level" code is code described in terms of registers and combinatorial logic that sits between them and intended to be used as input to a synthesis tool. The code sticks to a synthesizable subset[1] of the language. There are no explicit delays, all timing is in terms of clock edges. Structures representing level triggered latches are generally avoided. Registers are typically clocked off a small number of clocks whose details can be given to the timing analyser. The combinatorial logic is usually expected[2] to settle within a single clock cycle which limits it's complexity. It's higher level than a gate level model but it still defines what value every register has on every clock cycle.

"behavioural" code is generally code that describes behviour at a higher level for use in a simulation but it not intended to be synthsizable. It may be used to describe the environment surrounding your design in a simulation. It may be used as an early step in a design to get the overall design in place before detailed RTL design of the individual modules is overtaken.

[1] The exact subset allowed varies between synthesis tools.
[2] If it doesn't settle within a single cycle than simulation and synthisis may give different results and the timing analyser will show a violation unless it's explicitly told not to.

A more generalized definition.

Behavioral Code: By definition it defines the behavior of a digital component. It does not give information how it will be implemented into actual HW (synthesis). It will not give information how registers and gates will be implemented to perform required operation. It is more like writing an algorithm or FSM in C.

RTL: It is more precise form of a digital component. It gives information, how code will be implemented as actual HW (after synthesis). Also it gives information how data will be transferred between registers and gates.

It's the same language, but different styles are used. With experience you can tell them apart quickly, here's a few traits of each:

Behavioural verilog code generally looks more like a sequential computer program running from top to bottom within an initial begin block. You may find there are no input/output ports defined in top level behavioural modules, since the output may be to simulator facilities, like the console $display() or filesystem with $open or waveform dumper with $dumpfile and $dumpvars. Watch for delays between statements implemented using long simulation time waits e.g. #4000 and invoking tasks wishbone_master.checked_read(addr, value). For these higher level constructs is it not obvious what the synthesised technology equivalent would/could be.

Verilog for synthesis always has input/output ports, as without connected ports the module has no side effects and can be eliminated [1]. Delays probably implemented by counting cycles of some particular clock. Note some Verilog system functions e.g. $clog2(PARAMETER) may be permitted in code for synthesis, so the presence of $function is not a guarantee either way. Code for synthesis tends to comprise many of independent 'processes' each with a sensitivity list. Some technologies do permit initial begin blocks for memory initialisation so again that is not a guarantee.

Ultimately the designer knows the purpose of the code they write and will appropriately invoke it with the synthesis toolset or in a simulator.

[1] except for certain IP blocks which may make back-door connections to internal chip facilities, e.g. JTAG