|
The verification problem gets more difficult every day and the industry continues to meet the challenge with ever more innovative tools that mostly address specific issues we face. Meanwhile, as an industry executive, do you know what gains your extended teams are getting out of these tools? Do you know how to tell when the job is completed and bug free? Do you know if all these point tools are being used effectively within a broader solution?
What about your most valuable and complex resource: your team of professional engineers? Are they properly motivated? Are they properly trained? Do they communicate effectively? Do they fully leverage each other's expertise like a team should? Do they report back to management so team leaders can make required adjustments based on timely project data? Is your design or project ready for tape out? How do you know"?
This article is the first of a three part series focusing on how the new field of metric-driven engineering will improve design and verification processes. The next two installments will take a closer look at metric-driven engineering from a team leader and user's point of view.
Requirement Awareness
One of management's top concerns should be "Have all the requirements on this project been successfully addressed?" Even more fundamentally, "Do we know what all the requirements are?" It's fairly common in design projects to discover requirements from various stakeholders late in the project. Depending on what these new requirements are, they can wreak havoc with the project schedule. For example if a major customer intends to use the UART bus to download boot code to the on chip processor, and your designers didn't implement a DMA channel between the UART and instruction memory on the device because they were unaware of the marketing requirements -- then you have a problem.
Design Intent Translation
The Venn diagram shown below is frequently used to describe the verification process.
'Design intent' represents what the device was originally intended to do when it was first conceived. 'Functional specification' represents the document that captures the communicated design intent. 'Implementation' represents the hardware and software that was actually implemented. Verification is described as the process of making sure that these three sets converge. This simple diagram obscures one key concept however. How does each stakeholder work within the overall plan or translates the design intent.
Each stakeholder is unique and their varied understanding of the design intent, (and even the functional specification for that matter), can have a detrimental effect. I can think of one recent project where disaster was narrowly diverted. Two adjacent blocks in a design were to communicate using a protocol that optionally allowed the engineer to implement it using either a serial or a parallel data bus. The engineer of block A had decided to implement the communication protocol between his block and block B using the serial option. The designer of block B had decided to use the parallel option. They both had sound reasoning that told them the other engineer would 'obviously' make the same choice, except they didn't. Fortunately this issue was found before any hardware was implemented. But if it was found at the block integration stage, improper planning and management would have been blamed for creating a very costly debug cycle.
Planning and its Effects on Requirements and Translations
Requirements collection and design intent translations are successfully addressed when using an effective planning methodology. New project planning methodologies develop a plan based on team leaders input and objective measurements that track the resulting plan. It's really pretty simple. Each stakeholder provides the criteria needed for successful verification of the device " these verification planning meetings should take place in the same to be most successful. An interview process is used wherein the designer first draws a block diagram of their device and then begins to describe the design feature by feature. As each feature is described, management prompts each stakeholder to express their concerns about the feature. These concerns include how they think the feature might break as well as how they intend to make use of the feature.
This brainstorming process serves two purposes. First, the requirements of each stakeholder are captured in the verification plan. Second, during the brainstorming, the various translations of each feature of the device are leveled. The parallel/serial conundrum mentioned above was discovered in this manner.
|
