FPGA Central

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

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 <[email protected]>,
[email protected] 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

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

Whatever the reset code says it is.
If there is no reset code, it might be a 'U'.
Check your simulation waveforms for exact answers.

-- Mike Treseler

You can assignee an initial value when a variable or signal is
declared, e.g.,

signal mysig: std_logic := '0';

This will be the initial value when simulation starts. According to
VHDL LRM, if there is no initial value, the first value defined in the
data type will be used. Since std_logic is defined as ('U', 'X', '0',
....) in 1164 package. The 'U' value (for uninitialized) will be the
default value.

Since the initial value cannot always be synthesized, this approach
should not be used in synthesis. It is better to use an explicit reset
mechanism to initialize a sequential circuit.

Mike G.


Weng Tianxiang wrote:
> 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

On Fri, 28 Jul 2006 11:33:25 -0700, Mike Treseler
<[email protected]> wrote:
> 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.

It _is_ an electronics book. There is one mention of RTL, but it's
'resistor-transistor logic'. Not quite the same thing.

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

Hi Mike,
Thank you.

Weng



[email protected] wrote:
> You can assignee an initial value when a variable or signal is
> declared, e.g.,
>
> signal mysig: std_logic := '0';
>
> This will be the initial value when simulation starts. According to
> VHDL LRM, if there is no initial value, the first value defined in the
> data type will be used. Since std_logic is defined as ('U', 'X', '0',
> ...) in 1164 package. The 'U' value (for uninitialized) will be the
> default value.
>
> Since the initial value cannot always be synthesized, this approach
> should not be used in synthesis. It is better to use an explicit reset
> mechanism to initialize a sequential circuit.
>
> Mike G.
>
>
> Weng Tianxiang wrote:
> > 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

I almost always use integer subtypes for counters, so it would not
simulate as 'U'. I used a simple example to show a point about
combinatorial vs registered logic, not about reset; you can code async
or sync reset for registers using variables the same way you do for
signals.

Andy


[email protected] wrote:
> You can assignee an initial value when a variable or signal is
> declared, e.g.,
>
> signal mysig: std_logic := '0';
>
> This will be the initial value when simulation starts. According to
> VHDL LRM, if there is no initial value, the first value defined in the
> data type will be used. Since std_logic is defined as ('U', 'X', '0',
> ...) in 1164 package. The 'U' value (for uninitialized) will be the
> default value.
>
> Since the initial value cannot always be synthesized, this approach
> should not be used in synthesis. It is better to use an explicit reset
> mechanism to initialize a sequential circuit.
>
> Mike G.
>
>
> Weng Tianxiang wrote:
> > 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

Andy wrote:
> I almost always use integer subtypes for counters, so it would not
> simulate as 'U'.

I prefer integers for counters also.
Up to 31 bits, that is

-- Mike Treseler

KJ wrote:
> > 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
A few months ago a similar Idea was posted on an ASIC and Digital
design community at Orkut. The basic Idea was
a) To collect class notes/Presentation on a particular topic and expand
it to a book or
b) A person will come up with the book outline and others will submit
articles on specific topics and flesh it out
The final goal being to get a set of books on hardware design. You can
check the details at http://edaindia.com/books/

Regards
H.H.I Tracy
.....

vijayvithal jahagirdar wrote:
> A few months ago a similar Idea was posted on an ASIC and Digital
> design community at Orkut. The basic Idea was
> a) To collect class notes/Presentation on a particular topic and expand
> it to a book or
> b) A person will come up with the book outline and others will submit
> articles on specific topics and flesh it out
> The final goal being to get a set of books on hardware design. You can
> check the details at http://edaindia.com/books/
>
> Regards
> H.H.I Tracy

Why not go with Wikipedia? It's so easy for anyone to add to.
Just host the wikipedia software on some other server, if
Wikipedia's policies aren't satisfactory.

-Dave

David Ashley <[email protected]> writes:

> vijayvithal jahagirdar wrote:
>> A few months ago a similar Idea was posted on an ASIC and Digital
>> design community at Orkut. The basic Idea was
>> a) To collect class notes/Presentation on a particular topic and expand
>> it to a book or
>> b) A person will come up with the book outline and others will submit
>> articles on specific topics and flesh it out
>> The final goal being to get a set of books on hardware design. You can
>> check the details at http://edaindia.com/books/
>
> Why not go with Wikipedia? It's so easy for anyone to add to.
> Just host the wikipedia software on some other server, if
> Wikipedia's policies aren't satisfactory.

One could use http://wikibooks.org or http://wikia.com/ for hosting.
I too think that such a book project is doomed if the hurdle for
contributing is too high.

Cheers,
Colin

Colin Marquardt wrote:
> David Ashley <[email protected]> writes:
> >
> > Why not go with Wikipedia? It's so easy for anyone to add to.
> > Just host the wikipedia software on some other server, if
> > Wikipedia's policies aren't satisfactory.
>
> One could use http://wikibooks.org or http://wikia.com/ for hosting.
> I too think that such a book project is doomed if the hurdle for
> contributing is too high.
>
> Cheers,
> Colin

Most of the contributors to this thread seem to agree that writing a
Speciality book does not justify the effort that needs to be put in.
The reasons stated are
1> Small number of Digital designers.
2> Long time required to finish writing the book.

As an example suppose I decide to write a document on "VHDL/Verilog
coding style for Low Power mixed signal designs" which basically
collates the various material available on this topic in Public domain
and presents it in an easy to read and implement format. Out of the
estimated 10,000 Digital design engineers only a couple of hundreds
engineers (for e.g. those working on chips for handheld applications)
will actually find the book useful to the work at hand and will be
actually interested in buying the book. This makes the effort put in
writing the book commerically unviable.

Now suppose as a part of my normal work(either academic or otherwise) I
come up with a similar document which my funding organisation allows me
to put in public domain. I would rather prefer to put it as
is(ppt,word,pdf,ps,html etc.) and move on to the next pending work,
rather than rewrite the document in the format required by wiki.

I think in such a situation one of the following approach may be
suitable
1> Upload the document to my personal website and post the url to
usenet and other forums.
2> Upload the document to a common repository(Some place for electronic
documents similar to what CPAN is for Perl code or CTAN for tex macros)
say a sharepoint or a twiki or an interface similar to CPAN.

Collecting a set of similar articles, say on the topic of "digital
design in a low power mixed signal design" written by different authors
would give those 200 engineers working in this field a standard
reference. Due to the different formats and writing styles it would not
be a proper book but it can act as a loosely bound reference material

At a later date if this does turn out to be a hot topic and a demand
exists for a published text then it should be possible to get the
proper permissions form the respective authors and cleanup the
formatting linearise the content and publish the book.

Regards
Vijay

Andy Glew wrote:

> Care to estimate the size of the market?
>
> I.e. how much would the author expect to make, given typical publishing contracts?

Speaking as someone who's written three speciality-ish engineering
books (go to www.larwe.com and look down the left-hand column for links
to the books), the point of writing a volume like this is one of two
things:

1. Get it picked up as a textbook or training book in college or by one
of the major semi manufacturers.

2. Treat it as advertising.

Route 1 can lead to respectable direct profits. Route 2 leads to
indirect profits through consultancy and so forth. Do not expect to
make your fortune through route 1; the real money is in route 2 but
requires more work to realize.

Your book is the dynamite that exposes a seam of gold. Significant
pick-work is necessary to extract the gold and bring it to town for
conversion into cash.

"larwe" <[email protected]> wrote in message
news:[email protected] ps.com...
>
> Andy Glew wrote:
>
>> Care to estimate the size of the market?
>>
>> I.e. how much would the author expect to make, given typical
>> publishing contracts?
>
> Speaking as someone who's written three speciality-ish engineering
> books (go to www.larwe.com and look down the left-hand column for
> links
> to the books), the point of writing a volume like this is one of two
> things:
>
> 1. Get it picked up as a textbook or training book in college or by
> one
> of the major semi manufacturers.
>
> 2. Treat it as advertising.
>
> Route 1 can lead to respectable direct profits. Route 2 leads to
> indirect profits through consultancy and so forth. Do not expect to
> make your fortune through route 1; the real money is in route 2 but
> requires more work to realize.
>
> Your book is the dynamite that exposes a seam of gold. Significant
> pick-work is necessary to extract the gold and bring it to town for
> conversion into cash.
>

Must it always be about the money? Won't somebody think of the children
;-)