I've encountered a test bench which can essentially be boiled down to the below example: clock and signals are changed in the in the same timestep with blocking assignments. I believe this causes a race condition between the clock and the two ctrlX signals, but I was unable to prove in the EDA playground (I understand it's beyond my control). Am I correct that there is a race condition?
(EDA Playground link: https://www.edaplayground.com/x/5yDX#&togetherjs=gkG5xewfNN)
module tb_example;
reg clk = 1;
reg [3:0] dff1,dff2;
reg [3:0] ctrl1 = 'd0;
reg [3:0] ctrl2 = 'd0;
initial begin
#10 ctrl1 = 'd1;
#20 ctrl1 = 'd2;
#10 ctrl1 = 'd3;
#100 $finish;
end
always begin
#5 clk = !clk;
end
initial begin
$dumpfile("dump.vcd");
$dumpvars(0,tb_example);
end
initial begin
#10 ctrl2 = 'd1;
#20 ctrl2 = 'd2;
#10 ctrl2 = 'd3;
#100 $finish;
end
always # (posedge(clk)) begin
dff1 <= ctrl1;
end
always # (posedge(clk)) begin
dff2 <= ctrl2;
end
endmodule
Yes, this is a race condition because you are using blocking assignments for ctrlx and they are changing at the same time as posedge clk. So, the values assigned to dffx are indeterminate and can vary from simulator to simulator.
One way to avoid this is to change ctrlx on the negedge of clk:
reg clk = 0;
Related
I want to do manchester encoder's simulation in verilog. Design code and testbench codes are written. Although I don't get any error, in the simulation part "clk" and "data_out" are not working which is red color in simulation but reset and data_in are working in the simulation properly. How can I correct the issue?
module manchester_encoder(clk,reset,data_in,data_out);
input clk;
input reset;
input data_in;
output data_out;
integer prev_data;
assign data_out = data_in ^ prev_data;
always #(posedge clk) begin
if (reset) begin
prev_data <= 0;
end else begin
prev_data <= data_in;
end
end
endmodule
Its testbench
module testbench_manchester_encoder();
// Declare the signals
reg clk;
reg reset;
reg data_in;
wire data_out;
// Instantiate the DUT
manchester_encoder encoder(.clk(clk), .reset(reset), .data_in(data_in), .data_out(data_out));
// Generate the clock signal
always #10 clk = ~clk;
// Stimulus process
initial begin
reset = 1;
data_in = 0;
#20 reset = 0;
#10 data_in = 1;
#10 data_in = 0;
#10 data_in = 1;
#10 data_in = 0;
#10 $finish;
end
// Monitor process
always #(posedge clk) begin
$display("Time=%t, data_out=%b", $time, data_out);
end
endmodule
You never initialize clk in your testbench, doing that fixes your problem:
module testbench_manchester_encoder();
// Declare the signals
reg clk = 0; // <------- here
reg reset;
reg data_in;
...
I am using Quartus Prime Lite 19.1.0.
module memory_address_register1 #(
parameter ADDR_WIDTH = 4
)(
input clk, rst, load,
input [ADDR_WIDTH-1:0] add_in,
output reg [ADDR_WIDTH-1:0] add_out
);
always #(posedge clk) begin
if (rst) begin
add_out <= 4'b0000;
end else if (load) begin
add_out <= add_in;
end else begin
add_out <= add_out;
end
end
endmodule
module mmr_tb();
reg clk, rst, load;
reg [3:0] add_in;
wire [3:0] add_out;
initial begin
clk <= 1'b0;
rst <= 1'b0;
load <= 1'b0;
end
memory_address_register1 mmr (.clk(clk), .rst(rst), .load(load), .add_in(add_in), .add_out(add_out));
always #10 clk = ~clk;
initial begin
#20 add_in <= 4'd2;
#10 add_in <= 4'd3;
load <= 1'b1;
#30 add_in <= 4'd6;
#10 load <= 1'b1;
end
endmodule
It the output (add_out) accurate? Should the output (add_out) at t=70.0ns be "6" or "7"?
If the expected output is "6", can anyone explain why is that?
img2: posedge clk output value from previous clk cycle
I ran the testbench using modelsim, and I am able to get the expected output I wanted (output on the exact clock edge), but is it expected?
https://imgur.com/a/M85zPKT
You have potential race conditions in your testbench code. You should drive all your inputs in the testbench the same way you drive them in the design:
Use nonblocking assignments (<=) instead of blocking assignments (=)
Use #(posedge clk) instead of # delays
This will guarantee that your inputs will be synchronous to the clock. This also assures that pulsewidths of your inputs are a multiple of the clock period. Some of your signals are half a period wide or 1.5 periods wide.
module mmr_tb();
reg clk, rst, load;
reg [3:0] add_in;
wire [3:0] add_out;
initial begin
clk <= 0;
rst <= 1;
load <= 0;
add_in <= 0;
repeat (2) #(posedge clk);
rst <= 0;
forever #(posedge clk) begin
add_in <= add_in + 1;
end
end
memory_address_register1 mmr (.clk(clk), .rst(rst), .load(load), .add_in(add_in), .add_out(add_out));
always #10 clk = ~clk;
initial begin
repeat (4) #(posedge clk); load <= ~load;
repeat (1) #(posedge clk); load <= ~load;
repeat (4) #(posedge clk); load <= ~load;
repeat (1) #(posedge clk); load <= ~load;
repeat (3) #(posedge clk); $finish;
end
endmodule
I have a problem in the test bench code, and I am not getting correct waveforms. Even the clock does not trigger.
CODE for D Flipflop:
module D_FF(o,D,clk);
output reg o;
input D,clk;
always # (posedge clk)
begin
if(D==1'b1)begin
o=1'b1;
end
else begin
o=1'b0;
end
end
endmodule
Code for TestBench:
module DD_flipflop_tb();
reg clk,D;
wire o;
D_FF i1(o,D,clk);
initial begin
clk=1'b0;
D=1'b0;
end
always begin
#20 clk=~clk;
#35 D=~D;
#5000 $finish;
end
endmodule
Here is what happens in the always block in your testbench.
At time 0, clk and D are 0.
At time 20, you invert clk, which becomes 1.
At time 55, you invert D, which becomes 1.
At time 5055, you call $finish which terminates the simulation. The statements in the block only execute once, which is why your inputs never change more than once.
In your testbench, initialize them as 0 in an initial block, then separate the clock generation from the data signal.
initial begin
clk = 0;
forever #20 clk=~clk;
end
initial begin
D=0;
forever #35 D=~D;
end
initial #5000 $finish;
You might want to assign separately the clock and the stimulus in the testbench:
initial begin
clk = 0;
D = 0;
#5000 $finish;
end
//..clock
always
#20 clk = ~clk;
//..stimulus
always
#35 D = ~D;
i got a code like below with clk = #10 ~clk
always# (posedge clk)begin
for (g=0;g<8;g=g+1) begin
ws = 1;
#20
ws = 0;
#20;
end
so is there any other way to make the delay 20 synthesizaeble in the coding above?
A flip-flop is the only way of synthesising a delay:
always #(posedge clk)
q <= d;
With clk = #10 ~clk;, q will be #10 later than d.
The question appear not to be how to synthesis a #20 but how to control the timing for signals in to a RAM. Digital design are based around clock edges, with each positive or negative edge a set distance a part, this is the period of the clock or 1/frequency.
To sequence events as you describe you need a FSM (Finite state machine) to control or sequence it. I have included a small example below:
Available on EDA Playground
module tb;
//Tb component
reg clk;
reg rst_n;
initial begin :clk_and_reset
clk = 0;
rst_n = 0;
#40 rst_n = 1;
#40;
forever begin
#20 clk = ~clk;
end
end
//Design
reg [1:0] state;
reg [1:0] next_state;
reg [31:0] counter;
reg ws;
localparam S_IDLE = 'd0;
localparam S_WAIT = 'd1;
localparam S_OFF = 'd2;
always #(posedge clk, negedge rst_n) begin
if (~rst_n) begin
state <= S_IDLE;
end
else begin
case(state)
S_IDLE : begin
state <= S_WAIT;
counter <= 'b0;
S_WAIT :
if (counter < 32'd10) begin
state <= S_WAIT; //Wait for 10 clock cycles
counter <= counter + 1;
end
else begin
state <= S_OFF;
counter <= 'b0;
end
S_OFF : state <= S_IDLE;
default : state <= S_IDLE; //IDLE
end
end
//Output decode based on state
always #* begin
//ws goes high when in Wait state
ws = (state == S_WAIT);
end
//Test program
initial begin
repeat (10) begin
#(posedge clk);
$display("%4t : State %b: ws :%b", $realtime, state, ws);
end
$finish();
end
endmodule
This could be expanded by staying in idle until triggered then by having counter and staying in wait for x number of clocks, x number of clocks in OFF before going back to idle and waiting to be triggered again.
Update
I have updated the code example to stay in the WAIT state for 10 clock cycles to demonstrate how to control the delay between transitions.
As I have known, D flipflop samples its input value at every positive edge
of the clock.
Thus, it will produce a 1 cycle delay. Right?
But why does my D flip flop does not produce a 1 cycle delay?
module flipflop(
input clk,
input rstn,
input [7:0] i_data,
output reg [7:0] o_data
);
always #(posedge clk) begin
if (~rstn) begin
o_data <= 0;
end
else begin
o_data <= i_data;
end
end
endmodule
module test;
reg clk;
reg [7:0] i_data;
reg rstn;
wire [7:0] o_data;
initial begin
clk = 0;
rstn = 1;
i_data = 0;
#20;
rstn = 0;
#30;
rstn = 1;
#20;
i_data = 8'hFA;
#20;
i_data = 8'hF0;
#20
i_data = 8'hF1;
#20
#10 $finish;
end
always #10 clk = !clk;
flipflop flipflop(
.clk (clk),
.rstn(rstn),
.i_data(i_data),
.o_data(o_data)
);
initial begin
$dumpfile("flipflop.vcd");
$dumpvars();
end
endmodule
My D flip flop functions like a combinational circuit here.
You've run up against Verilog simulator event scheduling subtleties! Changing the data assignments to use nonblocking assignments is probably the easiest fix.
#20;
i_data <= 8'hFA;
#20;
i_data <= 8'hF0;
#20
i_data <= 8'hF1;
#20
What was happening in your original version is that the clock and the input data were scheduled to happen at the same time. Since the simulator can only do one thing at a time, it has to decide if it will change the clock or the data first. It changed the data first, so when the clock edge comes along, the input data has already changed to the next value so it looks like the data is slipping through the FF.
Nonblocking assignments (<=) are scheduled to happen after all the blocking assignments (=) have been done. So making the data assignments nonblocking ensures that they happen after the blocking-assigned clock edges.
Another way to rewrite things to work would be:
initial begin
#(posedge clk) i_data = 8'hFA;
#(posedge clk) i_data = 8'hF0;
#(posedge clk) i_data = 8'hF1;
end
The simulator is probably doing something like this:
initial begin
clk = 0;
rstn = 1;
i_data = 0;
#10;
clk = !clk;
#10;
rstn = 0;
clk = !clk;
#10;
clk = !clk;
#10;
clk = !clk;
#10;
rstn = 1;
clk = !clk;
#10;
clk = !clk;
#10
i_data = 8'hFA; //Input updated
clk = !clk; //Clock event
//o_data assigned here
#10;
clk = !clk;
#10;
i_data = 8'hF0;
clk = !clk;
#20
i_data = 8'hF1;
#20
#10 $finish;
end
Since the clock event is occurring last in each time step from your testbench, it looks like the flop is being assigned immediately. You likely want your testbench to be entirely slaved off the clock so Marty's suggestion of using #(posedge...) will achieve this. You could also simply delay your assignments once at the very beginning:
initial begin
clk = 0;
#1;
rstn = 1;
i_data = 0;
#20;
rstn = 0;
#30;
rstn = 1;
#20;
i_data = 8'hFA;
#20;
i_data = 8'hF0;
#20
i_data = 8'hF1;
#20
#10 $finish;
end