Hardware book like "Code Complete"?

KJ wrote:
> 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).

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

Mike Treseler wrote:
> 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...

----
I think we've beaten this one over the head enough, back to woyk.

KJ

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

KJ wrote:
> 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

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

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

In article <peyp8xmjgc51.fsf@PXPL8591.amr.corp.intel.com>, 
first.last@employer.domain says...
> > But if anyone writes a book like this it will fly off the shelves!
> 
> 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.

-- 
Christer Ericson
http://realtimecollisiondetection.net/

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

Weng Tianxiang wrote:

> 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

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

Hi Mike,
Thank you for your response.
Now what is the first value after system asynchronous reset for first
loop?

Thank you.

Weng

Mike Treseler wrote:
> Weng Tianxiang wrote:
>
> > 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 wrote:
> I read the whole thread and no one recommended "The Art Of Electronics"
> by Horowitz and Hill??

That's more of an electronics book than an RTL book.

         -- Mike Treseler