Cool Verification

Listening to the discussion about UVM extensibility today on the Accellera VIP-TSC call, I was reminded of a great post from Steve Yegge of Google.

It's *very* long, but a good read. In summary, Steve proposes that there are two competing world views when it comes to programming:

"Conservative" programming views

1. Software should aim to be bug free before it launches.
2. Programmers should be protected from errors. 
3. Programmers have difficulty learning new syntax. 
4. Production code must be safety-checked by a compiler. 
5. Data stores must adhere to a well-defined, published schema. 
6. Public interfaces should be rigorously modeled. 
7. Production systems should never have dangerous or risky back-doors. 
8. If there is ANY doubt as to the safety of a component, it cannot be allowed in production 
9. Fast is better than slow. 

"Liberal" programming views

1. Bugs are not a big deal. 
2. Programmers are only newbies for a little while. 
3. Programmers figure stuff out amazingly fast when their jobs depend on it. 
4. Succinctness is power. 
5. Rigid schemas limit flexibility and slow down development. 
6. Public interfaces should above all else be simple, backward-compatible, and future-compatible.
7. System flexibility can mean the difference between you getting the customer (or contract) vs. your competitor nabbing it instead. 
8. Companies should take risks, embrace progress, and fiercely resist ossification. 
9. Premature optimization is the root of all evil. 

Steve's point is that everyone falls somewhere on the spectrum between conservative and liberal (programming), whether they realize this or not.

On the Accellera VIP-TSC, and often in our everyday verification work, each of us often has debates where one side or the other claims a technical position assuming their position is based on a fundamental law of nature. It can be useful to admit to yourself that there are different views of acceptable programming practices, and there are pros and cons of each. Understanding this can improve your interaction with your team members, and can allow a team to more efficiently make conscious decisions about preferred styles as we move through a development process.

Update January 18, 2013

I appreciate the responses to this post. The Accellera folks have been able to fill the slots needed for the UVM Tutorial at DVCon. So no more responses are required! 

--------

Have you spent some portion of the last year or two adopting the UVM verification methodology? Would you be interested/able to present your experiences to the wider verification community as part of a tutorial session at DVCon next month in San Jose? If so, please contact me directly ASAP. 

Back in August I wrote a post here on Cool Verification called The $10,000 ASIC about a question I was posing to folks at DAC last summer about whether you could produce a prototype of an advanced chip for a total EDA tool and design/verification IP cost of $10,000.

Lou Covey from New Tech Press has spent the last several months investigating this question and has posted the first in a series of articles and interviews - this time with Gary Smith of Gary Smith EDA:

Gary Smith considers the quest for the $10K chip

In the interview, Gary mentions that it's relatively common to do 2M gate designs to the prototype stage in a couple of months with a budget of just shy of $30K. But he also mentions that it takes upwards of $29M to complete a "very good design". Additionally, investors are more likely to invest in chip design start-ups when the cost involved is closer to $25M.

I'd still like to know if you could reduce the tool and IP costs for the $29M project down to my mythical $10K mark, would it make the chip easier to design and verify, and more palatable to investors?

I'm looking forward to the rest of Lou's series to see what others have to say on the topic!