Hardware book like "Code Complete"?

Discussion in 'VHDL' started by Davy, Jul 20, 2006.

  1. Davy

    Davy Guest

    Hi all,

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

    Thanks!
    Davy
     
    Davy, Jul 20, 2006
    #1
    1. Advertising

  2. Davy

    fp Guest

    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.

    Davy wrote:
    > Hi all,
    >
    > Is there some hardware RTL book like "Code Complete" by Steve
    > McConnell?
    >
    > Thanks!
    > Davy
     
    fp, Jul 20, 2006
    #2
    1. Advertising

  3. Davy

    Eric Guest

    > 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!
     
    Eric, Jul 21, 2006
    #3
  4. 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

    Eric wrote:
    > > 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, Jul 21, 2006
    #4
  5. Eric wrote:

    > 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
     
    Mike Treseler, Jul 21, 2006
    #5
  6. Davy

    Andy Guest

    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
     
    Andy, Jul 21, 2006
    #6
  7. Davy

    JJ Guest

    Mike Treseler wrote:
    > Eric wrote:
    >
    > > 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


    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
     
    JJ, Jul 21, 2006
    #7
  8. Davy

    Guest

    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.

    > Andy wrote:
    > 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
     
    , Jul 21, 2006
    #8
  9. On 20 Jul 2006 18:51:11 -0700, wrote:

    >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

    http://www.MYCOMPANY.com

    The contents of this message may contain personal views which
    are not the views of Doulos Ltd., unless specifically stated.
     
    Jonathan Bromley, Jul 21, 2006
    #9
  10. Davy

    Phil Tomson Guest

    In article <>,
    Mike Treseler <> wrote:
    >Eric wrote:
    >
    >> 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.


    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
     
    Phil Tomson, Jul 21, 2006
    #10
  11. Davy

    Bob Perlman Guest

    On 21 Jul 2006 04:42:09 GMT, (Phil Tomson) wrote:

    <Stuff snipped>
    >
    >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
     
    Bob Perlman, Jul 21, 2006
    #11
  12. Davy

    Ted Guest

    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
     
    Ted, Jul 21, 2006
    #12
  13. Davy

    Guest

    >Jonathan Bromley wrote:
    > On 20 Jul 2006 18:51:11 -0700, wrote:
    >
    > >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.

    > 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
    >
    > http://www.MYCOMPANY.com
    >
    > The contents of this message may contain personal views which
    > are not the views of Doulos Ltd., unless specifically stated.
     
    , Jul 21, 2006
    #13
  14. Davy

    Jon Forrest Guest

    Eric wrote:
    >> Is there some hardware RTL book like "Code Complete" by Steve
    >> McConnell?


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

    --Jon-
     
    Jon Forrest, Jul 21, 2006
    #14
  15. Davy

    Andy Guest

    wrote:
    > ... 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
     
    Andy, Jul 21, 2006
    #15
  16. Davy

    Tommy Thorn Guest

    Andy wrote:
    > 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
     
    Tommy Thorn, Jul 21, 2006
    #16
  17. Davy

    Guest

    Andy wrote:
    > wrote:
    > > ... 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.

    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.

    > Andy
    >
     
    , Jul 21, 2006
    #17
  18. wrote:

    >> 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.


    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.

    >> 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.


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

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

    > 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
     
    Mike Treseler, Jul 21, 2006
    #18
  19. Davy

    Andy Guest

    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
     
    Andy, Jul 22, 2006
    #19
  20. Davy

    Guest

    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.

    Andy wrote:
    > 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
     
    , Jul 22, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    0
    Views:
    523
  2. wallge
    Replies:
    5
    Views:
    631
    Bill Mills
    Jan 24, 2007
  3. Patrick Kowalzick
    Replies:
    5
    Views:
    492
    Patrick Kowalzick
    Mar 14, 2006
  4. Replies:
    14
    Views:
    752
    Flash Gordon
    Nov 20, 2007
  5. Replies:
    0
    Views:
    341
Loading...

Share This Page