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.
Related
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.
I'm writing a code to implement an asynchronous reset D flipfip, but the always# line is showing a syntax error:
`timescale 1ns / 1ps
module Dflipflop(
input D,
input reset,
input clk,
output Q
);
reg Q;
initial
begin
if(reset==1) //clear the output (Q=0)
begin
Q <= 0;
end
else if(reset==0)
begin
always#(posedge clk) //syntax error here...
begin
Q <= D;
end
end
end
endmodule
What could be the possible error, and is there a better logic for implementing the same ?
First of all I would not encourage you to use the initial statement except in testbench. This is not synthetizable so it should not appear in RTL.
Then I think you are confusing Verilog with a standard programming language which it is not.
In Verilog, there is two classes of statements:
processes, like always or initial
assignment, with assign that allows you to directly assign a 'value' to a wire
In processes there can be distinguished two classes :
Synchronous processes, //do something statements begin end will be evaluated only when an edge, specified in the #, occurs
always # (posedge clock) begin
//do something
end
Combinatorial processes, //do something statements will be evaluated every time the value of a wire or reg used in the //do something block changes
always #* begin
//do something
end
Here you have instantiated a process inside a process something that has no physical reality.
Another point, as described you want to activate the process only when reset==0 so you put a condition to enter the process. Once more, that does not make any sense in terms of synthesis. The process should be activated and that is in the process that the conditions should be evaluated.
A classical solution for implementing a D flip-flop with asynchronous reset is the following:
module Dflipflop(
input D,
input reset,
input clk,
output reg Q
);
always # (posedge clk or negedge reset) begin
if (!reset)
Q <= 1'b0; // Clear Q when reset negative edge occurs
else
Q <= D; // Capture D in Q when clk positive edge occurs and reset is high
end
endmodule
You cannot have always block inside initial. It should be written like this:
`timescale 1ns / 1ps
module Dflipflop(
input D,
input reset,
input clk,
output Q
);
reg Q;
always #(posedge clk, posedge reset)
begin
if(reset==1) //clear the output (Q=0)
begin
Q <= 0;
end
else
begin
Q <= D;
end
end
endmodule
You should either use initial(not recommended for synthesis) or always. One procedural block cannot come inside another. If you are really interested in designing a non-synthesizable logic and want to try out with initial, you can do something like this mentioned below. Both initial and always are procedural blocks.
....
else if(reset==0)
begin
repeat(100000) #(posedge clk)
begin
Q <= D;
end
end
end
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.
my code is as follows:
module command_FSM(sys_R_Wn,sys_ADSn,cState,sys_REF_REQ,sys_REF_ACK,sys_INIT_DONE,sys_CLK);
input sys_R_Wn;
input sys_CLK;
input sys_ADSn;
output [4:0] cState;
inout sys_INIT_DONE;
input sys_REF_REQ;
output sys_REF_ACK;
wire sys_R_Wn;
wire sys_ADSn;
reg [4:0] cState;
wire sys_INIT_DONE;
wire sys_REF_REQ;
reg sys_REF_ACK;
reg mjet;
integer i;
parameter c_idle=5'b10000;
parameter c_AR=5'b10001;
parameter c_tRFC=5'b10010;
parameter c_rdata=5'b10011;
parameter c_tDAL=5'b10100;
parameter c_cl=5'b10101;
parameter c_ACTIVE=5'b10110;
parameter c_wdata=5'b10111;
parameter c_REDA=5'b11000;
parameter c_tRCD=5'b11001;
parameter c_WRITEA=5'b11010;
initial
begin
cState=c_idle;
end
initial
begin
for(i=0;;i=i+1)
begin
#2;
if (sys_INIT_DONE==1'b1)
if(~sys_REF_REQ && ~sys_ADSn)
begin
case (cState)
5'b10000: begin
cState=c_ACTIVE;
#10;
end
5'b10110:
if(sys_R_Wn)
begin
cState=c_tRCD;
#10;
cState=c_REDA;
end
else
begin
cState=c_tRCD;
#10;
cState=c_WRITEA;
end
5'b11000: begin
cState=c_cl;
end
5'b10101: begin
cState=c_rdata;
end
5'b11010: begin
cState=c_wdata;
end
5'b10111: begin
cState=c_tDAL;
end
endcase
end
end
end
always #(posedge sys_REF_REQ)
begin
sys_REF_ACK=1;
case(cState)
5'b10000: begin
cState=c_AR;
#50;
cState=c_idle;
end
endcase
end
endmodule
here i want "cState" signal to be scanned and updated continuously based on statemachines.Firstly i tried always #* but as it had only output signal cState to be updated.So that block was executed only once because it had no input signal that was being modified in that always #* block.So my doubt is is it good thing to use "infinite for loop" to serve that purpose of scanning and updating continuously
The short answer is no; it is not good style to implement FSMs using an infinite loop.
The long answer is that it very much depends. Firstly, if this FSM is purely for a functional model in simulation and never to be synthesized for an FPGA or ASIC; you might use an infinite loop to implement an FSM. However, you should use the keyword forever to implement these loops, not for (i = 0; ; i = i + 1) or while (1). Or, if they are clocked, you can use an always #(posedge clk) or the like to trigger them (or use forever begin #(posedge clk) if its a forked process or something fancy like that).
However, based on the header of this module, it appears you want to make a synthesizable FSM, it which case, theres quite a lot you need to do to fix your code. Heres a short list of suggestions to make your code synthesizable and have better style:
As a general rule, do not use initial blocks inside an module. While they have a few limited uses (in FPGA synthesis), you should fully understand those uses before using them. If you need a variable to take on an initial state, use a reset line in the element storing that variable (see the next point)
Combinational logic should be placed in an always #* block and sequential logic should be placed in an always #(posedge clk[, negedge rstL]) block (the reset is optional). When making a state machine, I recommend the following style:
reg state, next_state;
// The register that holds the state
always #(posedge clk, negedge rstL) begin
if (~rstL) begin
state <= INIT; // Your starting state here
end
else begin
state <= next_state;
end
end
// The logic that determines the next state and output values based on the inputs and current state
always #* begin
// Defaults
[ Place your outputs here with some default value ]
next_state = state; // As selfloops are common, I typically just set the next state to be the current state
case (state)
[ Your logic for what to do in each state here ]
endcase
end
This form I find to be the best to ensure no latches and makes the synthesis tools happy with simple register blocks (the always #(posedge clk) block).
Using parameters for state names is good practice, but you should use them everywhere, even in the case statement, like:
case (state)
INIT: begin
...
end
READ: begin
...
end
endcase
Do not use delays in your combinational logic like x = 1'b0; #10; x = 1'b1;. You change cState like this in your initial block but really should have different logic for each state.
You declare sys_REF_REQ as an inout when it should probably be an input.
Don't trigger logic on non-clock things, like always #(posedge sys_REF_REQ). Only use posedge and negedge on clocks and resets within synthesizable code.
Thats all I see right now, but other might add more in the comments. Best of luck!
I am very new to HDL language. I have a question about how to program a shift register. (i know i shift to the other direction). Why does the book use wire[N-1:0] r_next? what's drawback of my implementation?
thanks
my first try is as following
module lesson04#(parameter N=8)(
input wire clk, reset,
input wire data,
output wire out
);
reg [N-1: 0] r_reg;
always #(posedge clk or negedge reset)
begin
if(!reset)
r_reg =0;
else
r_reg[0]=data;
r_reg = r_reg<<1;
end
assign out =r_reg[N-1];
endmodule
but the book gives:
module lesson04#(parameter N=8)(
input wire clk, reset,
input wire data,
output wire out
);
reg [N-1: 0] r_reg;
wire[N-1:0] r_next;
always #(posedge clk or negedge reset)
begin
if(!reset)
r_reg =0;
else
r_reg <= r_next;
end
assign r_next= {data, r_reg[N-1:1]};
assign out =r_reg[N-1];
endmodule
First of all, don't forget your begin-ends around sections of code:
else begin
r_reg[0]=data;
r_reg = r_reg<<1;
end
Without this, only r_reg[0]=data will be in the else clause of the if statement. This will work, but is considered bad style due to the blocking statements in a sequential logic description...
Second, for modeling sequential blocks, use nonblocking assignments (<=) or your calculations may 'fall through' (google nonblocking vs blocking for more info). Your example may very well work (did you try it in a simulator?) but if things get more complicated and more variables are added things can break.
always #(posedge clk or negedge reset)
begin
if(!reset)
r_reg <= 0;
else begin // This is horrible! Don't write code like this!
r_reg[0] = data; // blocking
r_reg <= r_reg<<1; // non-blocking
end
end
For the above reason, it is sometimes recommended that combo logic is separated from sequential logic so that you can write nonblocking assignments to registers in sequential blocks, and blocking in combo blocks and never have to worry about the scheduling.
To code in this way, you need to calculate what the next output should be using the current state, hence the r_next bus in the answer. I think it tends to help the synthesis tool out too if all the flip-flops are separated from surrounding combo logic in this way.
Also, if your reset is active low (ie LOW resets ) it should be named as such, eg resetb or reset_n.
Your implementation produces quite a different output from the book's. You should prove this to yourself by constructing a simple testbench to drive your inputs and run a simulation. You will see that the book's output shifts the input data by a single clock cycle, whereas your output shifts the input data by eight clock cycles.
By the way you have indented your always block, I am led to believe that it is not what you wanted. This is how your block really behaves:
always #(posedge clk or negedge reset)
begin
if(!reset) begin
r_reg =0;
end else begin
r_reg[0]=data;
end
r_reg = r_reg<<1;
end
I always explicitly use the begin/end keywords in if/else statements to avoid this confusion.
The way it simulates, r_reg is always 0 because you clobber the 1st assignment (r_reg[0]=data;) with the 2nd (r_reg = r_reg<<1;). Another difference is that the book assigns data to the MSB of the shift register, but you assign it to the LSB.
If you are using decent linting and synthesis tools, you would probably get a bunch of warnings for your code. This would alert you to make some changes.