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

Jump to bottom

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

Open
veripoolbot opened this issue Mar 6, 2012 · 4 comments
Open

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

veripoolbot opened this issue Mar 6, 2012 · 4 comments
Labels
area: lint Issue involves SystemVerilog lint checking area: scheduling Issue involves scheduling/ordering of events effort: days Expect this issue to require roughly days of invested effort to resolve

Comments

@veripoolbot
Copy link
Contributor

Author Name: Jeremy Bennett (@jeremybennett)
Original Redmine Issue: 449 from https://www.veripool.org

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.
@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2012-03-07T00:21:22Z

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.

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Jeremy Bennett (@jeremybennett)
Original Date: 2012-03-07T13:54:28Z

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

@veripoolbot
Copy link
Contributor Author

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2012-03-07T14:09:57Z

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.

@veripoolbot
Copy link
Contributor Author

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

Not currently being worked on.

@veripoolbot veripoolbot added area: lint Issue involves SystemVerilog lint checking area: scheduling Issue involves scheduling/ordering of events effort: days Expect this issue to require roughly days of invested effort to resolve labels Dec 22, 2019
@wsnyder wsnyder mentioned this issue Aug 26, 2020
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area: lint Issue involves SystemVerilog lint checking area: scheduling Issue involves scheduling/ordering of events effort: days Expect this issue to require roughly days of invested effort to resolve
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@veripoolbot