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

Verilator supports assert but not assume #1269

Closed
veripoolbot opened this issue Jan 31, 2018 · 5 comments
Closed

Verilator supports assert but not assume #1269

veripoolbot opened this issue Jan 31, 2018 · 5 comments

Comments

@veripoolbot
Copy link

@veripoolbot veripoolbot commented Jan 31, 2018


Author Name: Dan Gisselquist
Original Redmine Issue: 1269 from https://www.veripool.org

Original Assignee: Dan Gisselquist


According to the 2004 Accellera specification, section 17.13.2 regarding the assume statement,

For simulation, the environment must be constrained such that the properties that are assumed shall hold. Like an assert property, an assumed property must be checked and reported if it fails to hold. There is no requirement on the tools to report successes of the assumed properties.

Judging by this statement, adding the "assume" capability into Verilator should be as simple as treating it just like the assert() statement. For this reason, I propose the following patch:

diff --git a/src/verilog.l b/src/verilog.l
index c39a930..b1cee6a 100644
--- a/src/verilog.l
+++ b/src/verilog.l
@@ -437,6 +437,7 @@ vnum {vnum1}|{vnum2}|{vnum3}|{vnum4}|{vnum5}
"always_comb" { FL; return yALWAYS_COMB; }
"always_ff" { FL; return yALWAYS_FF; }
"always_latch" { FL; return yALWAYS_LATCH; }

  • "assume" { FL; return yASSERT; }
    "assert" { FL; return yASSERT; }
    "bind" { FL; return yBIND; }
    "bit" { FL; return yBIT; }
@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Jan 31, 2018


Original Redmine Comment
Author Name: Dan Gisselquist
Original Date: 2018-01-31T01:37:36Z


That patch didn't come through properly. Here it is in code, and as an attached file.

diff --git a/src/verilog.l b/src/verilog.l
index c39a930..b1cee6a 100644
--- a/src/verilog.l
+++ b/src/verilog.l
@@ -437,6 +437,7 @@ vnum	{vnum1}|{vnum2}|{vnum3}|{vnum4}|{vnum5}
    "always_comb"		{ FL; return yALWAYS_COMB; }
    "always_ff"		{ FL; return yALWAYS_FF; }
    "always_latch"	{ FL; return yALWAYS_LATCH; }
+  "assume"		{ FL; return yASSERT; }
    "assert"		{ FL; return yASSERT; }
    "bind"		{ FL; return yBIND; }
    "bit"			{ FL; return yBIT; }
</code>

Dan

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Jan 31, 2018


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2018-01-31T02:48:34Z


Good point. The catch is if a user misuses the statement they might get errors like "Unexpected assert" instead of "Unexpected assume" which will be confusing.

So, would you mind making a new patch which returns yASSUME, then duplicate the verilog.y rules that use yASSERT to "or"-in yASSUME rules.

Also, please add a test case - you can duplicate a line in one of the existing test_regress tests.

Thanks.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Jan 31, 2018


Original Redmine Comment
Author Name: Dan Gisselquist
Original Date: 2018-01-31T04:26:44Z


Ok, sure and (hopefully) done. Please consider the attached (updated) patch,

Dan

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Jan 31, 2018


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2018-01-31T12:33:16Z


Perfect, thanks. Fixed in git towards 3.919.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Feb 2, 2018


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2018-02-02T01:16:22Z


In 3.920.

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.