Project

General

Profile

[logo] 
 
Home
News
Activity
About/Contact
Major Tools
  Dinotrace
  Verilator
  Verilog-mode
  Verilog-Perl
Other Tools
  BugVise
  CovVise
  Force-Gate-Sim
  Gspice
  IPC::Locker
  Rsvn
  SVN::S4
  Voneline
  WFH
General Info
  Papers

Issue #648

Error-BLKANDNBLK with nested modules in generate block

Added by Krzysztof Jankowski almost 6 years ago. Updated 3 months ago.

Status:
Confirmed
Priority:
Normal
Assignee:
-
Category:
Lint
% Done:

0%


Description

The attached code gives error: %Error-BLKANDNBLK: condgen.sv:29: Unsupported: Blocked and non-blocking assignments to same variable: v.datat. When code gets pasted directly in place of module then the entire example compiles just fine.

condgen.sv (1.25 KB) Krzysztof Jankowski, 05/21/2013 11:48 PM

condgen2.sv (1.12 KB) Olivier D'Arcy, 01/26/2019 04:28 AM

History

#1 Updated by Wilson Snyder almost 6 years ago

  • Category set to Lint
  • Status changed from New to Confirmed

I'm not immediately sure how to fix this. The conflict is at that port since a single bit is selected that is effectively the same as an assignment, causing the message.

The good news is for now you can lint_off that error (it's an error because it can cause bad results if otherwise ignored)

// verilator lint_off BLKANDNBLK
logic [7:0]           datat;
// verilator lint_on BLKANDNBLK

Test added as t_param_if_blk.

#2 Updated by Olivier D'Arcy 3 months ago

Hi, I experience the same kind of issue with conditional generate statements.

Here (codegen2.sv attached) is another code example that highlights the problem. You need to remove the lint pragmas. You will hit the Error BLKANDNBLK. Then if you add the lint pragmas for BLKANDNBLK, you get a MULTIDRIVEN warning which prevents the code from compiling. Adding the lint pragmas for the MULTIDRIVEN warning solves the problem.

I was able to go around it by using lint off pragmas.

Still my RISCV RTL codebase heavily uses the generate if/else constructs so I get tons of such BLKANDNBLK errors. Some RTL sources are from third party (memory models generated by memory compilers, etc) so inserting pragmas in these files is not an ideal solution.

Also available in: Atom