Hardware book like "Code Complete"?

[KJ]

KJ wrote:



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

 

[KJ]

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

 

[KJ]

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

 

[Mike Treseler]

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.

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

 

[KJ]

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

 

[Paul Floyd]

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

 

[KJ]

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?

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

 

[Davy]

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

 

[Andy]

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

 

[Andy]

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]

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

 

[KJ]

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.

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

 

[Mike Treseler]

We were discussing true outputs signals (i.e. not needed internally).

That's not what I was talking about.
I use output registers as working registers as well.

search for serial_out_v in http://home.comcast.net/~mike_treseler/uart.vhd
for an example.

-- Mike Treseler

 

[KJ]

That's not what I was talking about.
I use output registers as working registers as well.

Actually at the time, we were just talking about output registers
specifically.

<Pasting from 4 up in this thread>

** Mike said **

Output register variable values
are assigned directly to out ports.

** KJ said ***
And this is better (or just different) than output register signals
values being assigned to out ports?

<Pasting from 3 up in this thread>

** Mike said **

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

my_out_port <= my_out_reg_v;

** KJ said **

I'll go with just 'different' on this one, it doesn't seem...

 

[Andy]

Of course there are multiple functionally equivalent methods (i.e. they
synthesize to the same hardware) of describing a given architecture,
but some methods (e.g. using integers, variables and clocked processes,
while minimizing slv, signals, combinatorial processes and concurrent
assignments) simulate much more efficiently (approaching cycle based
performance) than others. The more clock cycles I can simulate, the
more bugs I can find, and the more quickly I can verify alternate
architectures. It may not make a big difference on small projects, but
on larger projects, the performance difference is huge.

Andy

 

[Weng Tianxiang]

Hi Andy,
I would like to ask a question:

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;

In the following statement:
var := (var - 1) mod var_limit;
var is not assigned any value before it is used. var_limit is a
constant, of course.
Anything is wrong?

Weng

 

[Christer Ericson]

Care to estimate the size of the market?

I don't know about hardware books, but for a specialist
book 10,000 copies over the lifetime of the book is a
bestseller!

A first printing may be something like 1,000-2,500
books I believe. Many (probably most?) don't make it
past a first printing.

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

About 15% in royalties.

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

There's no business in it. For the great majority, writing
specialist books is a losing proposition; you'd make more
money flipping burgers during the time it would take you to
write the book. You write a (specialist) book because you
have a burning need to write one.

The only way there's business in it is if the book is picked
up as a textbook at lots of universities around the world or
is on some universally interesting topic.

Knuth, Hennessy and Patterson, Foley et al, and McConnell
have probably made good money from their books, but they are
the exceptions.

 

[Weng Tianxiang]

Hi Christer,
I bought Knuth's books and McConnell's Pentium story. But I don't know
Hennessy and Patterson. What are their popular books?

Thank you.

Weng

 

[Mike Treseler]

In the following statement:
var := (var - 1) mod var_limit;
var is not assigned any value before it is used. var_limit is a
constant, of course.
Anything is wrong?

No.
For simulation, the present value is used
to calculate and save the expression value.
For synthesis, this is infers a register to save
the value for the next process loop.

-- Mike Treseler

 

[BobG]

I read the whole thread and no one recommended "The Art Of Electronics"
by Horowitz and Hill??