Difference between Behavioral, RTL and gate Level - verilog

I'm trying to fully understand the differences between the abstraction levels of Verilog, I get what the description of each level says but I still can't get it on the play.
For this case, I will paste some Verilog codes and what I think about them:
The following code is in Behavioral Level.
always # (a or b or sel)
begin
y = 0;
if (sel == 0) begin
y = a;
end else begin
y = b;
end
end
This (just an example) is in Gate Level
module test(clk, ready, next, Q);
input clk, enable, next;
output Q;
\**SEQGEN** reg_1 (.clear(1'b0), .next_state(next), .clocked_on(clk), .Q(Q), .synch_enable(enable) );
endmodule
I don't know if this code is in RTL or Gate Level ( I expect that the always keyword make this RTL and not Gate Level )
module dff_from_nand();
wire Q,Q_BAR;
reg D,CLK;
nand U1 (X,D,CLK) ;
nand U2 (Y,X,CLK) ;
nand U3 (Q,Q_BAR,X);
nand U4 (Q_BAR,Q,Y);
// Testbench of above code
initial begin
$monitor("CLK = %b D = %b Q = %b Q_BAR = %b",CLK, D, Q, Q_BAR);
CLK = 0;
D = 0;
#3 D = 1;
#3 D = 0;
#3 $finish;
end
always #2 CLK = ~CLK;
endmodule
I already know that initial begin and end are not synthesizeable and just used for testing. Now I have 2 questions
Third (and second) code is RTL or Gate-Leve? What would be a good RTL code example? I found this RTL Code Example but is that really RTL? For me it looks like behavioral level.
What means Verilog netlist? Is it the same as gate level or it have a context base definition?
I'm confused because in some websites I don't know if they're saying 'this is a Verilog code that is using logic gates' or 'this is a Verilog code in gate-level'
I will be very happy if somebody who wants to explain more details about this topic :)

RTL : Register-Transfer-Level, an abstraction hardware functionality written with always blocks and assign statements that are synthesizable (can be translated into gate level). Pure RTL does not instantiate sub-modules. RTL could contain sub-modules to guide the synthesizer. Structural RTL (ofter still called RTL) is a module that contains other RTL modules. Example: FSM (Finite-State-Machine)
always #* begin
next_state = state;
if (count>0) next_count = count - 1;
case (state)
IDLE :
if(do_start) begin
next_state = START;
next_count = 2;
end
START :
if (do_wait) begin
next_count = count;
end
else if (count==0) begin
next_state = RUN;
next_count = count_from_input;
end
RUN :
if (do_stop) begin
next_state = IDLE;
end
if (do_wait) begin
next_count = count;
end
else if (count==0) begin
next_state = IDLE;
end
endcase
end
always #(posedge clk, negedge rst_n) begin
if (!rst_n) begin
count <= 0;
state <= IDLE;
end
else begin
count <= next_count;
state <= next_state;
end
end
Behavioral : Mimics the desired functionality of the hardware but not necessarily synthesizable. There is no strict rules as long as the code generates the desired behavior. Guideline is to keep it simple and readable. Behavioral are often used to represent analog block, place holder code (RTL/gates not ready), and testbench code. Example: clock generator, delay cells.
always begin
if (!clk_en && clk==1'b1) begin
wait (clk_en);
end
#5 clk = ~clk;
end
The key difference between RTL and Behavioral is the ability to synthesize. It is behavioral if you see # delay, wait statements, while loops, force/release statements, or hierarchical reference. Technically there are some rare excusable exceptions, but that is out of scope if this question.
Gate-Level (aka Structural) : Logic described by gates and modules only. No always blocks or assign statements. This is a representative of the real gates in the hardware.
Verilog Netlist is a collection of Verilog modules used in the design. It can be one or many files. It can be a mix of of RTL, Behavioral and Structural. Usually it is mostly Structural, especially for large designs.

Behavioral level.
RTL level (don't have to be gate level, but primitive level.
A mixed working module/testbench, all enclosed in a single module. Not the best approach to design with Verilog, but would be OK for a teaching example. In fact, this example is actually two modules:
The testbench, which can be considered behavioral, even if it uses RTL coding to instantiate the module that is going to be tested to the regs and wires that the testbench drives:
module testbench_dff;
wire Q,Q_BAR;
reg D,CLK;
// Instantiate the unit under test
dff_from_nand uut (.CLK(CLK), .D(D), .Q(Q), .Q_BAR(Q_BAR) );
// Testbench
initial begin
$monitor("CLK = %b D = %b Q = %b Q_BAR = %b",CLK, D, Q, Q_BAR);
CLK = 0;
D = 0;
#3 D = 1;
#3 D = 0;
#3 $finish;
end
always #2 CLK = ~CLK;
endmodule
The unit under test (UUT) being tested, which it's a module like this (which is clearly a RTL level -gate level actually- module):
module dff_from_nand (
input wire CLK,
input wire D,
output wire Q,
output wire Q_BAR
);
wire X,Y;
nand U1 (X,D,CLK) ;
nand U2 (Y,X,CLK) ;
nand U3 (Q,Q_BAR,X);
nand U4 (Q_BAR,Q,Y);
endmodule
It's my understanding that a RTL level module is a module in which logic equations are explicity given. Behavioral module has processes (in Verilog using always blocks, although logic equations can be used inside those blocks). Any non-trivial Verilog design will have both.

Related

Is this a true FSM?

I have a conceptual question about FSM's and whether or not the following code is a true FSM. This is for my own curiosity and understanding about the subject. When I wrote this code, I was under the impression that this was an FSM, but now I am not so sure. According to a lot of reading I have done, a TRUE FSM should only consist of a sequential state transition block, followed by either one or two combination blocks to calculate the next state and the output logic.
My current code synthesizes and works on my Basys3 board, so I understand there may be an argument for "if it ain't broke, don't fix it" but it's been bugging me for a while now that I may have an incorrect understanding about how to write an FSM in HDL.
I have tried at least 4 or 5 different ways to rewrite my code using the format mentioned above, but I can't seem to get it without inferring latches, mainly due to the use of a counter, and the fact that pckd_bcd needs to remember its previous value.
Could somebody please explain to me either why this algorithm isn't fit for a true FSM, why it is fit for a true FSM and where my misunderstanding is, or how to rewrite this into the format mentioned above.
module double_dabble #
(
parameter NUM_BITS = 8
)
(
input wire i_clk,
input wire i_rst,
input wire [NUM_BITS-1:0] i_binary,
output wire [15:0] o_pckd_bcd
);
localparam s_IDLE = 3'b000;
localparam s_SHIFT = 3'b001;
localparam s_CHECK = 3'b010;
localparam s_ADD = 3'b011;
localparam s_DONE = 3'b100;
reg [2:0] state;
reg [NUM_BITS-1:0] bin;
reg [3:0] count;
reg [15:0] pckd_bcd;
reg [NUM_BITS-1:0] input_reg;
reg [15:0] output_reg;
assign o_pckd_bcd = output_reg;
always #(posedge i_clk)
begin
if(i_rst)
begin
state <= s_IDLE;
bin <= 0;
count <= 0;
pckd_bcd <= 0;
output_reg <= 0;
input_reg <= 0;
end
else
begin
input_reg <= i_binary;
state <= s_IDLE;
// FSM
case(state)
s_IDLE :
begin
state <= s_IDLE;
bin <= 0;
count <= 0;
pckd_bcd <= 0;
if (input_reg!=i_binary)
begin
bin <= i_binary;
state <= s_SHIFT;
end
end
s_SHIFT :
begin
state <= s_CHECK;
bin <= bin<<1;
count <= count+1;
pckd_bcd <= pckd_bcd<<1;
pckd_bcd[0] <= bin[NUM_BITS-1];
end
s_CHECK :
begin
state <= s_ADD;
if(count>=NUM_BITS)
state <= s_DONE;
end
s_ADD :
begin
state <= s_SHIFT;
pckd_bcd[15:12] <= add_three(pckd_bcd[15:12]);
pckd_bcd[11:8] <= add_three(pckd_bcd[11:8]);
pckd_bcd[7:4] <= add_three(pckd_bcd[7:4]);
pckd_bcd[3:0] <= add_three(pckd_bcd[3:0]);
end
s_DONE :
begin
state <= s_IDLE;
output_reg <= pckd_bcd;
end
endcase
end
end
function [3:0] add_three;
input [3:0] bcd;
if (bcd > 4)
add_three = bcd +3;
else
add_three = bcd;
endfunction
endmodule
In general, your code looks like it implements an FSM. You have evidence that the design is working as desired on your board.
The coding style you have chosen (one always block) is a valid Verilog approach. Another common FSM coding style involves two always blocks: one sequential and one combinational. See here for an example. It is not mandatory for an FSM to use two always blocks in Verilog.
One thing that I do notice in your code is that you are making multiple nonblocking assignments to the state signal at the same time. That is unusual.
For example, right before the case statement, you have:
state <= s_IDLE;
Then, in the IDLE case-item, you have the same code:
state <= s_IDLE;
I recommend trying to clean that up by adding a default to the case statement. A default is also a good coding practice when you have some undefined states, as in your FSM. You have only defined 5 of the 8 possible states (state is a 3-bit register).
Another example of multiple nonblocking assignments is:
s_CHECK :
begin
state <= s_ADD;
if(count>=NUM_BITS)
state <= s_DONE;
end
That would be better coded as:
s_CHECK :
begin
state <= (count>=NUM_BITS) ? s_DONE : s_ADD;
end
Following recommended coding practices yields more predictable simulation and synthesis results.

I2S Transmitter Verilog Implementation not working

I am trying to implement the I2S Transmitter in verilog. The datasheet for it is at: https://www.sparkfun.com/datasheets/BreakoutBoards/I2SBUS.pdf
I wrote the code, but my SD line is delayed 1 clock cycle when i test it.
Can someone check my implementation?
module Transmiter(
input signed [23:0] DLeft, input signed [23:0] DRight, input WS, input CLK,
output reg SD
);
wire PL;
reg Q1,Q2;
reg [23:0] shift_reg;
reg [23:0] Tdata;
assign PL = Q1^Q2;
always #(posedge CLK)
begin
Q1 <= WS;
Q2 <= Q1;
end
always #( Q1) begin
if (Q1)
begin
Tdata <= DRight;
end
else
begin
Tdata <= DLeft;
end
end
always #(negedge CLK)
begin
if(PL)
begin
shift_reg <= Tdata;
end
else begin
SD <= shift_reg[23];
shift_reg <= {shift_reg[22:0],1'b0};
end
end
endmodule
EDIT: here is a image of waveform image
TEST BENCH CODE:
module Transmitter_tb(
);
reg CLK, WS;
reg [23:0] dataL;
reg [23:0] dataR;
wire SDout;
Transmiter UT(dataL, dataR, WS, CLK, SDout);
initial begin
dataL = 24'hF0F0FF; #2;
dataR = 24'h0000F0; #2;
end
always begin
CLK=0; #20;
CLK=1; #20;
end;
always begin
WS=0; #1000;
WS=1; #1000;
end;
endmodule
Your negedge block contains an if-else construct and will only ever compute one or the other on a single clock edge. SD will therefore not change value when PL is high.
Furthermore you are using non-blocking assignments(<=) in your code. This roughly means that changes won't be evaluated until the end of the always block. So even if SD <= shift_reg[23] after shift_reg <= Tdata it will not take on the new value in shift_reg[23] but use the previous value. If you want SD to change immediately when shift_reg[23] changes you need to do this combinatorically.
This should work:
always #(negedge CLK)
begin
if(PL)
begin
shift_reg <= Tdata;
end
else
shift_reg <= {shift_reg[22:0],1'b0};
end
assign SD = shift_reg[23];
Working example: https://www.edaplayground.com/x/4bPv
On a side note I am still not convinced that DRight and DLeft are in fact constants, I can see that they are in your TB but it doesn't make sense that the data for your I2S is constant. Your current construct will probably generate a latch(instead of a MUX), and we generally don't want those in our design.
You should clean up your use of blocking versus non-blocking statements:
Always use non-blocking assigments, meaning "<=", in clocked statements.
Always use blocking assigments, meaning "=", in combinational (non-clocked) statements.
This is a industry-wide recommendation, not a personal opinion. You can find this recommendation many places, see for instance:
http://web.mit.edu/6.111/www/f2007/handouts/L06.pdf
The sensitivtity list being incomplete (as pointed out by #Hida) may also cause issues.
Try to correct these two things, and see if it starts working more as expected.
Also note that you are using Q1 (among other signals) to generate your PL signal. If the WS input is not synchronous to your local clock (as I assume it is not), you need to put one more flop (i.e. two in series) before starting to use the output, to avoid metastability-issues. But you won't see this in an RTL simulation.

Module not properly instantiated?

I have an example code about T-Bird Tail Lights, and it's passing states to the next module. I modified the code that it doesn't have to pass the state, but it seems the output is not changing(stays 000 all the time)
Here's my modified code:
module TBird(E,B,L,R,int_clk,L_Light,R_Light);
input E,B,L,R,int_clk;
output [2:0] L_Light;
output [0:2] R_Light;
reg [19:0] C;
wire int_clk;
One_Side U1 (E,B,R,int_clk,R_Light);
One_Side U2 (E,B,L,int_clk,L_Light);
endmodule
module One_Side(e,b,t,clk,light_eb);
input e,b,t,clk;
output reg [2:0] light_eb=3'b000;
always #(posedge clk or e or b or t)
begin
case ({e,b,t})
3'b000: light_eb=3'b000;
3'b0?1: begin
if (light_eb==3'b000) begin
light_eb=3'b001;
end else if (light_eb==3'b001) begin
light_eb=3'b011;
end else if(light_eb==3'b011) begin
light_eb=3'b111;
end else begin
light_eb=3'b000;
end
end
3'b?10: light_eb=3'b111;
3'b10?: begin
if (light_eb!==(3'b000|3'b111)) begin
light_eb=3'b000;
end
light_eb=~light_eb;
end
3'b111: begin
if (light_eb==3'b000) begin
light_eb=3'b001;
end else if (light_eb==3'b001) begin
light_eb=3'b011;
end else if(light_eb==3'b011) begin
light_eb=3'b111;
end else begin
light_eb=3'b000;
end
end
endcase
end
endmodule
I have had some experience in Java, but I don't know much about verilog, so I don't even know where goes wrong(in Java, eclipse has break points and debugger and things like that,) any suggestions/recommendations are appreciated.
A couple of mistakes in the testbench and design. Listed down as follows:
You have not provided any toggling on clock signal. So there will not be any posedge of clock detected. There are many ways for generating clock, one of them is as follows:
always #5 clk = ~clk;
Using a reset signal in design is good practice. Apply reset from testbench to set all the internal registers in design to their initial values.
The most important thing is you have not provided any input stimulus to the design. Any random stimulus must be applied to get the output. You have to provide some inputs to get the output, henceforth your output is x.
initial
begin
forever
begin
#6;
E = $random;
B = $random;
R = $random; // and so on...
end
end
Use of nonblocking (<=) assignments in design is a good coding practice. Also, donot mix blocking (=) and nonblocking (<=) assignments.
a = b; // never use this in sequential circuit.
a<= b; // use this in sequential circuit.
I have made a somewhat valid testbench for your design, have a look at EDAPlayground link.
Must refer to this, this, and this links for understanding general testbench architecture.

Circuit behaves poorly in timing simulation but alright in behavioral - new to verilog

I'm new to verilog development and am having trouble seeing where I'm going wrong on a relatively simple counter and trigger output type design.
Here's the verilog code
Note the code returns the same result whether or not the reg is declared on the output_signal without the internal_output_buffer
`timescale 1ns / 1ps
module testcounter(
input wire clk,
input wire resetn,
input wire [31:0] num_to_count,
output reg [7:0] output_signal
);
reg [31:0] counter;
initial begin
output_signal = 0;
end
always#(negedge resetn) begin
counter = 0;
end
always#(posedge clk) begin
if (counter == num_to_count) begin
counter = 0;
if (output_signal == 0) begin
output_signal = 8'hff;
end
else begin
output_signal = 8'h00;
end
end
else begin
counter = counter + 1;
end
end
assign output_signal = internal_output_buffer;
endmodule
And the code is tested by
`timescale 1ns / 1ps
module testcounter_testbench(
);
reg clk;
reg resetn;
reg [31:0] num_to_count;
wire [7:0] output_signal;
initial begin
clk = 0;
forever #1 clk = ~clk;
end
initial begin
num_to_count = 20;
end
initial begin
#7 resetn = 1;
#35 resetn = 0;
end
testcounter A1(.clk(clk),.resetn(resetn),.num_to_count(num_to_count),.output_signal(output_signal));
endmodule
Behavioral simulation looks as I expected
But the timing simulation explodes
And for good measure: the actual probed execution blows up and looks like
Any tips would be appreciated. Thanks all.
The difference between the timing and functional simulations is that a timing simulation models the actual delay of logic gates while the functional simulation just checks if values are correct.
For e.g. if you have a simple combinational adder with two inputs a and b, and output c. A functional simulation will tell you that c=a+b. and c will change in the exact microsecond that a or b changes.
However, a timing simulation for the same circuit will only show you the result (a+b) on c after some time t, where t is the delay of the adder.
What is your platform? If you are using an FPGA it is very difficult to hit 500 MHz. Your clock statement:
forever #1 clk = ~clk;
shows that you toggle the clock every 1ns, meaning that your period is 2ns and your frequency is 500MHz.
The combinational delay through FPGA resources such as lookup tables, multiplexers and wire segments is probably more than 2ns. So your circuit violates timing constraints and gives wrong behaviour.
The first thing I would try is to use a much lower clock frequency, for example 100 MHz and test the circuit again. I expect it to produce the correct results.
forever #5 clk = ~clk;
Then to know the maximum safe frequency you can run at, look at your compilation reports in your design tools by running timing analysis. It is available in any FPGA CAD tool.
Your code seems working fine using Xilinx Vivado 14.2 but there is only one error which is the following line
assign output_signal = internal_output_buffer;
You can't assign registers by using "assign" and also "internal_output_buffer" is not defined.
I also personally recommend to set all registers to some values at initial. Your variables "resetn" and "counter" are not assigned initially. Basicly change your code like this for example
reg [31:0] counter = 32'b0;
Here is my result with your code:
Your verilog code in the testcounter looks broken: (a) you're having multiple drivers, and (b) like #StrayPointer notices, you're using blocking assignments for assigning Register (Flip-Flop) values.
I'm guessing your intent was the following, which could fix a lot of simulation mismatches:
module testcounter
(
input wire clk,
input wire resetn,
input wire [31:0] num_to_count,
output reg [7:0] output_signal
);
reg [31:0] counter;
always#(posedge clk or negedge resetn) begin
if (!resetn) begin
counter <= 0;
end else begin
if (counter == num_to_count) begin
counter <= 0;
end else begin
counter <= counter + 1;
end
end
end
assign output_signal = (counter == num_to_count) ? 8'hff : 8'h00;
endmodule

Verilog Array Walkthrough

I am just starting Verilog, and with little to no direction. I have been trying to build an 4 bit array that I want to walk through turning on and then off each of my LED's in order. I want them to go from 0-3, 7-4 and start over. I haven't set up my loops yet, however I want to see if I'm at least going in the right direction.
// 4 bit oscillating LED pattern
module count_osc (rstn, osc_clk, clk, LED);
input rstn;
output osc_clk;
output clk;
output [7:0] LED;
reg [22:0]c_delay;
genvar i;
genvar j;
GSR GSR_INST (.GSR(rstn)); // Reset occurs when argument is active low.
OSCC OSCC_1 (.OSC(osc_clk));
generate
for (i=0; i<4; i=i+1) begin : LED_loop
assign LED[i] = (clk);
for (j=4; j<8; j=j+1) begin : LED_loop_2
assign LED[j] = (~clk);
end
end
endgenerate
// The c_delay counter is used to slow down the internal oscillator (OSC) output
// to a rate of approximately 0.5 Hz
always #(posedge osc_clk or negedge rstn)
begin
if (~rstn)
c_delay <= 32'h0000;
else
c_delay <= c_delay + 1;
end
assign clk = c_delay[22];
endmodule
There are few misconceptions about verilog here, which are quite common for programmers coming from more procedural languages.
If your not aware Verilog describes hardware and therefore everything can happen in parallel, we do not procedurally start at the top and work our way through lines of code. Every initial and always blocks are running at the same time.
assign should be used outside of loops and it is a continuos assignment, ie combinatorial logic.
generate is used for parameterising hardware instances, you should not need this on basic examples. NB it also means that the hardware you describe can be quite tricky to understand.
With that in mind you may realise that this block:
generate
for (i=0; i<4; i=i+1) begin : LED_loop
assign LED[i] = (clk);
for (j=4; j<8; j=j+1) begin : LED_loop_2
assign LED[j] = (~clk);
end
end
endgenerate
Does not mean much, the first section is:
assign LED[0] = (clk);
assign LED[1] = (clk);
assign LED[2] = (clk);
assign LED[3] = (clk);
The second for loop is inside the first but only uses the second variable essentially overwriting the same statements 4 times:
assign LED[4] = (~clk);
assign LED[5] = (~clk);
assign LED[6] = (~clk);
assign LED[7] = (~clk);
When suggesting you write out what you want I was implying you write out the above instead of using generates.
Solution
I am not sure of the exact sequence you want from your question as you refer to a 4 bit array but uses 8 elements for the LED.
I think this might be a good place to practice creating a FSM (Finite state machine).
reg [2:0] state;
reg [2:0] nextstate;
always #(posedge clk or negede rst_n) begin
if (~rst_n) begin
state <= 'b0;
end
else begin
state<= nextstate;
end
end
//Next state logic (keeping it simple)
always #* begin
nextstate = state +1;
end
//Output logic
always #* begin
case(state)
3'd0 : LED = 'b0000_0000; //Binary makes sense as we can see the LED pattern
3'd1 : LED = 'b0000_0001;
3'd2 : LED = 'b0000_0011;
3'd3 : LED = 'b0000_0111;
3'd4 : LED = 'b0000_1111;
3'd5 : LED = 'b0000_0111;
3'd6 : LED = 'b0000_0011;
3'd7 : LED = 'b0000_0001;
default : LED = 'b0000_0000; //Default unreachable if we completed the case
endcase
end
I do not think this completes the sequence your trying to do but it should give enough of an understanding to complete the sequence yourself.

Resources