Hardware book like "Code Complete"?

[Davy]

Hi all,

Is there some hardware RTL book like "Code Complete" by Steve
McConnell?

Thanks!
Davy

 

[fp]

Try the text "RTL Hardware Design Using VHDL:
Coding for Efficiency, Portability, and Scalability."
A sample chapter on FSM can be found in

http://academic.csuohio.edu/chu_p/

Hope this helps.

S.C.

 

[Eric]

Is there some hardware RTL book like "Code Complete" by Steve

McConnell?

I don't think so, but that would be super cool if there was. Have you
considered writing one?

My impression is that hardware people don't like to write much, and
even if they do, they don't have time to sit down and document all of
the important "big issues" that new people need to learn in order to be
effective.

But if anyone writes a book like this it will fly off the shelves!

 

[Weng Tianxiang]

Hi Eric,
It is not because hardware engineers are lazy, but most of what they
have written for any interesting projects are properties of their
companies that prevent them from disclosing, not mention writing a
book.

SunMicro system published their CPU core with 350K code lines. If there
is a retired Sun engineer who had involved in the design and will write
something about the CPU project, I would like to be the first one to
order his book. Nobody can read a CPU design with 350K code lines and
at the same time without comments and introductions.

Weng

 

[Mike Treseler]

But if anyone writes a book like this it will fly off the shelves!

A few hundred copies would fly off the shelves.

There's probably about 10,000 digital designers
in the US. Not all of those do hardware description
and not all of those write their own RTL.
Those are not numbers that would excite
a major publisher.
Writing and editing a book is two long years
of work, whatever the subject.

-- Mike Treseler

 

[Andy]

Too bad the author is a proponent of the ancient style of separate
clocked and combinatorial processes in VHDL. He even uses a third
process for registered outputs.

I think he needs to discover what variables can do for you in a clocked
process.

Andy

 

[JJ]

A few hundred copies would fly off the shelves.

There's probably about 10,000 digital designers
in the US. Not all of those do hardware description
and not all of those write their own RTL.
Those are not numbers that would excite
a major publisher.
Writing and editing a book is two long years
of work, whatever the subject.

-- Mike Treseler

And even in a metro hub like Boston, MIT Cambridge area, a good book
store inside the Microcenter hardly ever sold any of these Hardware
books to any of us, the books were really too expensive at $70-$150 &
up so were mostly browsed (and dated). They dumped them at $10 a pop
instead and now stick to the VB, Java, Web, & ofcourse "Code Complete"
stuff that does move.

Softbooks in Marlboro also moved on sigh.

When you visit DAC & other big hardware design events, you can often
talk directly with several fine publishers, they are often quite eager
to talk to would be authors too. They also have all the relevant and
upcoming books in their booths with a modest show discount too.

I get the impression that unless you are writing for the college
market, the payback for the author would never cover the time spent.
And by the time you are ready to write, the subject is already changed.

John Jakson
transputer guy

 

[mikegurche]

I believe that separating the FSM into a combinational logic and a
register is the first guideline for coding state machines in "Reuse
methodology manual" by Keating.

Mike G.

 

[Jonathan Bromley]

I believe that separating the FSM into a combinational logic and a
register is the first guideline for coding state machines in "Reuse
methodology manual" by Keating.

It could well be that you are right.

Someone's going to have to work pretty hard to convince me
that such a split has any benefit for reusability. As I and
many other contributors to this group have noted on
numerous occasions, splitting a design of any kind into
combinational logic and a bunch of registers is a sad
waste of the expressive power of RTL.

Every synchronous design is a state machine in party dress.
Am I expected to write the whole of every design in the
two-process FSM style?

I have no intention of allowing pedantic coding guidelines to
force me into writing my designs as a bunch of isolated
flip-flops dangling on the side of a mess of combinational
logic, with its inevitably restrictive rules and coding style
limitations.

Decoding glitches on outputs, unexpected combinational
feedthrough paths from input to output, unwanted
combinational feedback, unpredictable clock-to-output
delays, unnecessary declarations of next-state signals
cluttering the top level of your modules, artificially clumsy
coding styles to assure freedom from unwanted latches -
all these can be yours, merely by following the textbooks'
advice to split your logic into combinational and registers.

Two-process FSMs for re-use? Hmmmm.

You HAVE a choice
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Phil Tomson]

A few hundred copies would fly off the shelves.

There's probably about 10,000 digital designers
in the US. Not all of those do hardware description
and not all of those write their own RTL.
Those are not numbers that would excite
a major publisher.
Writing and editing a book is two long years
of work, whatever the subject.

In the software world if it took two years to write a book the content
would be seriously outdated by the time the book came out. A lot of the
publishers of software books (O'Reilly, The Pragmatic Programmers even
APress now) are aiming for a six month cycle. In fact those publishers
have now gotten the idea of selling pre-release titles as PDFs: you buy
the pre-release PDF early for a reduced fee so you have access to the
content and then later on when the final book comes out you get the paper
version for an additional fee. That way your readers can access time-sensitive
information early on.

The other issue with hardware books like this is that the market is
relatively small (I'm guessing that the ratio of software engineers to
hardware engineers is at least 30:1). It
could be a good opportunity to self publish where
you publish not paper books but PDFs (this is happening on the software side).
Then instead of having to pay $70 for a title because the audience is
small, the author charges $20 for a pdf and gets to keep all of it instead
of getting a small royalty from a publisher. If you manage to sell 1000
of them you've made $20K and that's generally a lot better than what you'd
get from a publisher. One publisher (The Pragmatic Programmers) even
publishes mini-books which are less than 100 pages (not paper, pdf only)
which they sell for $8 to $10. It wouldn't be hard to write 100 pages in
2 to 3 months (part-time even).

Phil

 

[Bob Perlman]

On 21 Jul 2006 04:42:09 GMT, (e-mail address removed) (Phil Tomson) wrote:

The other issue with hardware books like this is that the market is
relatively small (I'm guessing that the ratio of software engineers to
hardware engineers is at least 30:1). It
could be a good opportunity to self publish where
you publish not paper books but PDFs (this is happening on the software side).
Then instead of having to pay $70 for a title because the audience is
small, the author charges $20 for a pdf and gets to keep all of it instead
of getting a small royalty from a publisher. If you manage to sell 1000
of them you've made $20K and that's generally a lot better than what you'd
get from a publisher. One publisher (The Pragmatic Programmers) even
publishes mini-books which are less than 100 pages (not paper, pdf only)
which they sell for $8 to $10. It wouldn't be hard to write 100 pages in
2 to 3 months (part-time even).

Self-publishing on actual, old-fashioned paper has become surprisingly
affordable of late. Take a look at lulu.com or blurb.com and be
amazed.

Bob Perlman
Cambrian Design Works
http://www.cambriandesign.com

 

[Ted]

In the Wallace & Gromit film "The Wrong Trousers", Gromit uses a book
called "Electronics For Dogs" to help him convert the NASA
technotrousers to remote controlled operation. Is this the kind of
thing you had in mind?

Cheers
TW

 

[mikegurche]

I believe that separating the FSM into a combinational logic and a
register is the first guideline for coding state machines in "Reuse
methodology manual" by Keating.

[ ommitted]

Decoding glitches on outputs, unexpected combinational
feedthrough paths from input to output, unwanted
combinational feedback, unpredictable clock-to-output
delays, unnecessary declarations of next-state signals
cluttering the top level of your modules, artificially clumsy
coding styles to assure freedom from unwanted latches -
all these can be yours, merely by following the textbooks'
advice to split your logic into combinational and registers.

I agree that good code depends on your understanding of hardware rather
than any "coding style." Either one- or two-process style will be
fine if you know what you are doing. But the two-process style is
easier to understand and less error-prone, especially for a novice
user.

BTW, "Reuse methodology manual" is not a textbook. It is written by
two veterans in two major EDA companies. I have the second edition and
it indicates the first author is the VP of engineering for design reuse
group of Synopsys and the second author is the director of R&D for IP
in Mentor Graphics.

Mike G.

 

[Jon Forrest]

It's not exactly the same but "The Pentium Chronicles" by
Robert Colwell is worth looking at.

--Jon-

 

[Andy]

... But the two-process style is
easier to understand and less error-prone, especially for a novice
user.

In what ways is a two-process style less error prone? Let's see:

The two-process style is infinitely more prone to latches.

The two-process style is more prone to simulation-synthesis mismatches
(sensitivity list problems).

The two-process style requires twice as many signals to be declared and
managed.

The two-process style simulates slower (more signals, more events, more
processes sensitive to more signals, and fewer processes that can be
combined in simulation), allowing less simulation to be performed and
more errors to go undetected.

The two-process style encourages combinatorial outputs (touted as one
of the prime benefits of 2-process descriptions), which have
less-predictable clock-to-out performance than registered outputs.
Besides, if you really need combinatorial outputs, you can code them
from your synchronous processes if you use variables for the registers.

The two-process style encourages a net-list approach to design, rather
than a functional approach. It is important to know what kind of
hardware gets generated; it is more important to understand the
functionality of that hardware.

Andy

 

[Tommy Thorn]

Too bad the author is a proponent of the ancient style of separate
clocked and combinatorial processes in VHDL. He even uses a third
process for registered outputs.

I think he needs to discover what variables can do for you in a clocked
process.

Really? Which of his arguments do you disagree with?

I always thought of the two-process style as being redundant, but after
reading Dr. Chu's argument, I'm revising my thinking. For one thing,
this style makes it much less disruptive to change a Moore output to a
Mealy and vise versa.

My thanks to S.C. for the reference. Good one.

Tommy

 

[mikegurche]

In what ways is a two-process style less error prone? Let's see:

The two-process style is infinitely more prone to latches.

Not if you assign default values to all signals in the beginning of the
process.
On the other hand, in one-process code every signal within the clocked
process infers an FF, regardless you need it or not. A variable within
the clocked process may infer an FF (if used before assigned) or may
not (if assigned before used).

The two-process style is more prone to simulation-synthesis mismatches
(sensitivity list problems).

Missing a signal in sensitivity list for combinational circuit is a bad
practice and has nothing to do with one or two processes.

The two-process style requires twice as many signals to be declared and
managed.

This is true. It is a small price for clarity.

The two-process style simulates slower (more signals, more events, more
processes sensitive to more signals, and fewer processes that can be
combined in simulation), allowing less simulation to be performed and
more errors to go undetected.

The two-process style surely simulates slower. However, since the code
is in RTL level, not synthesized cell net list, it should be tolerable.

The two-process style encourages combinatorial outputs (touted as one
of the prime benefits of 2-process descriptions), which have
less-predictable clock-to-out performance than registered outputs.
Besides, if you really need combinatorial outputs, you can code them
from your synchronous processes if you use variables for the registers.

The clock-to-output delay is only important in the "boundary" of a
relatively large subsystem . Two-process style allows you to add
buffer in any place (the buffer can be grouped within the register
process), including any desired output. Except for the "boundary"
of a large system, an output buffer is not needed within the system if
it is synchronous. Blindly adding output buffers wastes resource
(additional FFs) and penalizes performance (one extra clock delay for
the output signal).

The two-process style encourages a net-list approach to design, rather
than a functional approach. It is important to know what kind of
hardware gets generated; it is more important to understand the
functionality of that hardware.

I disagree. I feel that it is more important to understand the
hardware structure in RTL level, particularly for synthesis.

Mike G.

 

[Mike Treseler]

Not if you assign default values to all signals in the beginning of the
process.

True, but if you forget one, you have an error.

On the other hand, in one-process code every signal within the clocked
process infers an FF, regardless you need it or not. A variable within
the clocked process may infer an FF (if used before assigned) or may
not (if assigned before used).

Sounds like using a variable is more flexible. I'm sold.

See rising_v.strobe in http://home.comcast.net/~mike_treseler/rise_count.vhd
for an example of an asynchronous node within a synchronous process.

Missing a signal in sensitivity list for combinational circuit is a bad
practice and has nothing to do with one or two processes.

I disagree. For one process, the sensitivity list is always the same.

This is true. It is a small price for clarity.

It's clear to me, that with one process,
I don't need any signals at all.

-- Mike Treseler

 

[Andy]

Mike,

So, what you're saying is that if the (novice) user goes to the extra
trouble of definining default assignments, and correctly managing the
sensitivity list, then it is easier for him to design/code that way?...

The whole point of using variables in clocked processes is that you can
have either behavior you like (registered or combinatorial), in one
process. In fact, the variable itself does not infer combo or
register, each access to it does. The same variable can represent both
via two different references to it. A reference to the variable can
even represent a mux between the combo and registered value. The whole
point is, the synthesizer will generate hardware that behaves exactly
like it simulates, using combinatorial and/or registered logic to do
so.

Even combinatorial RTL code simulates faster than gate level code (the
ulimate extension of combinatorial code), but that is not the issue.
Simulating RTL that consists almost entirely of clocked processes
approaches cycle based simulation performance in modern simulators
(that merge processes with same sensitivities). You can simulate many
more corner cases in RTL than gate-level, and many more than that if
you code almost exclusively with clocked processes.

Depending on the target choice and synthesis approach (top-down or
bottom-up), the argument over combinatorial ouptuts from modules (i.e.
state machines) may be more or less important. The bottom line is
you'll have fewer timing problems if combinatorial paths don't cross
hierarchical boundaries (though some tools and methods minimize those
problems). The argument of a performance hit by incurring a clock
delay on registered outputs is nonsense for outputs decoded from states
(not from inputs). In all such cases, it is possible to recode those
outputs to be registered with the exact same clock cycle performance as
with combinatorial outputs.

My point about netlist vs functional is more about level of
abstraction. We're aren't going to improve productivity by continuing
to focus on "this is the combo logic, that is the registers". Adopting
single process descriptions using variables for registers and
combinatorial logic allows one to move up the ladder, abstraction-wise.
Of course, you still have to have an idea of what is going to happen at
the gates and flops level, but you needn't focus on it.

Andy

 

[mikegurche]

Andy,

Thank you for your response and I see your point of functionality and
level of abstraction.

But using lower level of abstraction (i.e., separating comb logic and
register) has its advantage. For example, if we want to add scan chain
(for testing) to a synchronous system after completing the design, we
can simply replace the regular D FFs with dual-input scan FFs in a
two-process code. This will be messy for one-process code. Another
example is to use a meta-stabile hardened D FF for synchronization.

I am not an expert in verification, but I believe the two-process code
helps formal verification as well. It is the guideline presented in
"Principle of verifiable RTL design" by Bening and Foster (The
summary is in http://home.comcast.net/~bening/Broch10f.pdf. It's
written for Verilog, but the idea is there). They even go to the
extreme to suggest that all memory elements should be separately
instantiated. This is may be one reason that "Reuse Methodology
Manual" I mentioned in an earlier message also recommends two-process
style.

Mike G.