In reply to bmorris:
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.
Agree; this is because they both deal with verification.
Quote:
- 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?
Agree
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?
But isn’t the verification plan a black box plan that deals with the requirements, whereas a tesplan is way to test the item, and that may include the hierarchical black boxes? Thus, if the implementation has an IP that does the FFT, or a UART, the testplan should include a line that states that all integrated IPs should have been tested prior to incorporation into the black boxes. The test planner could take the vendor’s promise at face value, or he could add additional tests. The test plan should also include tests that verify the interfaces an interactions with the rest of the design.
Years agao, I had the bad experience of purchasing a GM truck that turned out to be a lemon, as modular parts started to fail at rapid paces (oil pump, generator, starter, water pump, …). The first night I had the truck, oil dripped profusely all over the garage, and that fix entitled a major replacement of a part (3 days in the shop)!
Obviously, GM was OK in the requirements (what parts are needed to make a truck for that model year), bu the test plan and test implementation were pretty much F**Ked up!
Ben Cohen SystemVerilog.us