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

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

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

Comments

@veripoolbot
Copy link

@veripoolbot veripoolbot commented Mar 6, 2012


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

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Mar 7, 2012


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

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Mar 7, 2012


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

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Mar 7, 2012


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

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Oct 18, 2019


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


Not currently being worked on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.