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

Combinatorial loop fails to converge #531

Closed
veripoolbot opened this issue Jul 17, 2012 · 4 comments
Closed

Combinatorial loop fails to converge #531

veripoolbot opened this issue Jul 17, 2012 · 4 comments
Labels
resolution: no fix needed Closed; no fix required (not a bug)

Comments

@veripoolbot
Copy link
Contributor


Author Name: Jeremy Bennett (@jeremybennett)
Original Redmine Issue: 531 from https://www.veripool.org
Original Date: 2012-07-17


This may not be a bug, but a failure by me to understand the limitations of cycle accurate modeling. The following code is intended to increment register @y1@ every time the clock changes:

module t (/*AUTOARG*/
    // Inputs
    clk
    );
    input clk;

    integer   cnt = 0;

    reg [1:0] y1;

`ifndef VERILATOR
    initial begin
       $dumpfile("obj_dir/iv_t_eval_problem6/iv_t_eval_problem6.vcd");
       $dumpvars;
    end
`endif

    initial begin
       y1 = 0;
    end

    always @(clk) begin
       y1 = y1 + 1;
    end

    always @(posedge clk) begin
       cnt = cnt + 1;
    end

    always @(clk) begin
`ifdef TEST_VERBOSE
       $display("clk = %x, y1 = %x", clk, y1);
`endif
       if (cnt > 4) begin
          $write("*-* All Finished *-*\n");
          $finish;
       end
    end

endmodule

It works just fine with Icarus Verilog, producing the expected VCD, with y1 incrementing on each clock edge. However with Verilator, the code fails to compile

%Warning-UNOPTFLAT: t/t_eval_problem6.v:17: Signal unoptimizable: Feedback to clock or circular logic: v.y1
%Warning-UNOPTFLAT: Use "/* verilator lint_off UNOPTFLAT */" and lint_on around source to disable this message.
%Warning-UNOPTFLAT:      Example path: t/t_eval_problem6.v:17:  v.y1
%Warning-UNOPTFLAT:      Example path: t/t_eval_problem6.v:30:  ALWAYS
%Warning-UNOPTFLAT:      Example path: t/t_eval_problem6.v:17:  v.y1

I don't understand this. Sure @y1@ is assigned from an expression involving itself. But this is in a combinatorial @Always@ block sensitive to @clk@, not @y1@, so there is no circularity.

BTW, if I disable UNOPTFLAT, I just get a Verilator program which fails to converge.

Advice appreciated.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2012-07-17T17:00:49Z


always @(non-edge) with only ='s indicates combinatorial logic. This I suspect won't synthesize, either, which is the real test for compatibility.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2012-07-17T17:01:56Z


P.S. what they are probably really after is

always @(posedge clk or negedge clk)
y <= y + 1

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Jeremy Bennett (@jeremybennett)
Original Date: 2012-07-17T17:40:34Z


Thanks for the explanation.

This came out of my efforts to get combinatorial always blocks with non-blocking assignments working. It was a test case of my own creation, but as you point out it probably won't synthesize (I'll check), so it isn't a good test case. I'm only looking at synthesizable use of non-blocking assignment in combinatorial always blocks.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2012-11-03T12:06:05Z


Inactive I think.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
resolution: no fix needed Closed; no fix required (not a bug)
Projects
None yet
Development

No branches or pull requests

1 participant