Sunburst Design Book Review

Sunburst Design, Inc. Logo

Expert Verilog and Verilog Synthesis Training

HOME

PAPERS

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: www.dictionary.com/doctor/faq/a/a-oran.ntml

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 http://www.janick.bergeron.com/wtb/errata.html (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.

Page	Note	Comment
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 - 1^st paragraph		Adding OVL-style assertion checks could have caught this
16 - 1^stparagraph 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?
18		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")
25-26		Note: 'bz extension is fixed in Verilog 2001.
33 - 2^nd to last paragraph		Note: STA is not just for cycle-based simulators!
36 - 2^nd 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 1^st 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 1^st 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 - 2^nd 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* http://www.sunburst-design.com/papers and select the paper: "full_case parallel_case", the Evil Twins of Verilog Synthesis
46 - 2^nd 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 - 1^st 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 - 2^nd 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 - 1^st 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.
102	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); end function real yn; input start; // dummy start input - not used // static variables can be assigned hierarchically real xn, xn_1; yn = xn * xn_1; endfunction endmodule
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 [538:1]*	The frombits task uses a different range than the tobits function. I would change it to [538: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 - 2^nd 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 - 2^nd to last paragraph		Last sentence of this paragraph is wrong. For most Verilog simulators higher resolution = lower performance
131 - 1^st paragraph		Overly simplistic description of Verilog event scheduling. Janick's description is not guaranteed by the IEEE Verilog Standard.
131 - Sample 4-44		Replace: r <= #10 1'b1; #10; With: r = #10 1'b1; The latter is equivalent to the VHDL.
133 - Sample 4-48		Errata: should show initialization of "do" and "done"
138 - 2^nd 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 - 3^rd 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	Exaggeration!!	"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 http://www.sunburst-design.com/papers 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 - 1^st 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 - 1^st 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 - 2^nd paragraph after Figure 5-1	Opinion!	"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?
161-163	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; end // 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 2^nd negedge clk initial begin rst <= 1; @(posedge clk); repeat (2) @(negedge clk); rst = 0; // ... other commands end
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	Clarification	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) expect(data); end $finish end
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 - 2^nd paragraph	Exception	"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 - 2^nd to last paragraph	Terminology	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[328: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: 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. 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 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;"
298-299	-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	Wrong!	" 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.
321 - GENERAL CODING GUIDELINES	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:

http://www.janick.bergeron.com/wtb/errata.html

Page	Note	Comment
26 - 1^st paragraph after Sample 2-5	Typo - is/are	The least significant bits are* ...*
46 - 1^st paragraph	Awkward	Awkwardly worded - should be reworked
46 - 2^nd paragraph	Typo tool/tools	"One interesting aspect of these tools* ..."*
48 - 4^th paragraph	Typo: a HDL/an HDL	See global comments above
52 - 3^rd paragraph	Typo?:email/e-mail (global)	See global comments above
62 - 1^st paragraph		Add a footnote to describe "barnacle"
67 - 3^rd paragraph	Typo: for the/for	"They form a natural partition for * verification ..."*
67 - 4^th paragraph	Typo: by the/ by Inderminant "they"	"The ever increasing densities offered by * semiconductor technology ..."* (Later) "... , they are often designed ..." (expand "they")
68 - 2^nd 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 - 2^nd 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)	www.dictionary.com/doctor/faq/a/a-oran.ntml
76 - 2^nd paragraph	Typo: group of feature verification/ group of verification features	"Each group of verification features* forms a testcase."*
77 - 1^st 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 www.nortelnetworks.com (global typo)
84 - Sample 4.1 - 1^st point	Typo?: combinatorial	Should this be "combinational"?? I seem to read more references to combinational instead of combinatorial.
84 - 1^st paragraph after Sample 4-2	Multiplexer - is - multiplexor	Now Janick uses "multiplexers", which I think is correct
90 - 1^st 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 - 1^st 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 - 3^rd 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 ... -or- "Schematic capture tools are a* perfect example of ...*
125 - last paragraph	Typo?: SystemC	I believe the "s" on SystemC is capitalized?
127 - 4^th 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 - 2^nd 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 - 1^st 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 - 2^nd 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 - 2^nd 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."
192	Typo: a n!/an n!	See global comments above
200 - 2^nd paragraph	Typo: takes/take	"The input operations take* as argument ..."*
200 - 2^nd 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 - 1^st paragraph	Typo: exception/exceptions	"Another could be used to specify whether to force one of the target termination exceptions."
211 - 3^rd paragraph	Typo: worse/worst case	"... may not stress the design under worst case* conditions."*
226 - 3^rd paragraph	Better wording?	I think Janick means the following in the 2^nd 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 - 4^th paragraph	Typo: a X86/ an X86	See global comments above
227 - 3^rd paragraph	Add a note	To the left of the 3^rd paragraph, I would add the note: "Start with a simple testbench and refine it."
250 - 2^nd paragraph after Sample 6-25	Typo:in/into	"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 - 3^rd 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 - 2^nd paragraph	Typo: a RTL/ an RTL	See global comments above
294 - 2^nd 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 - 1^st paragraph	Typo: file/format	SDF stands for Standard Delay Format* (not file). An SDF file is not redundant.* Go to http://standards.ieee.org/catalog/design.html 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 - 4^th 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.