Major Tools
Other Tools
General Info

Issue #677

unable to unroll for loop causing BLKLOOPINIT error

Added by Jie Xu over 4 years ago. Updated about 2 years ago.

% Done:



When compiling our RTL code with Verilator, we got "BLKLOOPINIT" errors. According to Verilator manual, we try to increase the --unroll-count 256 and --unroll-stmts 99999. However, still Verilator reports the "BLKLOOPINIT" errors.

After a bit investigation, we found the root of the error actually is that Verilator is unable to unroll the for loop which has a little bit complicated condition, e.g. for (i=0; (i< 4) && (i > 2); i++).

This means the error message in this case is not quite correct since it actuall report
Unsupported: Delayed assignment to array inside for loops (non-delayed is ok - see docs)

A test case to regenerate the issue is attached.

t_unroll_blkloopinit.v (870 Bytes) Jie Xu, 09/13/2013 11:49 AM View (466 Bytes) Jie Xu, 09/13/2013 11:49 AM


#1 Updated by Wilson Snyder over 4 years ago

  • Category set to Unsupported
  • Status changed from New to Assigned

Yes, the unroller is pretty stupid, it predates the internals being able to emulate most code.

Perhaps you might be willing to look at providing a patch? Basically if you look at V3Unroll now it just looks for certain hardcoded constructs. Instead it should apply values in the initial part of the for, then execute the test and increment, and 'timeout' if too many loops are needed, or anything strange happens (like other variables are needed, or an unsupported construct like PLI call is seen). V3Table has good examples of how to execute code during compilation.

#2 Updated by Jie Xu over 4 years ago

I think I could give it a try. Will update you if there is some progress or problems.

#3 Updated by Johan Bjork over 2 years ago


I wrote up an initial version of this over the weekend, it's mostly passing tests but needs some more work. I'm somewhat worried it'll have a negative performance impact though, especially for the cases where we decide to not unroll the loop. Previously it was a fairly quick check, but now we either have to 1) run the simulation for the incr/condition to determine size of loop, then bail if too big 2) Run the actual unrolling and then abort if it goes for too long. both which seems fairly slow.

Is there any performance benchmarks I can run to ensure things are looking good after this change?

#4 Updated by Wilson Snyder over 2 years ago

I don't have any verilator-compiletime benchmarks. I assume you have some fairly large jobs you could just "time" - just make sure your machine is idle otherwise for fairness. I suspect it will be in the noise, but good to check.

#5 Updated by Johan Bjork over 2 years ago

Thanks. I've pushed a draft to, please let me know what you think.

#6 Updated by Johan Bjork over 2 years ago

Revived this patch here: The patch also fixes bug392

#7 Updated by Wilson Snyder over 2 years ago

Sorry I missed providing feedback on this.

1. Nit, it's "if (...)" not "if(...)". There's no space after function names "fileline()" not "fileline ()". These match GNU conventions (in theory).

2. forUnroller now seems to return a bool indicating additional "did it" status, but this isn't tested in forUnrollCheck. Presumably it should be, otherwise the loop will get mis-deleted. (Try #3 below it might find this.)

3. I think you have them all covered, but to the test cases, please add a complicated non-simulatable thing to init, cond, and inc, for example

j = 0; for (i=$c32("1"); i&lt;3; +i) j+;
if (j!=2) $stop;
j = 0; for (i=1; i<$c32("3"); +i) j+;
if (j!=2) $stop;
j = 0; for (i=1; i&lt;3; i=i+$c32("1")) j++;
if (j!=2) $stop;

4. I get a warning:

../V3Unroll.cpp:200:11: error: unused variable 'proceed' [-Werror=unused-variable]

In your .bashrc or whatever shell equivelent please


then reconfigure and build emacs, so you get warnings.

#8 Updated by Johan Bjork over 2 years ago

Thanks for the review. Updated the patch with the additional tests and fixed the issues you mentioned.

#9 Updated by Wilson Snyder over 2 years ago

  • Status changed from Assigned to Resolved

Great! Fixed in git towards 3.881.

#10 Updated by Wilson Snyder about 2 years ago

  • Status changed from Resolved to Closed

In 3.882.

Also available in: Atom