Hardware book like "Code Complete"?

> 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.
>
Certainly an interesting idea.
>
> Do we have the critical mass to pull something like this off?
>
Always a big question...the other important question is finding the
'leader' to prod this along to get it going in the first place.

KJ

KJ wrote:

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

True. My point is that keeping track of signal
direction relative to each process is manual
bookkeeping that I don't have to with a single process.

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

Simpler because *all* of my registers are variables.
There is no need to interpose a signal. Just

   my_out_port <= my_out_reg_v;


        -- Mike Treseler

Andy wrote:
> With variables, you don't have to wait an extra clock in single process
> descriptions.
>
With concurrent signal assignments that are outside of the process you
don't have to wait an extra clock either.

KJ

On 24 Jul 2006 10:12:42 -0700, Andy Glew <first.last@employer.domain> wrote:
>> 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 can't guess that.

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

From the software world, I suggest that you take a look at Scott Meyers
web site: http://www.aristeia.com/authorAdvice_frames.html

A bientot
Paul
-- 
Paul Floyd                 http://paulf.free.fr (for what it's worth)
Surgery: ennobled Gerald.

Mike Treseler wrote:
> KJ wrote:
>
> > 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.
>
> True. My point is that keeping track of signal
> direction relative to each process is manual
> bookkeeping that I don't have to with a single process.
>
But if you use an unresolved type you're not doing the bookkeeping
either, the compiler is when it complains about multiple drivers on an
unresolved signal.  If you assume that the designer can have a brain
fart and try to drive signal 'XYZ' from two processes then you also
have to accept that the same designer could have two equations for
'XYZ' in the 'one' process.  Assume for the moment that one of those
two is correct.  If those two equations are in separate processes the
compiler immediately flags it as an error, if they are all in one
process then you've basically priority encoded those two equations.
Since we assumed that the designer had a momentary brain fart
forgetting about the other assignment that already existed, which
method allows you to fix the bug quicker?

> >> 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?
>
> Simpler because *all* of my registers are variables.
> There is no need to interpose a signal. Just
>
>    my_out_port <= my_out_reg_v;
>
>
I'll go with just 'different' on this one, it doesn't seem better,
worse or simpler to me since the only reason for that line of code is
because the probably more logically complicated assignment that occurs
to the variable could just as easily have assigned it to the output
signal in the first place.  But there are times when even I use
variables inside a clocked process too so I don't really disagree.

KJ

Hi all,

For I think software engineer is more near to the application, they
"may think more thank hardware engineer".

And "software engineering" is a research topic (they have a lot of
methodology like design pattern).  But I haven't find any book named
"hardware engineering" (and hardware design and verification method is
based on software experience, for example, SystemVerilog is something
like C++).

Anyone finish a good book about "hardware engineering" will be known by
hardware engineer all of the world. Thanks!

Davy

Davy wrote:
> Hi all,
>
> Is there some hardware RTL book like "Code Complete" by Steve
> McConnell? 
> 
> Thanks! 
> Davy

Yes, but...

Assuming the signals that those concurrent assignments depend on are
driven from clocked processes, they do not update until after the
clock, which means they are the registered (delayed) values.

Also, see below:

process (clk) is
begin
  if rising_edge(clk) then
    var := (var - 1) mod var_limit;
    out1 <= var = 0; -- registered comparison of combinatorial var
(i.e. var - 1) with 0
  end if;
  out2 <= var = 0; -- combinatorial comparison of registered var with 0
end process;

Note that both out1 and out2 have the same cycle-accurate behavior.
Note also that if both out1 and out2 exist, Synplify will combine them
and use out1 for both.

Andy

KJ wrote:
> Andy wrote:
> > With variables, you don't have to wait an extra clock in single process
> > descriptions.
> >
> With concurrent signal assignments that are outside of the process you
> don't have to wait an extra clock either.
> 
> KJ

Using variables for the register itself also means that the register
can be read back internally, which you can't do with the output port
signal.

Variable assignment/update overhead during simulation is less than that
of signals.

Using variables for the registers, then a final output signal
assignment from the variable (within the process) removes the need for
a separate combo process or concurrent assignment, and the simulation
overhead involved with that too.

Andy

KJ wrote:
> Mike Treseler wrote:
> > Simpler because *all* of my registers are variables.
> > There is no need to interpose a signal. Just
> >
> >    my_out_port <= my_out_reg_v;
> >
> >
> I'll go with just 'different' on this one, it doesn't seem better,
> worse or simpler to me since the only reason for that line of code is
> because the probably more logically complicated assignment that occurs
> to the variable could just as easily have assigned it to the output
> signal in the first place.  But there are times when even I use
> variables inside a clocked process too so I don't really disagree.
> 
> KJ

Andy wrote:
> Using variables for the register itself also means that the register
> can be read back internally, which you can't do with the output port
> signal.
>
We were discussing true outputs signals (i.e. not needed internally).
If the signal is needed internally than the coding effort is identical,
in one case you declare a signal, the other you declare a variable.

> Variable assignment/update overhead during simulation is less than that
> of signals.
>
Agreed, I measured something around 10% hit for using signals with some
sample code a while back.  Assuming that the actual simulation time
itself is ~10-25% of the total sim/analyze/debug/fix cycle time (the
other 75-90% being analyzing, debugging, fixing) than this speed up
saves you about 1-2.5% of the total amount of time you spend getting a
design working.

Whether or not those numbers are representative of what you see or not,
the point is that the additional amount of test coverage that one gets
is not inversely proportional to actual simulation time.

> Using variables for the registers, then a final output signal
> assignment from the variable (within the process) removes the need for
> a separate combo process or concurrent assignment,

But the coding effort is the same, it's just a question of whether you
put that code inside a process or out in a concurrent assignment.
There's nothing inherently 'pure' or 'better' or anything about whether
everything fits into one process or not.  In this particular case
you're comparing code that is darn near equivalent no matter what
metric you choose to grade it against.

> and the simulation overhead involved with that too.
Agreed previously.

KJ

Andy wrote:
> Yes, but...
>
> Assuming the signals that those concurrent assignments depend on are
> driven from clocked processes, they do not update until after the
> clock, which means they are the registered (delayed) values.

So what?  I typically don't care about waiting a delta cycle delay,
when you put them up on a wave window to debug they all happen at the
same time.

<snip>
> Note that both out1 and out2 have the same cycle-accurate behavior.
> Note also that if both out1 and out2 exist, Synplify will combine them
> and use out1 for both.

And this can be written in a functionally equivalent manner using a
process and concurrent assignments and it will synthesize to the exact
same thing....equivalent.

KJ