Identify the building blocks of the design. Such as state machines, FIFOs, counters, linked lists etc. Again, implement covers to estimate how many cycles it takes to reach interesting states of these building blocks. A good exercise would be to code covers for all the state transitions of a state machine inside your design. These covers will fetch you enough information to estimate how many cycles are required to cover the logic for the entire state machine. Once you have the depth details for all the interesting states of various building blocks used in your design, do your math (mostly add) as per their arrangement of these building blocks in the design. This step will most likely increase (say by 𝚫a) your RPD from the previous step.
Cover interesting corners
Now comes the most important of listing the functional coverage targets for interesting corners of the design. You will need a lot of brainstorming here. Work with designers and your fellows in the verification team to identify those interesting corners of the design which will take longest cycles to hit. Once the list of functional coverage targets is ready, code them as covers, run the covers and arrive at the depth which will be required to hit that last mile in the design. Again, this step will most likely increase your RPD from the previous step (say by 𝚫b)
That’s it, calculations done! RPD = N + 𝚫a + 𝚫b
We now have a goal in the form of RPD to achieve and formally sign-off the design. So, if the achieved proof depth of your assertions has already exceeded RPD, you are good to sign-off.
But, wait, just like our math exams, it is always a good habit to validate your calculations to be sure. Refer to section V, subsection D, E, F of the DVCon paper for ways to validate your RPD calculation. The paper includes two detailed case studies to help understand the process of calculating required proof depth in detail.
Question from the case study, validation steps? — #AskOski