Skip to content

Support generic-derived constants as "numbers" in PSL #600

@lainy

Description

@lainy

Is your feature request related to a problem? Please describe.
Writing a core where the minimum time between changes (fastest toggle rate) of one of its outputs is determined by a generic. It'd be nice to use a PSL assertion to validate that, such as:

-- psl toggle_rate_01: assert always { s = '0'; s = '1' } |=> { (s = '1')[*DelayCycles] };
-- psl toggle_rate_10: assert always { s = '1'; s = '0' } |=> { (s = '0')[*DelayCycles] };

where DelayCycles is a constant computed from some generic.

However, when attempting the above, I get a compilation failure saying "number expected" at the location of DelayCycles. Indeed it works if I replace all the uses of generic-derived constants with numeric literals.
The same applies when using next_a.

Describe the solution you'd like
Support for generic-derived constants in PSL as above.

IEEE 1850-2010 (PSL) ambiguously defines "number" as "A non-negative integer value, and a statically computable expression yielding such a value." I'd say a generic is statically computable, but that only applies per instance, so it is unclear to me if my desired use case should be legal or not.

Describe alternatives you've considered
Have not tried any alternatives yet, open to suggestions here.

Additional context
None.

Metadata

Metadata

Assignees

Labels

Feature: PSLRequested feature addition related to the Property Specification Language (PSL).

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions