Review

• an overwhelmingly pragmatic focus.

• the tool-independent verification methodology. Tools are useful, but as you point out, no substitute for planned verification processes. Being able to map a methodology to a variety of tools as they emerge is vital.

• the structure of the book, with the annotated paragraphs and a very logical flow, makes it an admirable textbook. I think everyone teaching digital design should recommend to every student that they buy this book (even BEFORE buying a Verilog or VHDL syntax book) and READ and RE-READ your chapters 1-3 BEFORE ever learning a line of Verilog or VHDL syntax. This would set the philosophy of the verification approach to design (and 'design for verification') right up front in students' minds, which is vital.

• In the above sense, I think the book has wider applicability in teaching digital design than you give credit for in the preface 'Reading Paths'. I think every student (and of course lecturer) should understand Chapters 1-3. In fact, due to the 'lack of planning' for verification traditionally, I think you should emphasise more that it is a must for everyone to read in your Reading paths. (or in your publicity).

• the focus on hierarchical verification, from unit testing through the system testing, and the 'orthogonalisation of concerns' approach to verifying different features at the different levels of testing.

• the planned use of your web site and verification mailing list to give people access to more extensive examples, useful code utilities, errata, discussion etc. This is a very good idea, and a good idea to mention frequently through the book as you have done.

• the emphasis in chapter 4 on using behavioural HDL constructs for testbenches, thus liberating the synthesis-minded from all their normal restrictions. In addition, the emphasis on abstractions of design intent so that a design under verification is actually verified with a different implementation of their design intent rather than just a repeat of the implementation! Of course, this is 'motherhood' in design but I thought that your examples, and hammering on this point, was quite effective. In addition, the use of abstraction in creating test cases to allow efficiency in creation, and to keep the testbench at the abstraction level of the design objects (packets, frames, etc) was well described.

• the chapter 6 on architecting testbenches, with the packaging of testcases, utilities, test harnesses etc. I thought was bang-on. Given the differences between Verilog and VHDL, I thought that the fact you covered both in depth important. In fact, in some senses (I am a top down person) I think it would be better to read chapter 6 before chapter 5, in that designing and architecting the verification approach first, before considering the details on stimulus/response, is a more logical 'flow' for a top down kind of person. You of course say this in the beginning of chapter 5! (but I chose to read it linearly). But the chapters 5 and 6 are nicely structured such that they could be read in either order.

• chapter 5 on stimulus and response - actually this holds for all the chapters - lots of examples of code implementing your recommendations, and well structured to avoid unnecessary length while still getting the points across. Interesting to note that in a talk on IP reuse I saw at the India VLSI conference on Friday, given by Raul Camposano of Synopsys, the verification strategy he recommended had strong correlations with your chapter 5 especially the attention to self-checking testbenches, modeling expected responses, and complex output monitoring and comparisons.(of course, he had no details).

• chapter 7 on simulation management: clearly, the emphasis on creating behavioural models of designs (for more reasons than early debugging of testbenches of course). This fits in well with any top-down 'systems' approach to design. For that reason, again, this is a topic that deserves presenting to all readers earlier in the book!! (not waiting till simulation management chapter). But I think p. 269-289 are a very good explanation of behavioural modeling characteristics and rationale, especially the section p. 286 on the benefits of behavioural models. Actually, I would give even more weight to the 'audit of the specification' to one of finding errors and ambiguities in the specification. This whole section on behavioural modeling should be read by people planning the verification process, ie back at chapter 3.

• the configuration management section of chapter 7 is a good one. See comment below on applying revision management to testbench sources. Also the section on regression suites - very important.

Suggestions for improvement, in a subsequent version or a follow up book:

• Your discussion of revision control, configuration management and issue tracking in Chapter 2 seems 100% design centric. It may seem obvious, but of course the testcases/testbenches themselves, as well as the design files, of course need to be part of the revision control/configuration management/issue tracking, albeit with slightly different policies (for example, it is probably NOT a good thing to let designers modify testbenches for good, but as you point out, it may be fine for verification engineers to modify design files.....or at any rate a somewhat asymmetric policy may be best). I think this is at least worth stating in this section. Or maybe at the end of Chapter 3, the verification plan, where you talk about verifying testbenches and mention Code reviews - this might be a good point to re-state that testbenches, like the design code, need to have management/revision/config policies and systems....

• a little more about the relationship between functional verification and manufacturing test and in-service diagnostics would be interesting. Although Chapter 1, Testing vs. Verification, makes the distinction clear, there is more of a practical relationship between them than you intimate. It may be true of course that for better or worse, all you have for an IP block for mfg test is a set of functional test vectors (legacy issues) - although I would argue that in that case, design or buy a new block! not always practical. In addition, hierarchical system level diagnostics may reuse both mfg test and functional test suites. However, I agree that spending more time on this in your book would have been diverting from the main focus. Probably a good subject for a very different book!