REFERENCE - THE JANE SERIES
CHAPTER 1 - THE VERIFICATION PLAN FROM HELL
We should be integrating all the new blocks of RTL we are currently designing sometime early next week, so it’s time we started to think about pre-silicon. I’m assigning Tom and Bill to the job along with you; Bill has experience in debug, since, between you and me, his first Asic was a failure, and Tom is a recent college graduate that were not sure what to do with, so we’ve told him that if he does a good job on this, we may accept him to the design team.
I don’t want any of those fancy tools, which are supposed to speed things up, let’s stick to good old Verilog for the new stuff, and you should be reusing components from the old design which are written in Vhdl, c, Perl, and Tcl, so it should be a piece of cake.
Also, I want to clear up all this talk about getting in a expert verification consultant to help us set things up. We all know how to do verification, so we don’t need someone telling us how we should do our job.
The last thing I want to hear about is functional coverage, what a waste.. we all know we can accomplish all of our goal with the good old tests, we’ll run automatic tool for toggle coverage at the end of the project to see that we didn’t miss anything.
Since we want to use the environment for Post-Silicon, make sure all your checkers are completely external to the design, and adhere closely to the requirements of the post-silicon guys.
For your development, I want you to use the THX2000 specification, which is currently being written. Since design time is critical, I don’t want your team asking the architects too many questions.
The last project spent over a year developing the environment for the THX1000, and 20 people in all wrote the 2000 tests. We are counting on the legacy tests for most of verification, so it should be a simple task just to port them to the new interfaces and protocols, we’ll use “diff”s to assure they’re still on track. After the 5th spin those test proved to be quite efficient at getting the silicon out relatively bug-free, and we’ve already invested years in them, so we can’t risk loosing them.
You’ll be reporting directly to the rtl-design manger, so we don’t have any conflicts of interest.
To improve quality, we decided we are measuring designer’s performance by how many bugs your team reports for their block. In addition we’ll be charting indicators on how many bugs your team has in the environment.
Since we know verification is mainly a resource problem, if you fall behind we will assign 10-20 people to it during the critical time. You’ll need to support them in test writing with the environment you create. The design team will be completely freed up to write tests and work part time on their blocks as well as run synthesis and work on backend. Also, the RTY department has some interns they say they can spare for a few weeks for testing, and in addition we can hire short-term contractors to write some tests, shouldn’t be any problem finding good verification engineers, all they need to know is how to write some verilog and it doesn’t even have to be synthesize-able, so how hard could that be.
Most of the hard verification work we’ll do on an FPGA, so your job should be a breeze. You don’t need to waste any time on random, since that will be accomplished in the FPGA. But you’ll need to support recreating the bugs in simulation.
The schedule is pretty tight on this, since we plan to finish the coding so quickly, I expect you can be done with the verification in the span of 4-6 weeks; all you need to do is write some interfaces, port some tests and write a few tests for the new protocols.
As you know, we’ve always placed the utmost importance on verification. To keep morale high, your goal should be 0 bugs in first silicon. You have a key role in the success of our product, Jane, I know you can do well!
Design right. Verify right. Ace Verification
About Us | Careers | Contact Us
Copyright © 2006 Ace Verification Corp. All rights reserved.