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

[Verif] Introduce a clocked assertion verif.clocked_assert #6982

Closed
dobios opened this issue May 2, 2024 · 3 comments
Closed

[Verif] Introduce a clocked assertion verif.clocked_assert #6982

dobios opened this issue May 2, 2024 · 3 comments
Labels

Comments

@dobios
Copy link
Contributor

dobios commented May 2, 2024

The current structure of the verif dialect requires the use of ltl.clock to associate a clock to an assertion (which is required). This means that a use-def analysis is required everytime we want to work with verif.assert, which leads to the sv.assert operation being used in most lowerings to Core dialects.

As suggested by @fabianschuiki , I propose that we add a verif.clocked_assert(clock, prop) that would be the canonicalization of verif.assert(ltl.clock(clock, prop)). This would make it easier to use move away from sv dialect ops in the core representations.

@dobios dobios added the verif label May 2, 2024
@dobios dobios changed the title [Verif] Introduce a clocked assertionverif.clocked_assert [Verif] Introduce a clocked assertion verif.clocked_assert May 2, 2024
@fabianschuiki
Copy link
Contributor

You'd probably want to flip the canonicalization around: canonicalize verif.assert(ltl.clock(clock, prop)) to verif.clocked_assert(clock, prop), in order to allow passes to only work with verif.clocked_assert.

@maerhart
Copy link
Member

maerhart commented May 3, 2024

I assume the verif.clocked_assert will also verify that no (other) ltl.clock operation is present in the use-def chain of the prop operand?

@fabianschuiki
Copy link
Contributor

That's an excellent point. I like the idea of having clocked_assert enforce that the operand itself contains no clocking or enable/disable information. The regular assert could then have a canonicalizer which pulls single unambiguous clocking and enable/disable signals up into a clocked_assert where possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants