High level paper written by Chris Komar of Cadence discussing Assertion-Based Verification do's and don'ts.
- Focus on a productive subset of the assertion language instead of the entire assertion language.
- Consider using a library that contains common components and design constructs that make it easy to get started with ABV.
- Consider the big picture and leverage assertions across the entire flow.
- Consider reuse for common interfaces within your design with components that are parameterizable.
- In simulation, complement your assertions with coverage. Assertions describe the functionality of the design not how the stimulus is stressing the design.
- Spend much time worrying about which assertion language since they offer the same functionality only with different syntax.
- Corner yourself into one assertion language because assertions will come from multiple places that use multiple assertion languages.
- Write assertions for all aspects of your design. Focus on areas that are considered higher risk.
- Be afraid to simplify by using simple VHDL or Verilog/SV to generate easier and more familiar conditions to check.
- Wait to introduce assertions. Designers should write white-box assertions in their code while verification engineers should write block level assertions and end-to-end transactors.
Programmable Logic DesignLine | How to adopt assertion-based verification (ABV) into standard design flows