I am trying to write concurrent SVAs directly into the design.
Is there any way to write an assertion to check the frequency of a clock without using the realtime data type? Since the realtime data type is not synthesizable I am looking for alternatives.
In reply to Ankit Bhange:
Frequency/clock period infer time, which is a metric.
Another possible metric is a referenced clock with a known frequency; that can then become your metric. In SVA, you would count how many clocks of one clock occur within the other clock.
I welcome other ideas.
You could also use a stopwatch approach: count the desired clock for something like 10,000 reference clock and compute the percentage difference between the two.
I’m not sure why you’re trying to build this check into the design, if you could detail why you want to do that some more that could help.
Whether you choose to use a “reference” clock or have a counter fill and then you divide down, either way, a built-in check that uses a clock on the die will be affected by any process variations and so the results will be approximate. For this built-in assert are you planning on an external clock reference or is the concept to have everything internal to the design?
Given that variation is to be expected, and assuming that less accurate checking is acceptable(is it?), it may be good to allow for the checks to have a form to the effect of:
The goal was to have everything internal to the design. From all the responses I have seen it seems like a reference clock is needed to write an assertion for the target clock. In that case either way works, using an external reference clock or using a faster internal clock.
Using a reference clock no matter how fast will still incur some variance in measuring the clock period of the slower clock. We cannot really sample the exact time the slower clock toggled.
If somehow both the clocks synchronize, the faster clock may never sample the slower clock to be toggling at all.