[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
  SystemPerl
  Voneline
  WFH
General Info
  Papers

Issue #449

Using public accessor tasks/functions to read and write registers causes BLKANDNBLK error

Added by Jeremy Bennett about 1 year ago. Updated about 1 year ago.

Status:Assigned Start date:03/06/2012
Priority:Normal Due date:
Assignee:Wilson Snyder % Done:

0%
Category:Lint
Target version:-

Description

I have a register for which we wish to provide a public accessor task and function, to allow it value to be written (via a task) and read (via a function) externally. I can do this either using /* public verilator */ on the task and function or by marking them as DPI-C export functions.

However, if I do so, then I get a BLKANDNBLK error. But for this error to occur, the following conditions must be met.
  • we must define both a write task and read function.
  • both task and function must be exported
  • the variable concerned must be the target of a non-blocking assignment.

It would be very convenient to be able to write both write and read accessors for registers which are the subject of non-blocking assignment. The fact that either one or the other can be done, suggests it should be possible.

I've attached two tests which demonstrate this problem (one for DPI export, the other for verilator public) as git patches against the current HEAD. I'll investigate further how this might be solved.

blkandnblk_export.patch - two test cases as git patch against HEAD. (4.1 kB) Jeremy Bennett, 03/06/2012 04:10 pm

blkandnblk_export.patch - Git patch for revised tests against HEAD (commit 31b55d384479ca19704b094128f545b499aa6a73) (15.1 kB) Jeremy Bennett, 03/07/2012 01:54 pm

History

#1
Updated by Wilson Snyder about 1 year ago

  • Status changed from New to Assigned

Could you extend the test to check the read and write accessors? Due to the blocking assignment there's both the new value and the old value at play. It should correctly be sorting them out, but it's better to be sure and also verify it doesn't change down the road. Assuming the accessors do work correctly, then it's just a issue of automatically suppressing the warning.

#2
Updated by Jeremy Bennett about 1 year ago

Tests extended to include execution. Running with -Wno-BLKANDNBLK, these tests give correct results. The test harness matches for the exact output. Ideally I should like to use pattern matching to skip irrelevant lines with the "expect" argument, but I couldn't get this to work.

It looks safe to suppress the warning in this case.

Revised tests attached as git diff against current HEAD (commit 31b55d384479ca19704b094128f545b499aa6a73).

#3
Updated by Wilson Snyder about 1 year ago

  • Category set to Lint
  • Assignee set to Wilson Snyder

I'll suppress the warning.

Ideally I should like to use pattern matching to skip irrelevant lines with the "expect" argument, but I couldn't get this to work.

expect takes either an exact match, or a pattern. For example if you add a .* then you'll need to also quote other magic characters such as the parenthesis in your output, the easiest way is to see how "quotemeta" is used in test_regress/t/*.pl.

Also available in: Atom