-
Notifications
You must be signed in to change notification settings - Fork 283
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
[Moore] Add assert, assume, and cover ops. #7589
base: main
Are you sure you want to change the base?
Conversation
I'm not sure what the |
c651bc9
to
d7dcb4e
Compare
I know what
|
return failure(); | ||
|
||
auto defer = convertDeferAssert(stmt.isDeferred, stmt.isFinal); | ||
switch (stmt.assertionKind) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Immediate assertions can have an action block associated with them, for example:
assert (x) $display("success");
assert (x) else $error("failure");
assert (x) $display("yay") else $error("nay");
It's not entirely clear to me if the presence of an action block simply turns the assert into an "if" statement, or whether the fact that it's an assert allows for additional global enabling/disabling controls to take effect. Do you know how this is supposed to work?
In any case, we can definitely deal with all of this later. If we postpone handling this, I'd suggest to add a check above the switch statement that ensures there is no action block associated with the assertion. That should produce an error like "unsupported immediate assertion action block" or similar.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I also noticed that. It's so similar to if-else
in the slang AST. Therefore, I cannot make up my mind on how to deal with these different situations. It would be great if we could lower the situations you mentioned to if-else
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I distinguish the assertion statement between having an action block and not. The former will create moore.assert
, moore.cover
, etc. The latter will create cf.cond_br
. WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
module ImmediateAssertiWithActionBlock;
logic x;
int a;
assert (x) a = 1;
assert (x) else a = 0;
assert (x) a = 1; else a = 0;
endmodule
moore.procedure always {
%0 = moore.read %x : <l1>
%1 = moore.conversion %0 : !moore.l1 -> i1
cf.cond_br %1, ^bb1, ^bb2
^bb1: // pred: ^bb0
%2 = moore.constant 1 : i32
moore.blocking_assign %a, %2 : i32
cf.br ^bb2
^bb2: // 2 preds: ^bb0, ^bb1
moore.return
}
..........
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds great! 🥳
d7dcb4e
to
b88f0da
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great! Can you add your
assert (x) a = 1;
assert (x) else a = 0;
assert (x) a = 1; else a = 0;
examples as a test, to ensure things work as expected before merging?
These immediate assertion ops borrow from the
SV
dialect.