Any thoughts on verification

[Altera_Forum]

I believe we have posted a lot on design itself but little on verification. Verification is a very vague area and I have serious personal problems in reconciling with some elements of the current verification culture. 

 Here are my general points on verification in a nutshell: - verification may take 60% of work, design 40%, a meaningless rule of thumb easier said than proved. - an expensive well tested product that is late to the market is useless. - a design engineer may get biased to pass his/her design, this is no joke. Some companies have separate verification specialist engineers(as opposed to RTL engineers). Other companies are not interested in your testing plans and leave you free, they simply and fairly want a quick-to-market working design.  - the current verification ideal targets a fully-automated testbench. Just plug-in your design and it passes or fails… rubbish - the ideal plan requires correct set of stimuli, correct independent model to generate outputs followed by comparison. Great. - modules vary considerably that any generalisation is pointless. - many functionalities require other tools or languages to get reference output. Many such tools will not interface easily with HDL. - In my real working life, I have seen many legacy project files named testbenches in unknown folders. They never worked for me when I wanted to make changes and test them(regression testing). - the verification culture favours simulatable HDL like a ritual and it hates RTL. Yet the final testbench code is an uncontrolled mosaic of synthesisable and non-synthesisable code.  - imported IPs are sold with their testbench which is never fully automated. - simulation is part of verification, a further confusion of terminology as usual. - non-rtl modelling of entire systems is a further major task undertaken by some. - non-synthesisable HDL needs a different mindset and may ruin the RTL thinking. - How do we test our testbench. Then how do we test the test of the testbench?   My first objection in this verification dilemma is at the input side and is to do with stimulus generation. The verification people generate their input test stimuli using non-synthesisable code. But why do it that way in FPGAs? If we are always designing in RTL why on earth not design the test stimuli in RTL. After all this is what the input module will do exactly. RTL is easier, more accurate representation of actual input module, and shouldn’t take much space or time.(exception to this is clk generation of course and asynchronous signals before they get synchronised)  Do you use RTL stimuli or not and why? Please share your views on verification.   kaz