Ben,
Thank you for your input.
It sounds as though the verification plan is the low level, bread-and-butter spreadsheet that allows the environment builder to create the appropriate coverage collectors, and for the test writer to know which tests to generate etc. Great description of test plan. It sounds as though everyone has a slightly different impression of the names.
- The “verification requirements” should link to design requirements ?
Generally agree, can you elaborate more on this?
The design requirements, I.e. the functionality recipe (spreadsheet) that the design engineer is using to create the RTL implementation. Every line item from this design requirement spreadsheet should be mentioned at least once somewhere in my verification plan (in the form of an number: E.g. 1.2.). Agree or disagree?
Lastly, my impression was that the verification plan is NOT free of implementation. The design team has the liberty to implement RTL free of stipulations (design requirements shall be free of implementation), but the verification team will be handed a selected implementation. Much like the UART “test plan” from Mentor’s coverage cookbook, if I am verifying a DUT with a FIFO, I may added SVA constructs to check behavior of the FIFO when it is written while full, etc. If I include these design assertions in my verification, they are in the implementation category. thoughts?