The most common approach to quality in most engineering teams is event-driven. Designers work in silos, focused on register transfer level (RTL) creation and limited functional testing, with little objective measurement of quality or completeness. Milestone integration events force some higher level of testing, still with limited objective metrics or visibility. And so on, up to full system integration. Latent problems accumulate everywhere. The measure of completeness is largely subjective and, when the time comes to "fix quality" at any of these events, it is not surprising that team leads waive previously agreed-to objectives, sight unseen, in deference to schedule.

These designers are as quality-conscious as any others; their problem is not in intent, but in approach. Like it or not, semiconductor design in the early 21st century has more in common with an assembly line than a research lab. An assembly line with occasional checkpoints to "fix quality" would be down most of the time. That they function smoothly is only possible because manufacturing engineers know, in advance, exactly how they define quality, and they continuously monitor and correct quality problems, at the source. This continuous monitoring is often labeled continuous quality control (CQC).

Some may argue (and a depressing number still do) that this level of monitoring is unnecessary for semiconductor design. After all, teams tape out and build chips without this approach. It is equally true that you can get a car through an assembly line, eventually, without CQC. Eventually, you can work your way through most problems. But semiconductor markets and companies in 2009 have little tolerance (if they ever had it) for "eventually".

A handful of quality leaders is already adapting. These design teams are aggressively adopting CQC processes. Regressions are run every night and, importantly, results from each regression are automatically emailed to all stakeholders. This frequent and closed-loop monitoring provides no opportunity for problems to fester, or corners to be cut.

Across the range that regression suites provide coverage, every problem becomes immediately visible and actionable. Quality becomes manifestly every designer's responsibility, not just the responsibility of the verification and implementation teams.

Equally these teams know in advance exactly how they are going to define quality. Those metrics are rigorously followed no matter what twists and turns the design may take. A common mistake they avoid in their automated monitoring systems is to report only those steps for which results are available.