Hardware book like "Code Complete"?

On 21 Jul 2006 04:42:09 GMT, ptkwt@aracnet.com (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

"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message 
news:djb0c2d96k2f7tjv3tg9k09dri31bb1gtk@4ax.com...
>
> However...  it seems to me that comp.lang.verilog/vhdl
> and comp.arch.fpga represents a useful pool of
> expertise.  It's not part of *my* skill-set to do this,
> but I wonder if someone could consider setting-up
> a Wiki (freely-editable website) that could be used
> as a readily accessible repository of this kind of
> stuff?
>
> Any takers?
>
I think the infrastructure is already available.
http://en.wikibooks.org/wiki/Wikibooks:Engineering_bookshelf
or even more appropriately:-
http://en.wikibooks.org/wiki/Programmable_Logic

Cheers, Syms.

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

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-

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

Jonathan Bromley wrote:

> 
>  Our VHDL and Verilog courses teach language essentials
> and coding style, and discuss some generally-applicable 
> design techniques such as FSMs, but to keep them generic
> (and a reasonable length!) we don't discuss how to design 
> any specific kind of hardware.  But we have often been 
> asked to create a course covering "the art of good RTL 
> design" or somesuch.  What these customers seem
> to want is something like "thirty years of design 
> experience in a three-day class". 

I hear it stated like this:
"I'd like to try that technique, but
 I'm not sure it will work so I'm sticking
 with the way I did it last time."

And that's what many opencores designs
look like.

> It's never been 
> feasible for us to do that, because the exact content 
> would be so specific to the particular needs of any 
> one customer.  But an open, peer-moderated, 
> frequently-updated repository sounds like a good 
> idea to me.  I don't mean a library of complete 
> ready-cooked designs like opencores.org; rather,
> I'm thinking of a collection of "design patterns" 
> and shared experience. 

I imagine a site like opencores
with working synthesis and verification code
under version control. The difference would be
that all of the designs would be peer-reviewed
and make full use of advanced synthesis techniques.
The examples would be easy to read, understand and modify.
They would be simple, but non-trivial.
Working code would provide some confidence for the skeptical.

The same code base would provide the "design patterns"
for tutorial authors to reference and write about.
Designs might be combined structurally or procedurally.
They might be used as benchmarks for synthesis
or for evaluating the latest assertion based testing.

> Any takers?

I would be happy to write and review some code examples,
but we would need to find an interested retired person
to be the web master and chief editor.

    -- Mike Treseler

"Tommy Thorn" <tommy.thorn@gmail.com> wrote in message 
news:1153510009.206861.78040@p79g2000cwp.googlegroups.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 

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

KJ wrote:
> "Tommy Thorn" <tommy.thorn@gmail.com> wrote in message
> news:1153510009.206861.78040@p79g2000cwp.googlegroups.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

After reading the arguments here, I have started using a mixed
approach, but I still use the two process model for state machines and
other complex logic. There are just too many times when I don't want to
wait until the next clock for an output to take affect.

At work, we have a hard requirement (as in, it won't pass a peer
review) to write in the two process model. Another hard requirement
(that I agree with) is that there should only be one clocked process
per clock. The guy that came up with the requirement predates HDL's in
general - and I'm sure there was a good reason for it at one time.

However, for my home projects, I tend to mix the one and two-process
models based on what is most convenient.

Having done so, I don't see that the two-process model is that terribly
inconvenient. I simply place a default condition at the beginning of
the process, and override the default as needed. For most processes,
this adds maybe 1-10 "extra" lines.

Perhaps it's because I was taught in the two-process model, but I find
it easier to understand what is going on when I use it, so anything
that requires me to think, I use a separate combinatorial process for.
Simple logic, like counters, pipeline registers, etc. goes into the
appropriate clocked process.

For me, this mixed approach works pretty well.

radarman wrote:
>
> After reading the arguments here, <snip> There are just too many times
> when I don't want to wait until the next clock for an output to take affect.

Stop being so impatient ;)

> Another hard requirement
> (that I agree with) is that there should only be one clocked process
> per clock. The guy that came up with the requirement predates HDL's in
> general - and I'm sure there was a good reason for it at one time.
>
This struck me as kind of odd.  I understand that if there is a hard
requirement to do it this way then you either will do it that way or
seek other employment.  I also don't find it hard to believe either
that the reason for the requirement for may predate HDLs and there was
a good reason for it at one time.

What I find odd though is that you agree with it.  Based on your other
posts to this group I could see that you could 'accept' that this is
how you have to do it but I guess I'm surprised that you would 'agree
with' something that you don't know what the reasoning is...doesn't
seem like 'radarman' talking.

By the way, if you do find the 'good' reason for having physically only
one clocked process I'd be curious to hear what it is.  Although I put
myself in the 'one process' camp my 'one process' tends to be several
physical processes all clocked by the same clock.  From a logic
synthesis/simulation perspective those multiple processes are all
logically 'one' process but breaking them up into physically separate
processes I find makes it easier to understand and debug.

KJ