Review

Initial Reaction

Brilliant!

The cover brought me straight to (xiii) (About the cover), which I read fully. This is a great technique for getting people into the book and gives your readers an essence of how important verification is. The 'bridge' itself I think is a symbol very relevant to verification (I use it all the time).

On flicking through the book, I liked the initial layout. There is a hierarchical format of the data (sections + left hand margin). This I think is crucial and even necessary for engineers. I can get the point straight away without necessarily going into the detail. This means that as an advanced engineer, I can skip over sections that I'm familiar with and as a learner I can easily flip back to certain sections i.e. quick reference. Good logistics.

I don't like the back of the book. Too many lines which cut the main points.

General Comments

Footnotes: The footnote specs in the pages cause some type of line dislocation. The can be distracting. Also, Footnote page sync is not consistent. e.g. p117 footnote 4 appears on next page).

Author's comment: Many have complained about the increased line spacing when a subscript is used. I could not figure out how to fix it in FrameMaker. Footnotes will float to the next page if there is not enough room at the bottom of the page where it is first referenced.

Most of the software, systems that you mention are UNIX based. I think if you included a few references to Windows based products, it could balance things up (From you opening comments, I assume that you're not a huge Windows' fan) - but some of your audience could be. I've included some references below that you can use, if you wish.

Overall the book is of an excellent quality

Comments

Chapter 1

Page 2 : Last Paragraph. It may be useful to have references to the 70%, two verification to 1 design , type of figures.

Page 3 : P 4. What is a 'backhoe'? A special kind of hoe? Probably need a more generic term like digger.

Page 8 : P 4. Equivalence checking can also be used if a minor functional change needs to be made without the need for synthesis. E.g. Inverting the polarity of a signal by replacing a buffer in the netlist and a modifying a signal assertion in RTL.

Page 16 : P 4. Design for verification can also include bringing internal signals to external interfaces for observability. It can also drive high-level partitioning so that high-level components can easily be interfaced together for sub-system verification. You can probably come up with a better phrase for it.

Chapter 2

Page 48 : P5. It may be useful to quote some Windows based produces e.g. perForce or even Web based products like Teamtrack.

Page 52 : Issue Tracking I think that this section is missing a bit on what exactly it is you are tracking. You have the different mechanisms in place but a section on what you are tracking is just as important. If you find a bug for instance, then where the bug was found is important, how it was found it also important e.g. I remember before making an issue of a bug that was introduced in a graphical Entry tool that appeared late in the verification phase. The 'Where the bug was found' field generated a global action to change Graphical Entry Tool standards.

I know that the list of things to track changes from organisation to organisation and they can be grotesquely verbose to say the least ("Designer's Wifes' first car make" type of thing), but I think that the important things should be noted.

Another point on issue tracking is to define a formal platform of when to start tracking. When debugging e.g. untested code with an untested test bench (horror!), this could make your bug tracking 'top-heavy'.

Chapter 3

General. It may be useful to have a diagram of this plan, e.g. specification->Features, Features->TestCases etc.

P63 : Last Paragraph. Good definition of RTL Designer's responsibility.

Page 67 : P5. Traditional FPGA verification had always had a 0-Bug Tolerance. It's just not worth it in the lab.

Page 70 : Last Paragraph. Some responses are also difficult to recognize by humans AND are difficult to verify in simulation. A good example of this is a DSP design e.g. A linear feedback filter which performs many calculations and after several multiplication's, you don't know where you are.

Page 81 : P2. You should probably reference Pages 95/96 here as examples of the testbench producing regular notice messages. From my own experience I had the following methodology

Name	Handle	Description
Verbose	%V	Verbose information, useful for debugging a test case. The level can be set as a simulation parameter. Defaults to no verbose messages being displayed.
Non-Verbose	%I	This represents a general structure of a test algorithm and should represent no more than 20-30 lines per test. e.g. Starting Register Test Verifying Initial Values Verifying Normal Registers (12) Verifying Read-Rest Registers (8)
Warnings	%W	Warnings
Errors	%E	Errors

Chapter 4

Page 86 : P2. Another good example of this would be in a MAC function e.g. A := A + B*C; This is one line of code but to implement it with wallace trees and adders could be 100's of lines of code and consists of several levels of hierarchy. Reducing the levels of hierarchy means less files, less structural RTL and probably less errors! So this is an advantage of behavioral coding.

Page 87 : P1. A reduction of 40 what? (Also I assume that you're using a writing guideline of numbers 1-9 = One to Nine) but the sentence "40 in the synthesizeable version to two in the behavioral one, or a 1900 percent" doesn't flow well.

Author's comment: The synthesizable description will execute 40 times (20 for each process) if there are 10 clock cycles between the request and acknowledge. The behavioral description will only execute twice since it is not sensitive to the clock.

Page 96/97. It may be useful to have 'information' messages as I mentioned previously as part of this

Page 100. One useful data abstraction mechanism that I find useful and I don't see in this section is using enumerated data types.

e.g. rdata := readRegister(regInterrupt1)

• It can make your test bench code more readable
• It imposes restrictions on how they can be used and you can have more syntactically correct code
• Having enumerated types and constants in packages can help with the reviewability of the test bench e.g. the enumerated types make the test algorithms easier to review and a single package containing enumerated types can also be easier to review.

Page 112 : P2. While VHDL Records are useful, they need to be specified well with someone who has an understanding of reusability and object oriented techniques. I have seen but fortunately have never had to review or change code where huge records containing dislocated control fields were the so-called back bone of the verification.

Another point about records is their poor performance in that if they are used in sensitivity lists, then any bit changes cause the process to be run. Again, I've seen simulations running very slow with code structured like this.

One of the other drawbacks I've also seen is with observability. With modelsim, you can see records no problem but with leapfrog you couldn't. (I'm not sure with NC-VHDL)

Chapter 5 : Stimulus and Response

Page 178 : Para 2. An example of Windows equivalent tools are Windiff, Visdiff or even the primitive dos command 'fc' (File compare) .

Page 180 : Para 2. I'm confused by your statement, 'In reality a reference model never works'. Are you talking here about Behavioral models as reference models. If so, of course they work. They can

• Increase simulation performance
• Be used to debug test benches

Again my simplest and clearest example is writing behavioral models for DSP components. The implementation of a digital filter can be a huge undertaking with different low architectures tuned and tweaked for speed or power. A behavioral model can be written very quickly and simulate very quickly. Effective system level verification can be achieved using these substitute models.

From some other things you've written you're adamant that you need to leave RTL behind when it comes to writing behavioral models, a different mindset entirely e.g. RTL++, I think you called it. For verification, we need to be flexible though and sometimes it's being able to do the RTL++ at the necessary levels. For the DSP example, coding a HDL reference model is necessary for an effective verification strategy.

Am I missing the point of this paragraph or is there something missing?

Author's comment: If you are missing the point of this paragraph, then there is something missing. Behavioral model must be modelled with all necessary levels of accuracy (but mo more). If latency and bit-accuracy are important, then a "RTL++" style may be called for.

Page 189/190 : CPU Operations. I think it would be a good idea to give an example of a higher level of abstraction can be build around the bus models e.g.

Function	Description
Read(Address)	Reads and returns data from the address
Read(Address, Expected Data)	Reads and returns data from the address and verifies that it's equal to the expected data.
Read(Address, Expected Data, Mask)	Reads and returns data from the address and verifies that it's equal to the expected data where the mask bits are set to '1'
Read(IntegerAddress, Expected Data)	Reads and returns data from the address (specified by and integer) and verifies that it's equal to the expected data. This can be useful for iterating through address.

Writes could have the same structure.

Chapter 6 : Architecting Test Benches

Page 221 : Reusable Verification Components. The importance of this last paragraph gets lost between samples 6-1 and 6-2. I think you need more on what it gives you. Reusable Verification components are probably more important than reusable logic components because of the 70% stuff.

To introduce people to reusable verification components you could refer back to pages 95-96. Your reporting mechanism. This is probably the most widely used low-level verification component. Other things that exist at this level are conversion functions etc. For normal verification I include a standard test bench package (as I assume most people do by now) to give power to the verification process. I've seen a 'Check' package recently which standardises how checking is done as a methodology. These are very important low-level components.

On the higher-level (and still not too high) a great OO technique is to use functions that have a well defined interface but different implementations

Read(Address)
Read(Address, Expected Data)
Read(Address, Expected Data, Mask)
Read(IntegerAddress, Expected Data)

So a standard register test would look almost the same.

As far as I know. LMC had very standardised procedures for their BFM's so it was easy to write tests for any of their models.

Page 227 : P2. Very important!

Market Focus

It definitely clarifies the normally grey area of verification. It can benefit novice HDL designers by giving them a clear picture on their role in verification and it can further them into the verification process.

I would also recommend this book to anyone involved in the verification area as it serves to remind us what we're supposed to be doing.

Good focus for VHDL and Verilog

Poor focus for Windows based platforms.

Summary

Overall a good read, with an excellent view of the verification process. It's a very good achievement to get work of this quality in one of the least understood areas of hardware design.