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.

It can't justify the cost and delay of hard-copy but
could easily be sold as a pdf. Forget the idea of
publishing a single work. This should be a work
in progress that is always adding new chapters and
ideals and evolving with the industry.



> Writing and editing a book is two long years
> of work, whatever the subject.
> 
>             -- Mike Treseler


Two long man years.  Quadruple that if you have multiple
authors that need to coordinate their works and then
divide by the number of authors on the project.

Many hands make light work. Get a couple of dozen of
experienced designers, a bunch of proof reading fact
checkers and one decent editor and you  got yourself
an open source book writing project.

Put it out on sourceforge for free and make it useful for any
digital designer at any stage in their career or hobby.Do
a really good job and it can become the "bible" of the
industry that everyone has in the library.


Do we have the critical mass to pull something like this off?


Lets do a survey.  If we did a cooperative book on digital
design guidelines then what chapters would you like to see
and or contribute.


my list:


1)  Reset systems and how they work.

2)  Designing logic for scan testing (atpg)

3)  Designing bist test logic

4)  Designing and using jtag test logic

5)  Designing and using in-chip diagnostic and debugging logic





John Eaton

With variables, you don't have to wait an extra clock in single process
descriptions.

Andy


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

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

Care to estimate the size of the market?

I.e. how much would the author expect to make, given typical publishing contracts?

(I've long wanted to write such a book, but have trouble with the
business case - i.e. persuading my wife.  And, of course, I cannot
write it as an employee of Intel.)

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

I've been bitten in the hindquarters with cross-clock domain problems
too many times. I now have one clocked process per clock. While I try
to avoid cross-clock asynchronous resets, occasionally (especially in
CPLD's) there is no other choice.

I find that by doing this, I catch clock domain crossing errors more
easily. For example. On one design, I had a bus interface running on a
fixed clock (32MHz), internal logic on another fixed clock (40MHz), a
state machine that controlled a digital synthesizer (DDS 9858) that ran
on the DDS utility clock (40MHz, but asynchronous to the previous
clock), and a whole other section of code that ran on the clock
generated by the synthesizer (approximately 40MHz, but variable within
a band).

To summarize:
Local bus clock -> 32MHz.
Local bus I/F and control -> 40MHz (fixed)
DDS controller -> 40MHz (frequency locked, but not phase locked to the
previous)
"special logic" -> 38MHz < f < 42MHz from DDS.

Now, in most cases I was able to limit the crossings. There were a few
F40 <-> V40 crossings due to the nature of the design, but I tried to
restrict those to a handful of sentinel signals with strict timing, and
used rate-change FIFO's where timing wasn't critical. To simplify
things a bit, I created two copies of the bus interface - one for the
40MHz fixed, and another for the 40MHz variable.

However, in the actual DDS controller, I had all three clocks in play
at once. My design had to be able to frequency and phase lock the DDS
output frequency to the fixed 40 (which is quite doable, even if the
design to do so "looks" terrible). To make things more fun, it had to
issue the controls to the DDS aligned with the DDS utility clock - so
the state machine ran on that clock domain. Thankfully, the DDS utility
clock was reliably 90 degrees out of phase with the F40 domain, so I
could design a proper clock boundary crossing circuit.

The one time I fooled around with multiple clocked processes and
multiple clock domains, I ended up spending days (weeks?) debugging a
pernicious little problem that took hours of operation to fail. I
accidentally clocked something that was in the fixed 40MHz domain with
the variable 40MHz. It took a long time to debug that problem because
the per-operation error was so small. Unfortunately, even though the
error was only +/- a few nanoseconds worst case, it was cumulative, and
would cause the system to fail eventually.

While I would have been given leave to violate the design guidelines
with that module, given the complexity of the clock domain crossings, I
found it was better to follow them. Eventually, it dawned on me that a
certain register was in the wrong process. By putting all of the
registers for each domain in a single process, I was able to wrap my
head around the problem more easily.

As a result of that experience, I also started adding the clock domain
as a suffix to the signal name in complex designs. It leads to long
names, but it is worth the effort.

KJ wrote:


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

No signal declarations or direction
conflicts to worry about.
Output register variable values
are assigned directly to out ports.

         -- Mike Treseler

Andy Glew wrote:

> Care to estimate the size of the market?

2000-4000 copies over 2 years.
> 
> I.e. how much would the author expect to make, given typical publishing contracts?

Maybe $4 per book.

> (I've long wanted to write such a book, but have trouble with the
> business case 

There isn't one.
You would have to do it for love, not money.

> And, of course, I cannot
> write it as an employee of Intel.

I expect that would be negotiable.
RTL design is hardly proprietary.

       -- Mike Treseler

At least one.  I'd buy it.   ;-).

Suggestion:  Do it like the guy who wrote "Thinking in JAVA" did.  As he
finished a chapter, he posted it on his website for people to review.   He
got tons of corrections and feedback, which he then used to update the
chapter.   At the end of it all, he published a hardcopy and to his surprise
found out he sold more than expected - because everyone who had read it
online wanted a copy on his/her desk, and because it was online originally
it was highly anticipated when it was actually published.

Seems counter-intuitive, but I believe it would work for a tome such as
this... (and if you did it right, you could generate a few bucks before it
every gets published, wink-wink, nudge-nudge, hint-hint,
know-what-I-mean--know-what-I-mean?).

Regards,
   Dean

"Andy Glew" <first.last@employer.domain> wrote in message
news:peyp8xmjgc51.fsf@PXPL8591.amr.corp.intel.com...
> > 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!
>
> Care to estimate the size of the market?
>
> I.e. how much would the author expect to make, given typical publishing
contracts?
>
> (I've long wanted to write such a book, but have trouble with the
> business case - i.e. persuading my wife.  And, of course, I cannot
> write it as an employee of Intel.)

[snip]

I think what Dean means to say is that he knows an excellent, reputable
website that would put something online and attract a lot of good
readers : )

And if you do a good job, I bet you could persuade Intel to start
buying up copies in bulk for NCGs.

DK

Mike Treseler wrote:
> KJ wrote:
>
>
> > 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.
>
> No signal declarations or direction
> conflicts to worry about.

You have variable declarations instead....not sure what 'direction
conflicts' you're talking about but if it's multiple processes both
'outputting' some signal than not using 'resolved' logic types allows
the compiler to catch that straight out also.

> Output register variable values
> are assigned directly to out ports.
>
And this is better (or just different) than output register signals
values being assigned to out ports?

KJ

radarman wrote:
> Eventually, it dawned on me that a
> certain register was in the wrong process. By putting all of the
> registers for each domain in a single process, I was able to wrap my
> head around the problem more easily.
>
> As a result of that experience, I also started adding the clock domain
> as a suffix to the signal name in complex designs. It leads to long
> names, but it is worth the effort.

OK, good explanation, I wasn't immediately considering the entities
with several clocks in them.  I'd submit though that most of the real
value was in the naming convention of adding the clock domain suffix to
the signal name (which is something that I do as well by the way) and
not so much that they were all physically in one process.

If you agree that the naming convention was probably the more important
of the two then from your description it appears that 'the company'
didn't have signal naming rules in place....and that would've been a
bigger help if it did.  In other words,  the clock domain suffix
certainly would qualify as one of those 'good' patterns for all to
follow and your problem description is a case for why.

The jury is still out in my mind on the physically one clocked process
requirement, to me it can lead to a lot of scrolling back and forth to
make sure one understands all of the places where signals get assigned.
 But I'll also accept that in the multi-clock entities that one needs
to be even more rigid than usual since the tools are of almost no help
in helping to make sure you're crossing domains properly.....and dang,
why is that anyway it's not like it brain surgery.

KJ