Sunburst Design Book Review

Sunburst Design, Inc. Logo

Expert Verilog and Verilog Synthesis Training

     BOOK REVIEWS     
About Cliff Cummings

A Sunburst Design Book Review
Reviewer: Cliff Cummings
Review last updated: 10/16/2001

Writing Testbenches, Functional Verification of HDL Models
by Janick Bergeron

The book was great earning 3-1/2 out of 5 stars (the examples need to be debugged, tested and put online to merit 4 stars - I disagree with too many of the coding and methodology recommendations to award 5 stars). In my opinion, because the code examples are not full, because the code is not fully tested, and because not all examples are written in both Verilog and VHDL, the book is geared more to advanced users who can extrapolate the missing information and identify the mistakes in the code. The book will be best understood by experienced engineers who know both languages so that they can extract all of the relevant points. I disagree with a number of Janick's recommendations and have given my reasons in the accompanying table.

This is the first technical book that I have read from cover-to-cover (minus a couple of the larger VHDL examples). I picked up a few techniques and tricks that I had not thought of before and that I intend to use. Although I may appear to be overly critical of Janick in some of my accompanying review notes, I only do in-depth critiques of books that I deem worthy of recommending. Nice job, Janick!

A few global comments:

Nonblocking assignment is spelled without the hyphen, despite what a spell-checker says. Nonblocking is how it is spelled in the IEEE Verilog Standard and we even cleaned up the Verilog BNF in the 2001 standard to remove stray non_blocking and non-blocking BNF statements. Almost all "non-blocking" references in the book should be changed to "nonblocking." Janick uses testbench instead of test bench (and I agree) even though a spell checker does not like testbench (but it does like workbench). I believe e-mail is also preferred over email?

Janick uses a mixture of multiplexor and multiplexer in his book. Even though both are technically correct, one or the other should be used consistently throughout the book and multiplexer is by far the more common usage (search for both on the Nortel web site - Nortel even has products named "Multiplexer ...") (also look it up in most engineering texts)

A very common English-usage mistake is the incorrect usage of "a" instead of "an" in a sentence. Most Americans mistakenly believe that "a" is used in front of a word starting with a consonant and that "an" is used in front of words that start with a vowel. This is wrong. "an" is used in front of any word that starts with a vowel-sound, such as "an HDL" (pronounced: an aach-dee-ell). Visit the following website for a full explanation:

In my opinion, the Chapter Summaries in the book are useless. Janick merely re-states what topics are in the chapter. It would be much better to summarize the important guidelines that he developed in each chapter. That would make the chapter summaries awesome!

I believe I have removed from my accompanying tables, all of the typos and mistakes that Janick has already noted on his web page (by the way, great idea to maintain an errata-list web page). Please read the typos list carefully. In many cases there are already typos on the same pages, but these are different.


The following sections contain guidelines that I disagree with and coding errors that should be corrected.




xxi - last paragraph

I disagree

Self-taught (Agree) Competently-taught (disagree)

I believe a competently taught Verilog engineer will have much less area under the learning curve; however, I believe there are a large number of incompetently taught Verilog courses, many are especially lacking in the area of Verilog event scheduling and nonblocking assignments

9 - 1st paragraph


Adding OVL-style assertion checks could have caught this

16 - 1st paragraph under "VERIFICATION AND DESIGN REUSE"


"design reuse is considered the best way" - very controversial statement and I disagree.

"The reality is proving to be more problematic" - Duh! Ya-think?



Regarding false positives - VHDL can hide real race conditions

24 - Sample 2.4

Typo? - Uppercase

Janick recommends using lowercase letters for identifiers on page 330 (I highly agree - and this is a departure from what Janick used to recommend) but the warning messages clearly show that uppercase identifiers were used. Better to recommend using "_lt" suffixes, or better yet, "_lat" (_lt is frequently interpreted as "less than")



Note: 'bz extension is fixed in Verilog 2001.

33 - 2nd to last paragraph


Note: STA is not just for cycle-based simulators!

36 - 2nd paragraph


"If you were able to procure the part from a third party, you should be able to procure a model of that part as well." In my opinion, guideline: Make this a purchasing requirement for the component! If a vendor does not have a model, ask yourself, "do I have time to create a model for this part if I buy it?" It might be easier to synthesize an FPGA equivalent to gain a corresponding simulation model.

39 - end of 1st paragraph after Figure 2-11

Somewhat disagree!

"The quantity and scope of the signals whose transitions are traced, as well as the duration of the trace, should be limited as much as possible."

I somewhat disagree - time & cost of re-simulation to view signals not captured during the 1st simulation can exceed simulation time overhead and cost of additional disk space. I like Bening & Foster's recommendation to dump everything in the early debugging phase, reduce dumping in the profiling phase, and turn off dumping in the regression phase [Bening & Foster - 2nd Ed] (pp. 79-81)

39 - last paragraph


"The only time golden waveforms are truly available is in a redesign exercise." Golden waveforms can also be useful when re-coding complex modules to improve RTL synthesis. They can be used to verify equivalent functionality after making changes.

43 - Sample 2-12

Bad Example

*show a full case example

*remove full_case from the example

*remove the translate_off/on directives

"Even though there is a directive instructing the synthesis tool that the case statement describes all possible conditions, ..." YUCK! There should be all types of warnings surrounding full_case and parallel_case.

See and select the paper:

"full_case parallel_case", the Evil Twins of Verilog Synthesis

46 - 2nd paragraph


In my opinion: "Testbench Generation" tools are useful to generate efficient test cases - engineer to verify which are accurate

Pages 68-69 - Board-Level Verification


The primary objective is to verify connectivity?? Wrong! This section is full of holes. What about timing verification? Functional verification? Passive device modeling? Board-level schematics are captured to build boards. We try to use the same schematics for simulation to verify that the board being built is the same as a functionally- and timing-correct design. STA at a board level is mostly impractical. Are you going to use the same Verilog resistor model for series termination, parallel termination, pullups? There is much missing in this section.

73 - System Level Features paragraph


"Because of the large size and long runtimes of system-level simulations, it is necessary to minimize the features verified at this level." Necessary to minimize??? I'm not sure I agree. Again, it depends on the project simulation phase: Debugging phase - dump everything / Regression phase - dump nothing.

74 - Concerning "Error Types to Look For"


STA is also done after gate-level simulations. Formal verification should be a better tool to equate RTL to gates, but it's another tool, costs money and is not perfect

84 - 1st paragraph after Sample 4-2

Multiplexer - is - multiplexor

Now Janick uses "multiplexers", which I think is correct

90 - Sample 4-6

Questionable coding style

Declaring a local "reg winner" to make a sequential blocking assignment to "winner" followed by a nonblocking assignment to "grant[winner]" is pretty wacky! I give the guideline to avoid making blocking and nonblocking assignments to the same variable (does this even pass synthesis?) If nothing else, when debugging this design in a waveform viewer, it will look strange that the combinational "winner" is changing on a clock edge, the same clock edge that is going to use the just-changed "winner" value to clock the "grant[winner]" signal. I know this is done a lot in VHDL with variables and signals in the same process but I think it sucks there too! I think we are back to that long Verilog learning curve when I see this coding style encouraged.

91 - 2nd paragraph


Concerning comments, "No one can argue that reducing their number can lead to better code." As Janick notes in the next paragraph reducing some comments can be better.

92 - 1st paragraph

Comments: I disagree

"Ideally, it should be possible to strip a file of all its source code and still understand its functionality based on the comments alone." I disagree - if you are adding that many comments to your design, your coding style probably needs serious work.


Wrong: reals can be passed hierarchically

Janick states that "Whenever a real value needs to be passed across an interface, it has to be translated back and forth using these system tasks." (referring to $realtobits and $bitstoreal). Wrong, real numbers can be passed very efficiently hierarchically:

module realstest3;
   real y;

   initial begin
     yn.xn=1.5; yn.xn_1=2.5; // hierarchical assignments
     y = yn(1);
     $display("Y is %f\n", y);
     yn.xn=0.5; yn.xn_1=4.0; // hierarchical assignments
     y = yn(1);
     $display("Y is %f\n", y);

   function real yn;
     input start; // dummy start input - not used
     // static variables can be assigned hierarchically
     real xn, xn_1;
     yn = xn * xn_1;

108 - last paragraph


With respect to defining symbols, I suggest the following guidelines:

Guideline: Put macro definitions in a file and compile them first.

Guideline: minimize usage of macro definitions

I personally don't like `include very much.

(More on parameter vs. `define later)

109 - task frombits

Typo: Range [53*8:1]

The frombits task uses a different range than the tobits function. I would change it to [53*8:1] to match the tobits function.

110 - Sample 4-30

Typo: all definitions should be `ATM_cell_typ

After `define-ing the ATM_cell_typ Janick declares the tobits function range again, which sort-of defeats the purpose of defining the ATM_cell_typ to begin with. I would also show that `ATM_cell_typ is used in the frombits task.

112 - 2nd to last paragraph


Note: Multi-dimensional arrays were added to Verilog-2001

121 - Sample 4-39

Typo: Ranges [IT_size-1:0] [max-len-1:0]

Probably better to declare the MSBs in this example to be the larger numbers. Same thing on page 122.

129 - Figure 4-6


Figure 4-6: Overly simplistic simulation cycle description for Verilog

130 - 2nd to last paragraph


Last sentence of this paragraph is wrong. For most Verilog simulators higher resolution = lower performance

131 - 1st paragraph


Overly simplistic description of Verilog event scheduling. Janick's description is not guaranteed by the IEEE Verilog Standard.

131 - Sample 4-44


r <= #10 1'b1;

r = #10 1'b1;

The latter is equivalent to the VHDL.

133 - Sample 4-48


Errata: should show initialization of "do" and "done"

138 - 2nd paragraph


Janick's explanation for the origin of register is wrong! - per Phil Moorby, Verilog was invented and used before synthesis tools were invented and Phil thought that always blocks would indeed always infer registers. Oops!

138 - Sample 4-55


Note: this example has multiple procedural assignments to the same Verilog variable, which I strongly discourage!

139 - 3rd paragraph after Figure 4-9

Clarify:...and driving strength of the assignment

"... while the final value is determined by the type of wire being *used (wire, wor or trireg) and the driving strength of the assignment.*

140 - last paragraph


"In my many years of consulting in design verification, I have yet to see a single testbench that simulates with identical results on Verilog-XL and VCS."

Give me a break! Except where I have found simulator bugs, with a good coding style, I have never seen a testbench simulate differently on Verilog-XL and VCS. (Janick is heard in the distance yelling: "The sky is falling! The sky is falling!")

142 - Sample 4-58


Guideline: Should use nonblocking assignments for sequential logic

Or in this example - use $strobe instead of $write

143 - Sample 4-60

Bug: count declaration required before usage

The "integer count" declaration must precede the "assign out = count + 1;" statement.

147 - Guidelines for Avoiding Race Conditions

I disagree with #1, #3 and #4

I strongly disagree with guidelines #1, #3 and #4. There are better guidelines that should be followed. (The area under the Verilog learning curve just got bigger! "The sky is falling!")

See and select the paper:

Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!

148 - paragraph before Figure 4-13

Multiple nonblocking assignments to same variable

"Avoid overwriting previously scheduled values using non-blocking assignments" - Again I disagree! This coding style is frequently used to model FSMs with registered outputs. It works fine. Who cares if some simulators trigger an extra event off of the multiple assignments? These are registered outputs that might trigger the combinational logic more than once before the combinational logic settles before the next clock edge.

151 - Non-Reentrant Tasks

Non-reentrant tasks

Verilog - 2001 will include "task automatic" (reentrant tasks)

152 - 1st paragraph

Typo: should be:? "at address 8`had"

The last sentence should be:

"It goes on to write the value of 8'h34 at address *8'hAD.*"

(Because in figure 14.4(b), wadd=8'hAD and wdat=8'h34)

152 - 1st paragraph

Error: order not defined

In reality, the two initial blocks could be executed in any order and the actual values used by both task calls might be the values that are passed by the first initial block, not necessarily the values passed by the second initial block.

156 - 2nd paragraph after Figure 5-1


"To produce a more robust clock generator, use ..."

This coding style is not more robust, and leaves clk undefined for a half cycle at time zero. Do you want clk=X for a half clock cycle?


Excessive concern over asynchronous reset

Janick really muddies the waters showing all of these weird startup scenarios. Sample 5-12 will still have problems if any circuitry is added with low-true, asynchronous resets (setting reset to 0 at time zero using a blocking assignment inside of an initial block does not guarantee that asynchronous resets will be triggered at time 0 - however, I believe all of the major Verilog vendors schedule initial block assignments after always blocks have been activated, ensuring that this code would work, but not guaranteed by the IEEE Standard)

An easy way to handle this is:

// Free running clock oscillator where clk will be initialized to a 0 at the end of time zero,
// triggering any always blocks that is looking for a negedge clk.
// I like to start all of my testbenches with a low clk for the first half cycle
initial begin
   clk <= 0;
   forever #(`cycle/2) clk = ~clk;

// rst will be asserted to a 1 at the end of time zero, triggering any
// always blocks that is looking for an asynchronous reset.
// rst is reliably deasserted on the 2nd negedge clk
initial begin
   rst <= 1;
   @(posedge clk);
     repeat (2) @(negedge clk); rst = 0;
   // ... other commands

175 - paragraph after Sample 5-30


"It is a tool-dependent process that is different for each language and each tool." Or one could use the IEEE standard (and less efficient) VCD format that is accepted by all IEEE compliant Verilog simulators

176 - top of page (starts on previous page)


"Reducing the number of signals sampled, or the duration of the sampling, increases simulation performance." ...but might require re-simulation if a critical debug signal that was not sampled, which frequently is even less efficient than just capturing all signals during the first simulation. Again, simulation phase should drive the dumping strategy

182 - Sample 5-36

This is very confusing. What is the desired test?

I did not understand what was going on in this test, nor what the desired test was supposed to accomplish. Clarification should be added

195 - Figure 5-21


What is int delay?

Define Tx...

Response checking not labeled in the diagram

207 - Sample 5-61

Typo: ouptut/output

"*output* [31:0] address;"

213 - Sample 5-66

Design problem?

This example appears to be shifting the data in the FIFO so the next word to compare is always in fifo[0]? Instead, I believe the read pointer should be incremented in this example?

Shouldn't the response block be:

   initial begin: response
     reg [7:0] data;

     repeat (...) begin
     data = get_fifo(i); // instead of get_fifo(0)


222 - Sample 6-1

Personal preference

I prefer to put all testbench tasks at the bottom of the file. When I open a testbench file in an editor, I prefer to see test code, not subroutines (tasks). I also do not like to page down through subroutines to find my code every time I open a file.

226 - 2nd paragraph


"Do not attempt to implement all functionality in a single level. It would unduly complicate the implementation of the bus-functional models and increase the risk of introducing a functional failure."

Exception: sub-blocks. Building the full environment around each sub-block is tedious and overkill.

231 - last paragraph

Personal preference

Some simulators have problems with multiple top-level modules.

I prefer to instantiate "utility packages" in the top-level testbench

251 - 2nd to last paragraph


I would call "blocking" and "non-blocking" implementations and procedure calls something different. A "blocking" or "nonblocking" anything is a term that is pretty unique to Verilog scheduling. I would call these "active" or "queued" implementations or procedure calls

256 - bottom half of the page

Confusing text & diagrams

I did not understand what was going on in these diagrams so I just gave up

261 - Sample 6-38

Minor nit

I prefer the character count be listed first:

input[32*8:1] name; // first number represents the character count

265 - last paragraph

Yuck! - I disagree

"(I prefer the first one because ... "

Defparams should be discouraged and might be deprecated in future Verilog standards. Until recent versions of Synopsys tools, defparams were not supported by Synopsys. Defparams have multiple problems: (1) all parameters might be redefined in the last file read so vendors do not know what the parameter values are until all files have been read. (2) defparams can be used to change parameters of grand-parent modules that in turn pass the parameters right back down the hierarchical chain. (many more including undefined behavior if more than one defparam tries to change the same parameter from multiple files, etc.) Defparams are uuugly! Verilog-2001 adds the ability to pass parameters on the instantiation line by name (like named ports). This is what the Verilog Standards Group is encouraging designers to use.

267 - Sample 6-48 and the paragraph above it

Defparam abuse

Keeping defparams in a separate module?? It would be better to use `define macros and +define+ command-line switches or include files with macro definitions.

This type of defparam abuse is why defparams are being deprecated! Vendors hate this stuff!

275 - Sample 7-6

Bugs: Sample 7-6

Sample 7-6 appears to have multiple bugs:

  1. If the data bus is bi-directional, one cannot make a procedural assignment to the port (inout [15:0] data;), one will need to use a continuous assignment.
  2. data = entry >> addr[3:0] only shifts up to 15 bit positions. You need to shift up to 240 bit positions to access the entire 255-bit entry
  3. A write is made to the entry variable but never stored back into the table

280 - Sample 7-13

Better implementation

There is no need to maintain two always blocks (one that hangs with a never-ending wait statement) in this example. One always block with a nested forever loop will work just fine. I don't like to see assignments to the same variable from more than one procedural block (one of my guidelines). Try this:

always begin: main
   count = 0;
   forever begin
   strobe <= 1'b0;...

Now a reset can just "disable main;"


-F yuck!!

I like the -f option but the entire discussion about using the -F option should be removed. Paths to remote manifest files? A script to parse the manifest files? This looks like a real bad idea

319 - Section on "Put a Makefile with a default 'all' target in every source directory"

I disagree!

Yuck! This is tedious overkill and a maintenance pain. If an engineer is too dumb to first change to the tb directory create an mverilog alias to put the engineer into the correct directory before executing the simulation.

321 - top of page


" A front-end script can also *handle* the case where a file is included more than once in a simulation through separate references in different manifest files."

Not true: compiling the same module name twice is a syntax error unless ugly `uselib directives are used or Verilog-2001 config files are used. This is very misleading.


Add a guideline

In general, avoid included files, they tend to be missed when transferring designs to other engineers or to EDA tool support teams.

322 - paragraph under "Use a trailer comment ..."

Alternate guideline

"Because these can become quite lengthy, put revision history at the bottom of the file."

Or just keep a short log header in the file and use RCS commands to see the full history.

Development file printouts get too long with the full history attached to every file.

323 - "Use a minimum of three ..." section

I disagree

I prefer two spaces for each indentation level. I have never found two spaces to be too narrow and I also like to indent all of my procedural blocks inside of modules, which Janick apparently does not do. I also generally like putting "begin" on the same line as the procedural block header or test statement that starts the block and then I line up the "end" statement with the procedural block or test keyword. These are all personal preferences but calling two spaces "too narrow" is a stretch.

324 - "Limit line length to 72 characters ..."

?? - examples do not correspond to topic?

The example in this section does not seem to support the 72-character limit topic that is being discussed.

327 - Examples at the top of the page

Bad Example

Give me a break! Good concept but bad example. I would use the first code ("poor ... usage") over the (""proper use"") example any day! For a better example, use a testbench write task example.

332 - top of page

Personal preference

"Separate words using an underscore; do not separate words by mixing uppercase and lowercase letters." This is a personal preference that should probably be left to individuals as opposed to Janick trying to drive the industry to his own preference.

332 - Identifiers

Give me a break!

"Do not use reserved words of popular languages"

This is way over planning. I can't believe Janick wants engineers to fret over a word possibly in use as a key word in another language.

332 - Use meaningful names ...

Give me a break!

"Avoid acronyms or meaningless names. Using at least five characters ..."

Again, this is way too picky. I again can't believe that Janick is going to have some poor junior engineer fretting over counting the number of characters in his identifiers to make sure they meet some arbitrary recommendation. I like the following example just fine:

assign {co,sum}=a+b+ci;

334 - Constants

Not defined "magic"

"Use symbolic constants instead of "magic" hard-coded numeric values."

I don't know what Janick means by "magic". Janick might want to explain his intended meaning

336 - Filenames

Strongly disagree!

I strongly disagree! My guideline: make file root names match module names (what Janick labels as "poor file naming"). If the file names match the module names, it is easy to read all of the design files using the -y switch.

"Using postfixes with identical root names causes all related files to show up next to each other when looking up the content of a directory."

What?? These files are in different directories per recommendations made on pages 318-319.

337 - Layout

Strongly disagree!

"Group port declarations that belong to the same interface."

I strongly disagree! All Verilog primitives list ports, outputs, data inputs, controls. There might be some designs where interface partitioning makes sense, but for the most part, I prefer seeing all of my outputs grouped first, data inputs grouped second, etc. I can mentally sort my design better this way. If you want to comment the interface signals based on ports, I don't have a problem with that. Some ports drive or are driven by multiple interface blocks and fretting over how to do the groupings is a waste of time. This should not be a very big deal.

337 - Labeling all processes

Somewhat disagree!

I somewhat disagree! Required labeling is tedious, adds scope and is typically removed by compilers to improve performance (At least in Verilog - I know Janick is talking about VHDL here)

340 - Verilog specific

Give me a break!

"Start every module with a `resetall directive"

"Make sure your module name is unique"

These requirements are tedious & overkill. These are not big problems. Janick must be paid by how many lines of code he writes ;-)

341 - Top of page

Give me a break!

I strongly disagree! A clock cycle definition is an important global definition. A local parameter cycle definition is inappropriate for something that is global to an entire design.


The following typos are not listed on Janick's errata page as of 10/16/2001. For a list of additional errata, visit the following web site:




26 - 1st paragraph after Sample 2-5

Typo - is/are

The least significant bits *are* ...

46 - 1st paragraph


Awkwardly worded - should be reworked

46 - 2nd paragraph

Typo tool/tools

"One interesting aspect of these *tools* ..."

48 - 4th paragraph

Typo: a HDL/an HDL

See global comments above

52 - 3rd paragraph



See global comments above

62 - 1st paragraph


Add a footnote to describe "barnacle"

67 - 3rd paragraph

Typo: for the/for

"They form a natural partition for ** verification ..."

67 - 4th paragraph

Typo: by the/ by

Inderminant "they"

"The ever increasing densities offered by ** semiconductor technology ..."

(Later) "... , they are often designed ..." (expand "they")

68 - 2nd paragraph

Awkward: system-level... -or- the system level verification testbench

"The system-level verification focuses on ..."

Replace with: "System-level verification focuses on ..."

Or with: "The system-level verification testbench focuses on ..."

71 - 2nd paragraph

Typo: input signals/input signal

"... apply zeros and ones to every input *signal* in the design."

74 - last two paragraphs

Typo: a RTL/an RTL (global)

76 - 2nd paragraph

Typo: group of feature verification/ group of verification features

"Each group of *verification features* forms a testcase."

77 - 1st note on the page


Note does not match the paragraph discussion

78 - last paragraph

Typo: values/value

"use a programmable constant input *value* instead of ..."

78 - last paragraph

Typo: multiplexor/multiplexer

Should use multiplexer - See global comments above (global typo)

84 - Sample 4.1 - 1st point

Typo?: combinatorial

Should this be "combinational"?? I seem to read more references to combinational instead of combinatorial.

84 - 1st paragraph after Sample 4-2

Multiplexer - is - multiplexor

Now Janick uses "multiplexers", which I think is correct

90 - 1st paragraph

Typo: problem are/ problem is

"Another potential problem *is* the race ..."

113 - last paragraph

Typo: be is to/be to

"One solution would be ** to hardcode ..."

114 - 1st paragraph

Typo: the number of changes to code that has to be/ the number of code changes that have to be

"... the number of *code changes that have* to be reused ..."

116 - paragraph after Sample 4-35

Typo: are/is

"If access time to various elements *is* your primary concern, ..." (If access time is - NOT - If access time are)

125 - 3rd paragraph

Typo: of describing/to describe

"Connectivity is the ability *to describe* a design using ..."

125 - 3rd paragraph

Typo: perfect examples or a perfect example

"Schematic capture tools are perfect *examples* of ...


"Schematic capture tools are *a* perfect example of ...

125 - last paragraph

Typo?: SystemC

I believe the "s" on SystemC is capitalized?

127 - 4th paragraph

Typo: desert/dessert

desert - hot dry place

dessert - a sweet and tasty culinary dish

Janick has just created a recipe for a hot dry place!

128 - 2nd paragraph

Typo: can/could & constructs/construct

"... you *could* always write a model with one more parallel *construct* than you have processors available."

128- last paragraph

Better: it/the simulator

"Unlike a multi-tasking operating system, *the simulator* assumes that ..."

130 - last paragraph

Typo :axis/axes

"The state of the simulation progresses along two *axes:* zero-time and simulation time."

152 - 1st paragraph

Typo: should be:? "at address 8`had"

The last sentence should be:

"It goes on to write the value of 8'h34 at address *8'hAD.*"

(Because in figure 14.4(b), wadd=8'hAD and wdat=8'h34)

154 - last paragraph

Typo: non-portables

"... can make Verilog models *non-portable* ..."

155 - 2nd paragraph

Typo: the output/output

"... The final part of this chapter covers techniques for communicating the predicted ** output to the monitors."

175 - paragraph after Sample 5-30


"It is a tool-dependent process that is different for each language and each tool." Or one could use the IEEE standard (and less efficient) VCD format that is accepted by all IEEE compliant Verilog simulators

187 - Sample 5-42 note

Typo: wrong note

The test case is handling the failure, not the procedure

190 - 2nd paragraph

More introductory info required

Give a brief explanation of why a read operation starts with a phase-2 clock

190 - paragraph after Figure 5-18

SWAP: wait & valid bus timing

In the first sentence, it sounds like Janick is saying that one does not need to enforce a particular number of wait states and that one DOES NOT need to adapt to any valid bus timing. The sentence is improperly ordered. I had to re-read this sentence multiple times to understand Janick's point. Better:

"With behavioral models of the operation, you *can adapt to any valid bus timing because you do not have to enforce a fixed number of wait states.*"


Typo: a n!/an n!

See global comments above

200 - 2nd paragraph

Typo: takes/take

"The input operations *take* as argument ..."

200 - 2nd paragraph

Typo: argumen/argument

"... or procedures in VHDL, take as *argument* the value expected ..."

207 - Sample 5-61

Typo: ouptut/output

"*output* [31:0] address;"

209 - 1st paragraph

Typo: exception/exceptions

"Another could be used to specify whether to force one of the target termination *exceptions*."

211 - 3rd paragraph

Typo: worse/worst case

"... may not stress the design under *worst case* conditions."

226 - 3rd paragraph

Better wording?

I think Janick means the following in the 2nd sentence of this paragraph?

"If the procedural interface to the harness BFMs is well-defined and can support different physical implementations, the physical interface of a design can be modified without having to modify any test cases."

226 - 4th paragraph

Typo: a X86/ an X86

See global comments above

227 - 3rd paragraph

Add a note

To the left of the 3rd paragraph, I would add the note: "Start with a simple testbench and refine it."

250 - 2nd paragraph after Sample 6-25


"Once the bus-functional procedures are moved *into* a module ..."

258 - last paragraph

Typo: in providing difference/ by providing different

"... in various ways and "by providing different* data sequences."

259 - top of page (starting on bottom of previous page)

Wording? It/using external files...they/ using external files

"It also shows how to properly configure reusable verification components and *using unique output file names to ensure that simulation results are not clobbered."

259 - 3rd paragraph

Typo: time/times

"... they offer a technical solution to minimizing the number of *times* a model is compiled or initialized."

277 - Sample 7-8 note

Typo: process/processes

"Behavioral *processes* have to be reset"

283 - top of page

Typo: node/nodes

"... be routed by different switching *nodes*, each node must have an ..."

289 - 2nd paragraph

Typo: a RTL/ an RTL

See global comments above

294 - 2nd to last paragraph

Typo: design/designs

"It is very likely that different scripts have to be used for different *designs*.

298 - Note after Sample 7-29

Typo: toward/towards

"The -F option is a good start *towards* a solution."

306 - 1st paragraph

Typo: file/format

SDF stands for Standard Delay *Format* (not file). An SDF file is not redundant.

Go to and look at the title for "Unapproved Draft P1497 ..."

307 - Sample 7-45

Explanation of $test$plusargs is missing

Janick should probably explain the $test$plusargs system function before using it in Sample 7-45

320 - last paragraph

Typo: handles/handle

"A front-end script can also *handle* the case where a file is ..."

321 - 4th paragraph

Minor Typo: extra space between "complete" and "relative"

Extra space between "... using a complete **relative pathname."

351 - Index

Missing entries

harness & manifest index entries should be added. These are names Janick invented so he should help people find their definitions according to Janick.