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

blocking & non-blocking assigns -- verilator issues error when no logical conflict exists #364

Open
veripoolbot opened this issue Jul 7, 2011 · 12 comments
Labels
area: scheduling Issue involves scheduling/ordering of events effort: weeks Expect this issue to require weeks or more of invested effort to resolve type: feature-IEEE Request to add new feature, described in IEEE 1800

Comments

@veripoolbot
Copy link
Contributor


Author Name: John Stevenson
Original Redmine Issue: 364 from https://www.veripool.org


In regards to the following error message:

It was issued in error. To reproduce, do the following:

// pseudo-code:
logic [31:0] shiftreg [10];
assign shiftreg[0] = input;
for( i = 1; i < 10; i++ ) begin
    always_ff @(posedge clk) begin
       shiftreg[ i ] <= shiftreg[ i - 1 ];
    end
end

There is no logical conflict:

... shiftreg[ 0 ] has a blocking assign

... shiftreg[ 1 to 9 ] have non-blocking

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2011-07-07T18:50:18Z


Unfortunately this is a known limitation that's not going to be fixed soon; this case is shown in the manual under BLKANDNBLK. Verilator does all scheduling presently by variable not by individual bits (for speed) so it complains when all bits aren't handled the same way. Sorry. It's on the medium term list of things to improve.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Alex Solomatnikov
Original Date: 2011-07-07T20:58:54Z


Temporary workaround is to convert packed array to unpacked array. Of course, this can cause other problems with other tools.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Alex Solomatnikov
Original Date: 2012-04-12T00:57:44Z


Is this issue resolved as part of DETECTARRAY issue fix?

Seems to compile and run correctly now.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2012-04-12T10:47:49Z


Yes, fixed in git towards 3.833.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Alex Solomatnikov
Original Date: 2012-04-12T20:01:06Z


Apparently, I was wrong - it sill does not work in some cases, e.g.:

    always_ff @(posedge clk) begin
       integer k;

       for( k=0; k<RATIO-1; k++ ) begin
          if( en[k] ) begin
             full_line[k*`WIDTH +: `WIDTH] <= `CLK2Q rdata;
          end
       end
    end // always_ff @
    assign full_line[(RATIO-1)*`WIDTH +: `WIDTH] = rdata;

I got:

%Error-BLKANDNBLK: ...: Unsupported: Blocked and non-blocking assignments to same variable: full_line
%Error-BLKANDNBLK: ..: Unsupported: Blocked and non-blocking assignments to same variable: full_line

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Alex Solomatnikov
Original Date: 2012-04-13T00:33:48Z


I should add that in previous example variables are defined as simple vectors:

    logic [`WIDTH-1:0]       rdata;
    logic [RATIO*`WIDTH-1:0] full_line;

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2012-04-15T20:28:37Z


The fixed note should have mentioned it fixes only arrays used in this context. I'll leave the bug open until the more general fix is made.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Roman Popov
Original Date: 2019-06-14T23:17:02Z


I wonder if some simple fix can be invented here, like splitting array into 2 arrays internally, one modeling a register, and one modeling a wire.

So far all of large designs I've tried fail in Verilator with this error. Looks like its quite a common coding practice.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-10-18T00:06:08Z


Not currently being worked on.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Paul Donahue
Original Date: 2019-11-12T22:17:19Z


I am running into this problem very frequently with RTL that extensively uses packed structs. For instance this does different types of assignments to different elements of the struct:

module foo(input logic clk, x, y, output ab_s ab);
  always_comb ab.a = x;
  always @(posedge clk) ab.b <= y;
endmodule

See the attached tarball for an example with Makefile. I have a workaround as the tarball shows but it is painful to change all of the RTL to implement this workaround.

Add me as a vote to raise the priority above Low. Thanks.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-11-13T00:34:00Z


Good point, raised to normal. Perhaps if I provide some pointers you could attempt a patch to the warning (which should be sufficient for your case versus the larger issue)?

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Paul Donahue
Original Date: 2019-11-13T21:39:39Z


I'm not sure if you mean that the warning can be disabled for my case or the fundamental issue can be fixed for my case. Either way, I'm happy to be involved in exploring a solution (hopefully to the fundamental problem).

@veripoolbot veripoolbot added area: scheduling Issue involves scheduling/ordering of events effort: weeks Expect this issue to require weeks or more of invested effort to resolve type: feature-IEEE Request to add new feature, described in IEEE 1800 labels Dec 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: scheduling Issue involves scheduling/ordering of events effort: weeks Expect this issue to require weeks or more of invested effort to resolve type: feature-IEEE Request to add new feature, described in IEEE 1800
Projects
None yet
Development

No branches or pull requests

1 participant