Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Incorrect Result of Cascading Module Using Generate Statement #1409

Closed
veripoolbot opened this issue Mar 14, 2019 · 3 comments
Closed

Incorrect Result of Cascading Module Using Generate Statement #1409

veripoolbot opened this issue Mar 14, 2019 · 3 comments
Labels
area: wrong runtime result Issue involves an incorrect runtine result from Verilated model resolution: no fix needed Closed; no fix required (not a bug)

Comments

@veripoolbot
Copy link
Contributor

Author Name: Xusine Lin
Original Redmine Issue: 1409 from https://www.veripool.org

Hi. I use Verilator to verify a ripple carry adder formed by a series of full adders generated by generate statement of systemverilog, but I get a wrong result.
Here is my code:

full_adder.v:

```verilog
module full_adder #(parameter width_p = "inv")(
input [width_p-1:0] opA_i
,input [width_p-1:0] opB_i
,input [width_p-1:0] opC_i

,output [width_p-1:0] res_o
,output [width_p-1:0] car_o
);
generate
for(genvar i = 0; i < width_p; i++) begin: CSA_EACH
assign res_o[i] = opA_i[i] ^ opB_i[i] ^ opC_i[i];
assign car_o[i] = opA_i[i] & opB_i[i] | opA_i[i] & opC_i[i] | opB_i[i] & opC_i[i];
end
endgenerate
endmodule

And this is the accumulator using generate statement to create the ripple carry adder:

module accumulator(
input clk_i
,input rst_i
,input [31:0] opA_i
,output [31:0] result_o
,output carry_o
);
reg [32:0] acc_r;
wire [31:0] acc_n;
wire car_n;
generate begin: FULL_ADDER_STRING
wire car[31:0];
full_adder #(.width_p(1))
x0(
.opA_i(0)
,.opB_i(opA_i[0])
,.opC_i(acc_r[0])
,.res_o(acc_n[0])
,.car_o(car[0])
);
for(genvar i=1; i < 32; ++i) begin : STRING
full_adder #(.width_p(1))
x(
.opA_i(car[i-1])
,.opB_i(opA_i[i])
,.opC_i(acc_r[i])
,.res_o(acc_n[i])
,.car_o(car[i])
);
end
assign car_n = car[31];
end
endgenerate
always_ff @(posedge clk_i) begin
if(rst_i) acc_r <= '0;
else acc_r <= {car_n,acc_n};
end
assign result_o = acc_r[31:0];
assign carry_o = acc_r[32];
endmodule

I run my test bench where I set opA_i to 1 and output the port result_o every cycle in Vivado 2018.3 and I get the correct result, but in Verilator I get the output like this:

0
1
2
3
4
13
14
15
8
25
26
27
28
21
...


I'll upload all my files. you can use make to generate the same result.

Best wishes!
@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Xusine Lin
Original Date: 2019-03-14T13:28:23Z

In spite of the disorder I packed my code into the attachment.

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-03-14T22:04:21Z

%Warning-STMTDLY: bsg_nonsynth_clock_gen.v:15: Unsupported: Ignoring delay on this delayed statement.

Verilator is a cycle based simulator, so your delay in making the clock is ignored and you have a toggling clock with zero time between edges. At that point your flop races and won't match "sane" expections.

Instead drive the clock in from the .cpp code and I suspect it will match up, if not please reopen.

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Xusine Lin
Original Date: 2019-03-15T11:12:22Z

Thanks! It works!

@veripoolbot veripoolbot added area: wrong runtime result Issue involves an incorrect runtine result from Verilated model resolution: nofixneeded resolution: no fix needed Closed; no fix required (not a bug) and removed resolution: nofixneeded labels Dec 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area: wrong runtime result Issue involves an incorrect runtine result from Verilated model resolution: no fix needed Closed; no fix required (not a bug)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@veripoolbot