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

Comments

@veripoolbot
Copy link
Contributor

@veripoolbot veripoolbot commented Jul 7, 2011


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

@veripoolbot veripoolbot commented Jul 7, 2011


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

@veripoolbot veripoolbot commented Jul 7, 2011


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

@veripoolbot veripoolbot commented Apr 12, 2012


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

@veripoolbot veripoolbot commented Apr 12, 2012


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

@veripoolbot veripoolbot commented Apr 12, 2012


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

@veripoolbot veripoolbot commented Apr 13, 2012


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

@veripoolbot veripoolbot commented Apr 15, 2012


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

@veripoolbot veripoolbot commented Jun 14, 2019


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

@veripoolbot veripoolbot commented Oct 18, 2019


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

@veripoolbot veripoolbot commented Nov 12, 2019


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

@veripoolbot veripoolbot commented Nov 13, 2019


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

@veripoolbot veripoolbot commented Nov 13, 2019


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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.