FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > VHDL

VHDL comp.lang.vhdl newsgroup / Usenet

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 07-20-2006, 03:21 PM
Davy
Guest
 
Posts: n/a
Default Hardware book like "Code Complete"?

Hi all,

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

Thanks!
Davy

Reply With Quote
  #2 (permalink)  
Old 07-20-2006, 10:23 PM
fp
Guest
 
Posts: n/a
Default Re: Hardware book like "Code Complete"?

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


Reply With Quote
  #3 (permalink)  
Old 07-21-2006, 12:10 AM
Eric
Guest
 
Posts: n/a
Default Re: Hardware book like "Code Complete"?

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

Reply With Quote
  #4 (permalink)  
Old 07-21-2006, 12:26 AM
Weng Tianxiang
Guest
 
Posts: n/a
Default Re: Hardware book like "Code Complete"?

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!


Reply With Quote
  #5 (permalink)  
Old 07-21-2006, 01:07 AM
Mike Treseler
Guest
 
Posts: n/a
Default Re: Hardware book like "Code Complete"?

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
Reply With Quote
  #6 (permalink)  
Old 07-21-2006, 01:21 AM
Andy
Guest
 
Posts: n/a
Default Re: Hardware book like "Code Complete"?

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

Reply With Quote
  #7 (permalink)  
Old 07-21-2006, 02:32 AM
JJ
Guest
 
Posts: n/a
Default Re: Hardware book like "Code Complete"?


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

Reply With Quote
  #8 (permalink)  
Old 07-21-2006, 02:51 AM
Guest
 
Posts: n/a
Default Re: Hardware book like "Code Complete"?

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


Reply With Quote
  #9 (permalink)  
Old 07-21-2006, 03:14 AM
Jonathan Bromley
Guest
 
Posts: n/a
Default Re: Hardware book like "Code Complete"?

On 20 Jul 2006 18:51:11 -0700, [email protected] 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
[email protected]
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Reply With Quote
  #10 (permalink)  
Old 07-21-2006, 05:42 AM
Phil Tomson
Guest
 
Posts: n/a
Default Re: Hardware book like "Code Complete"?

In article <[email protected]>,
Mike Treseler <[email protected]> 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
Reply With Quote
  #11 (permalink)  
Old 07-21-2006, 06:10 AM
Bob Perlman
Guest
 
Posts: n/a
Default Re: Hardware book like "Code Complete"?

On 21 Jul 2006 04:42:09 GMT, [email protected] (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
Reply With Quote
  #12 (permalink)  
Old 07-21-2006, 02:28 PM
Ted
Guest
 
Posts: n/a
Default Re: Hardware book like "Code Complete"?

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

Reply With Quote
  #13 (permalink)  
Old 07-21-2006, 04:04 PM
Guest
 
Posts: n/a
Default Re: Hardware book like "Code Complete"?

>Jonathan Bromley wrote:
> On 20 Jul 2006 18:51:11 -0700, [email protected] 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
> [email protected]
> http://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.


Reply With Quote
  #14 (permalink)  
Old 07-21-2006, 04:53 PM
Jon Forrest
Guest
 
Posts: n/a
Default Re: Hardware book like "Code Complete"?

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-
Reply With Quote
  #15 (permalink)  
Old 07-21-2006, 08:01 PM
Andy
Guest
 
Posts: n/a
Default Re: Hardware book like "Code Complete"?


[email protected] 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

Reply With Quote
  #16 (permalink)  
Old 07-21-2006, 08:26 PM
Tommy Thorn
Guest
 
Posts: n/a
Default Re: Hardware book like "Code Complete"?

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

Reply With Quote
  #17 (permalink)  
Old 07-21-2006, 11:25 PM
Guest
 
Posts: n/a
Default Re: Hardware book like "Code Complete"?


Andy wrote:
> [email protected] 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
>


Reply With Quote
  #18 (permalink)  
Old 07-21-2006, 11:49 PM
Mike Treseler
Guest
 
Posts: n/a
Default Re: Hardware book like "Code Complete"?

[email protected] 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
Reply With Quote
  #19 (permalink)  
Old 07-22-2006, 12:05 AM
Andy
Guest
 
Posts: n/a
Default Re: Hardware book like "Code Complete"?

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

Reply With Quote
  #20 (permalink)  
Old 07-22-2006, 01:05 AM
Guest
 
Posts: n/a
Default Re: Hardware book like "Code Complete"?

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


Reply With Quote
  #21 (permalink)  
Old 07-23-2006, 04:41 PM
KJ
Guest
 
Posts: n/a
Default Re: Hardware book like "Code Complete"?


"Tommy Thorn" <[email protected]> wrote in message
news:[email protected] ups.com...
> 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.
>


But in practice one doesn't much care if any outputs are 'Mealy' or 'Moore'.
What one has is a function that needs to be implemented within specific area
(or logic resource) constraints and performance (i.e. clock cycle, Tpd, Tsu,
Tco) constraints.

Breaking what can be accomplished in one process into two (or more)
logically equivalent processes should be considered for code clarity which
can aid in support and maintenance of the code during it's lifetime as well
as for potential design reuse (although realistically re-use of any single
process is probably pretty low). Re-use happens more often at the
entity/architecture level, but the 'copy/paste/modify' type of re-use
probably happens more at the process level when it does happen.

Breaking a process into two just to have a combinatorial process to describe
the 'next' state and a separate process to clock that 'next' state into the
'current' state has no particular value when using design support and
maintenance cost as a metric of 'value'. Since the different methods
produce the final end logic there is no function or performance advantage to
either approach. On the other hand, there are definite drawbacks to
implementing combinatorial logic in a VHDL process. Two of these are
- Introduction of 'unintended' latches
- Missing signals in the sensitivity list that result in different
simulation versus synthesis results

Both of these drawbacks have manual methods that can be used to try to
minimize them from happening but the bottom line is that extra effort
(a.k.a.. cost or negative value) must be incurred to do this....all of which
is avoided by simply not using the VHDL process to implement combinatorial
logic (i.e. the 'next' state computation).

So as far as the VHDL language is concerned, there are real costs that will
be incurred every time the two process method is used but no real value
add....or at least that's my 2 cents.....

KJ


Reply With Quote
  #22 (permalink)  
Old 07-23-2006, 05:51 PM
Mike Treseler
Guest
 
Posts: n/a
Default Re: Hardware book like "Code Complete"?

KJ wrote:

> Breaking what can be accomplished in one process into two (or more)
> logically equivalent processes should be considered for code clarity


I find the idea of describing both the "Q side" state
and the "D side" next state more confusing than clarifying.

> which
> can aid in support and maintenance of the code during it's lifetime as well
> as for potential design reuse (although realistically re-use of any single
> process is probably pretty low). Re-use happens more often at the
> entity/architecture level,


....one reason that I favor single process entities.

> but the 'copy/paste/modify' type of re-use
> probably happens more at the process level when it does happen.


....for this type of reuse, I use procedures.
This provides some modularity and built-in documentation.
Even if the operation is not reused, well-named
procedures in process scope make code easier to read and maintain.


> Breaking a process into two just to have a combinatorial process to describe
> the 'next' state and a separate process to clock that 'next' state into the
> 'current' state has no particular value when using design support and
> maintenance cost as a metric of 'value'. Since the different methods
> produce the final end logic there is no function or performance advantage to
> either approach. On the other hand, there are definite drawbacks to
> implementing combinatorial logic in a VHDL process. Two of these are
> - Introduction of 'unintended' latches
> - Missing signals in the sensitivity list that result in different
> simulation versus synthesis results
>
> Both of these drawbacks have manual methods that can be used to try to
> minimize them from happening but the bottom line is that extra effort
> (a.k.a.. cost or negative value) must be incurred to do this....all of which
> is avoided by simply not using the VHDL process to implement combinatorial
> logic (i.e. the 'next' state computation).
>
> So as far as the VHDL language is concerned, there are real costs that will
> be incurred every time the two process method is used but no real value
> add....or at least that's my 2 cents.....


Well said. Thanks for the posting.

-- Mike Treseler
Reply With Quote
  #23 (permalink)  
Old 07-23-2006, 10:44 PM
KJ
Guest
 
Posts: n/a
Default Re: Hardware book like "Code Complete"?

>> Breaking what can be accomplished in one process into two (or more)
>> logically equivalent processes should be considered for code clarity

>
> I find the idea of describing both the "Q side" state
> and the "D side" next state more confusing than clarifying.
>


I find the 'D/Q' side coding less usefull too. I was referring more to
having multiple clocked processes rather than the 'two process' discussion
that is going on here. Even though the multiple clocked processes that I
meant can all be logically thought of as one process I tend to break them up
into the multiple clocked processes simply to group together somewhat
related functions. Somewhat like the way a story/chapter is broken up into
multiple paragraphs that express a particular thought.

KJ


Reply With Quote
  #24 (permalink)  
Old 07-24-2006, 07:46 AM
Ian Bell
Guest
 
Posts: n/a
Default Re: Hardware book like "Code Complete"?

Davy wrote:

> Hi all,
>
> Is there some hardware RTL book like "Code Complete" by Steve
> McConnell?
>


Unlikely. Creating software is far less complex and variable than creating
hardware.

Ian

Reply With Quote
  #25 (permalink)  
Old 07-24-2006, 11:31 AM
KJ
Guest
 
Posts: n/a
Default Re: Hardware book like "Code Complete"?

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


Maybe I'm missing something but in the one process code you would add the
following...
if (Scan_Chain_Active = '1') then
-- Assign the clocked signals here per how it's needed for scan chain
else
-- Assign the clocked signals here per how the design needs it to
function
-- (i.e. this was what was here prior to adding scan)
end if;

I don't see that as any particular burden or how that would be any different
in the clocked process of the two process approach. It certainy isn't any
messier.

> Another example is to use a meta-stabile hardened D FF for
> synchronization.


Kinda lost me on what you mean or how the two process approach would
help have any advantage over the one process approach.

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


And I think that is the crux of the debate between the 'one process' versus
'two process' camps, the 'two process' folks can't explicitly state any real
advantage to their approach even though they recognize real costs to doing
so....to be blunt, you're paying a price and getting nothing in return. In
this particular case, can you explain what benefit is received for
separately instantiating each memory element?

In reality, since either approach yields the exact same function and
performance the debate centers solely on productivity....which method, can
one be more productive with and why? Productivity is economoics and
measuring productivity means using currency ($$, Euros, etc) as your basis
for comparison. You can't really measure productivity without also bringing
up which tools are being used either since use of a 'better' tool may
involve being somewhat less efficient on one end with the overall goal that
the entire process is more efficient.

Comparing the two process approach to the one process the basic difference
is that you have several more lines of code to write:
- Declarations for the additional set of signals (i.e. the 'D' and 'Q'
instead of just the 'Q')
- Adding the 'default' values for each of the 'D' equations so as to not
create unintended latches.
- The 'Q <= D;' code in the second (i.e. clocked) process of the two process
approach.
- Process sensitivity list maintenance (in VHDL)

Now take design creation and debug as an activity to measure cost. For
every line of code written, one can assume that there is a certain
probability that it will be wrong. For a given designer using a given
language using a given coding technique one will likely tend to have some
particular error rate measured in errors per line of code. Since errors
need to be fixed at some point you incur some cost to doing so. If nothing
else, the two process approach encourages more lines of code and therefore a
higher probability of having an error than the one process approach so what
does the two process approach bring to the table that would lower the error
rate that might somehow offset the increased lines of code?

One can take other tasks like scan chain insertion as you did, or test
creation, life cycle support etc. whatever tasks you can think of and try to
compare costs of those tasks using the two approaches and go through the
same process to come up with a $$ measure for each task. Total up the tasks
and see which approach is better.

Now if someone in the two process camp can walk through a single task and
show how even that one task is more efficient (i.e. productive) than the one
process approach you might be able to start convincing readers until
then....well one can always dream.

KJ


Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
What is a "bug", and what is "good code"? (or: more default_nettype) Evan Lavelle Verilog 2 07-26-2007 03:03 PM
C/C++ for hardware (from "Re: Embedded languages based on early Ada (from "Re: Preferred OS, processor family for running embedded Ada?")") Colin Paul Gloster FPGA 0 04-10-2007 11:31 AM
Hardware book like "Code Complete"? Davy FPGA 61 08-21-2006 10:34 AM
Hardware book like "Code Complete"? Davy Verilog 30 08-21-2006 10:34 AM
Warning: FlipFlops/Latches "/"ADR_reg<0>"/Q_reg" are set/reset by "". (FPGA-GSRMAP-14) Martin Bammer VHDL 0 11-17-2003 11:28 PM


All times are GMT +1. The time now is 11:51 AM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved