( ESNUG 340 Item 8 ) --------------------------------------------- [1/19/00]
From: "Zain Navabi" <navabi@ece.neu.edu>
Subject: ( ESNUG 337 #8 ) Help! Cliff Did A "Playboy" Review Of My Book!
Dear John,
In this email I would like to take a few minutes to react to the review of
my book "Verilog Digital System Design" that appeared in ESNUG Post 337.
Essentially, Cliff Cummings did a Playboy review of my book; he only looked
at the pictures and didn't read anything.
It appears that Cliff only just scanned the Verilog code in the first part
of the book. His comments appear based on Verilog code samples and appear
completely out of context with the text written around the code. And, as
you know, John, the design process includes strategy, documentation,
simulation and synthesis. Verilog is used not only for synthesis, but also
for simulation, test bench generation, and hardware modeling. But before
one can use Verilog, he or she must know what simulation is, how simulation
handles timing and concurrency, what to expect from synthesis, how a design
is partitioned, what constructs of the language to use for various parts of
a design, and above all, you have to know hardware. This is why I write
text (that Cliff ignored) that explains all these concepts to newbies.
Let me address Cliff's concerns point by point:
> It is also common courtesy to correctly spell the names of companies...
The first printing of the first edition of any new book has a few typos. We
try to avoid this as best as we can, and those that are not caught before
the first print usually make it for the second printing.
> The first two code examples in the book are not Verilog. What's the
> point?
It is not the first two code examples; it is the first three code examples
that are not Verilog. One is ISPS, one is VHDL and one is AHPL. These are
in Chapter 1 where a general overview of HDLs is given. Readers will see
lots of Verilog code in the rest of the book; it is good for a reader to
see some other old and new languages as well. "What is the point?" The
point is specifically discussed in the text part of the book and would have
become clear if Cliff had read the text of the book in this chapter. A
figure's caption is not the place to say why a figure is being presented!
> Figure 1.5 shows the book's first "Verilog description". Unfortunately
> the example is not Verilog, it is VHDL.
The text in the section that this figure appears presents VHDL as a means
of describing hardware at the structural level. I suggest that Cliff read
the paragraph before that figure.
> Indeed, the book appears to be a VHDL book that has been translated to
> Verilog (poorly). There is a definite VHDL flavor to the book.
I agree that there is a definite hardware flavor to the book. VHDL and
Verilog are both ways of describing hardware, so a correspondence is only
natural. After all, both languages are intended to describe the same
hardware, so why wouldn't one be the translation of the other?
> * The pseudo code description at the top of page 62 uses VHDL
> variable assignments.
Another statement out of context, and clearly indicates that Cliff has not
read the book and has only glanced at what appears to him to be code. As a
matter of fact, that snippet happened to be Pascal partial code. The line
above these statements mentions software languages. I was showing how
things are done in a software language; therefore software language
notations are used.
> * The state machine code on page 55 is even a poor coding style
> for VHDL.
That happened to be an example for continuous assignments with right hand
side conditions. A case statement construct would not be a good example
for showing syntax and semantics of the condition statement construct.
Cliff's comment here does not consider why the code is being presented and
where in the book the code appears.
> * Figure 10.16 (page 298) VHDL-like verbose assignments
>
> ac <= 8'b00000000;
> mar <= 12'b000000000000;
>
> The more Verilog-like way to make these assignments is:
>
> ac <= 8'h0;
> mar <= 12'h0;
I am being very explicit. Instead of using the implicit zero padding, all
bits are specified. This is writing for students new to HDLs, remember?
This format clearly shows how to assign of any bit pattern to the left
hand sides. A "ac <= 8'h0;" and "mar <= 12'h0" wouldn't show this to a
new Verilog student.
> The first actual Verilog example of the book shows up on page 34. Far
> too many silly diagrams and pseudo-code examples occupy the first 33
> pages of the book.
Diagrams are there to show a top-down design process, they only look "silly"
if one does not understand why they are being presented. Actually reading
the text helps! The title of this chapter is "Design Methodology Based
on Verilog" and is not to be regarded as a Verilog tutorial. Design
methodology the focus here.
> The use of nonblocking assignments in the book is inconsistent and does
> not follow common recommendations.
Nonblocking statements are used in examples only after the concept of
nonblocking has been discussed. All examples use correct semantics of the
language. I suggest that Cliff write a paper about a new language and
present his "common recommendations" without explaining the basic syntax
of his new language. Only then might he understand the importance to
teaching basic syntax first and then giving recommendations.
> Many of the early Verilog examples emphasize Boolean equations...
That is because the early parts of the book is for describing
Boolean expressions and the structure of components is being presented.
It's part of the language.
> The reader is developing the wrong habits early in the book.
Easier material is presented first. Readers are not expected to stop on
the first part, as Cliff did, but to go beyond that. This is not a
reference book; it is a book with flow and a specific mission. Examples
are built as constructs of the language are presented. Examples in the
later parts of the book are built upon constructs presented in the earlier
parts of the book.
> The UDP flip-flop in figure 5.15 on page 97 is wrong. Table entries...
That simple example was to serve the purpose of showing UDP syntax and
semantics of sequential tables. The necessary declarations were shown in
this figure, a partial syntax tree is shown in the next figure, and edge
specification formats are shown in the next after that.
> A full Boolean description for a bit comparator in Figure 5.24. Why?
> If one is trying to design everything using gate primitives, this might
> be a good reference book.
Once again, it is important to read the book and see for yourself why an
example is being presented. Without reading the book, this information is
hard to extract. Figure 5.24 is not a Boolean representation, it is a
structural representation based on language primitives. The section that
this example appears in is "5.2 Wiring of Primitives". This series of
examples is used to illustrate the use of primitives, how wired logic is
formed, ways that timing parameters are specified, and ways that primitive
strengths affect outputs. I can only use examples that are based on
primitives to illustrate issues related to language primitives.
> In Figure 6.8 (page 137), using a 'include to include a task is silly.
You include a modular code so that the code does not have to be repeated in
every description that it is being used. This way if you decide to modify
the code you only have to do it in one place. This is a simple coding issue
taught in many beginning programming courses.
> A casez instruction would have greatly simplified the example in figure
> 8.9 on page 188.
This section is on continuous assignment and condition statements. Figure
8.4 shows the syntax tree of continuous assignments and Figure 8.7 shows
that of a condition expression. This figure illustrates the use of right
hand side condition expression is a continuous assignment. Why would I use
a casez statement if this is not what is being discussed? Treatment of case
statements including their syntax details appears in Chapter 9.
> The treatment of state machines in section 8.3 is pathetic. Ignore the
> coding style shown in this section. The state machine code described
> at the top of page 247 and shown in Figures 9.32 and 9.34 includes an
> initial block to handle the reset. It's both bad & non-synthesizable.
> Initial blocks are not synthesizable and should generally only be used
> inside of a testbench.
The three categories of a synthesis subset are "Supported", "Not Supported",
and "Ignored". Synthesis tools ignore initial blocks, and it is not wrong
to use these statements in synthesizable code. Note that these examples are
not presented as synthesizable descriptions. Initial blocks are useful for
pre-synthesis simulation of state machines that do not have any hardware
resetting mechanisms. This section presents a basic state machine and adds
to it in the later sections. Without a resetting mechanism, the only way
to simulate is to use an initial block. With resetting mechanism, it is
still a good practice to use initial blocks. Page 252 shows a state machine
with an asynchronous reset.
> RTL coding styles are almost absent from this book.
Chapter 8 lays out RTL style of coding and Chapter 9 shows more ways of
describing RT level components. Chapter 10 shows a complete CPU designed
at the RT level.
I think it's very important to understand that this is not a cookbook nor
was it ever intended to be used like one. If you do read it that way,
I'm sure you'll get into all sorts of trouble like my poor reviewer
Cliff Cummings did here. I don't mind my book being judged, I just
hope that who's judging it actually reads it.
- Zain Navabi
Northeastern University Boston, MA
|
|
