Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > vhdl for beginners

Reply
Thread Tools

vhdl for beginners

 
 
vipin lal
Guest
Posts: n/a
 
      03-19-2010
hi andy.. that was some awesome information..I didn't find in any
sites these things.. I want to share this information in my blog.Hope
you don't mind.

I had little doubt about how successful I will be with writing codes
using only signed or unsigned data types.. but yesterday i wrote some
square root and division functions using numeric_std alone..it worked
well.. thanks..
I will try to avoid the use of SLV as much as possible..

Regards
vipin
 
Reply With Quote
 
 
 
 
M. Norton
Guest
Posts: n/a
 
      03-19-2010
On Mar 19, 12:39*am, vipin lal <(E-Mail Removed)> wrote:
> I will try to avoid the use of SLV as much as possible..


I'm not sure that's the lesson to take from Andy's explanation. If I
may be allowed to interpret here, you should use the data type that
fits the data you are representing by that symbol. If you are
shipping around numbers, use unsigned or signed as appropriate. If
you are shipping around discrete logic, use std_logic and
std_logic_vector. The general thrust is that the language supports a
wide variety of data types and to the extent made possible by the EDA
tools, we should use those language features in an intelligent manner
to accurately represent the design we are building.
 
Reply With Quote
 
 
 
 
Andy
Guest
Posts: n/a
 
      03-20-2010
On Mar 19, 9:52*am, "M. Norton" <(E-Mail Removed)> wrote:
> On Mar 19, 12:39*am, vipin lal <(E-Mail Removed)> wrote:
>
> > I will try to avoid the use of SLV as much as possible..

>
> I'm not sure that's the lesson to take from Andy's explanation. *If I
> may be allowed to interpret here, you should use the data type that
> fits the data you are representing by that symbol. *If you are
> shipping around numbers, use unsigned or signed as appropriate. *If
> you are shipping around discrete logic, use std_logic and
> std_logic_vector. *The general thrust is that the language supports a
> wide variety of data types and to the extent made possible by the EDA
> tools, we should use those language features in an intelligent manner
> to accurately represent the design we are building.


Yes, M Norton has correctly interpreted what I wrote:


Generally, if you can, create your entity interfaces using unsigned
or
signed (or even integer)

!!!if they are uniformly numerically interpretted.!!!

(i.e. a generic memory device may be able to store any
kind of binary data, so SLV may make more sense there, but a digital
filter has a specific definition of its input data in mind, and that
can be coded by using the appropriate type on the port. Using the
appropriate types on the ports makes it much easier to avoid
conversions within the body.



There are many places where unsigned or signed should rightly be used
instead of SLV, but there are also many places where a single numeric
interpretation of the data is not supported, and the more general SLV
remains appropriate.

For example, an ALU that accepts signed or unsigned data (depending on
the operation control) may always have a numeric interpretation of the
data on its ports, but since we do not have a generic numeric signed
and unsigned representation, SLV would still be appropriate for those
ports.

Other examples, as Norton pointed out, include any collection of bits
that does not have a numeric meaning such as a vector of enable bits,
etc.

Andy
 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      03-20-2010
vipin lal wrote:

> I will try to avoid the use of SLV as much as possible..


Since I agree with the others on this thread,
I will play the devils advocate.

What is the upside to a top entity with an SLV interface?

1. Everyone will understand the type and where bit 0 is.
2. Experts will provide conversions to their preferred types.
3. Journeymen will like it as is.
4. Very old synthesis tools will have a chance of working.

-- Mike Treseler
 
Reply With Quote
 
vipin lal
Guest
Posts: n/a
 
      03-21-2010
Hi...
Yeah..I misunderstood Andy in the beginning.Now I got it.
One more doubt.
IS there any math library in VHDL for operations such as square
root,floating point operations etc.Or you should make them your own
according to your own needs?
I am trying to write some functions of some basic operations.But if
any reliable standard library is there,then I can use them instead.

Thanks
vipin
 
Reply With Quote
 
rickman
Guest
Posts: n/a
 
      03-21-2010
On Mar 20, 1:22*pm, Andy <(E-Mail Removed)> wrote:
> On Mar 19, 9:52*am, "M. Norton" <(E-Mail Removed)> wrote:
>
> > On Mar 19, 12:39*am, vipin lal <(E-Mail Removed)> wrote:

>
> > > I will try to avoid the use of SLV as much as possible..

>
> > I'm not sure that's the lesson to take from Andy's explanation. *If I
> > may be allowed to interpret here, you should use the data type that
> > fits the data you are representing by that symbol. *If you are
> > shipping around numbers, use unsigned or signed as appropriate. *If
> > you are shipping around discrete logic, use std_logic and
> > std_logic_vector. *The general thrust is that the language supports a
> > wide variety of data types and to the extent made possible by the EDA
> > tools, we should use those language features in an intelligent manner
> > to accurately represent the design we are building.

>
> Yes, M Norton has correctly interpreted what I wrote:
>
> Generally, if you can, create your entity interfaces using unsigned
> or
> signed (or even integer)
>
> * !!!if they are uniformly numerically interpretted.!!!
>
> (i.e. a generic memory device may be able to store any
> kind of binary data, so SLV may make more sense there, but a digital
> filter has a specific definition of its input data in mind, and that
> can be coded by using the appropriate type on the port. Using the
> appropriate types on the ports makes it much easier to avoid
> conversions within the body.
>
> There are many places where unsigned or signed should rightly be used
> instead of SLV, but there are also many places where a single numeric
> interpretation of the data is not supported, and the more general SLV
> remains appropriate.
>
> For example, an ALU that accepts signed or unsigned data (depending on
> the operation control) may always have a numeric interpretation of the
> data on its ports, but since we do not have a generic numeric signed
> and unsigned representation, SLV would still be appropriate for those
> ports.
>
> Other examples, as Norton pointed out, include any collection of bits
> that does not have a numeric meaning such as a vector of enable bits,
> etc.
>
> Andy


Isn't that rather a philosophical approach? If I have a signal that
is sometimes signed and other times unsigned, there is nothing wrong
with declaring it unsigned and then converting to signed when I need
to use it that way. That beats converting to signed as well as
converting to unsigned anytime I need to use if for arithmetic. VHDL
is so verbose that I often code to avoid the verbosity rather than
worrying about philosophical issues.

Rick
 
Reply With Quote
 
Tricky
Guest
Posts: n/a
 
      03-22-2010
On 21 Mar, 02:11, vipin lal <(E-Mail Removed)> wrote:
> Hi...
> Yeah..I misunderstood Andy in the beginning.Now I got it.
> One more doubt.
> IS there any math library in VHDL for operations such as square
> root,floating point operations etc.Or you should make them your own
> according to your own needs?
> I am trying to write some functions of some basic operations.But if
> any reliable standard library is there,then I can use them instead.
>
> Thanks
> vipin


in VHDL 2008 there are 2 new packages - one for fixed point operations
and one for floating point. The floating point one wont be very useful
until vendors start supporting it and are able to do decent register
re-timing to get the long pipelines required for floating point in
place. But the fixed point package makes code alot more readable when
theres fractional bits flying around. I dont think there is any you
cant already do with the numeric_std package, but it makes aligning
numerator and fractional parts so much easier and much easier to read.

Quick reference and version compatible with VHDL 93 are here:
http://www.vhdl.org/fphdl/
 
Reply With Quote
 
Andy
Guest
Posts: n/a
 
      03-22-2010
The fixed point packages can be used, by specifying zero fractional
(negative indexed) bits, to represent signed and unsigned integer
arithmetic. The fixed point packages assume a more integer-like tilt
toward numeric accuracy than numeric_std does, by expanding the sizes
of results to accurately handle the possible nnumeric range of those
results. So adding two n bit ufixed operands results in an n+1 bit
result. This means that intermediate results in expressions are
numerically accurate (not subject to truncation, except for division),
but due to the inability to override assignment operators in VHDL, the
results usually must be manually re-sized to store in a variable or
signal. Just like with integers, synthesis should be able to do a good
job of removing bits and logic associated with expanded intermediate
results if they do not contribute to those bits retained in storage.

So an up counter would look something like:
variable n : ufixed(nsize - 1 downto 0);
....
-- resize does the rollover
n := resize(n + 1, n);

My biggest disappointment with the fixed point package is that
subtraction of two ufixed operators does not expand the result to
sfixed (but it does expand the size of the results by one bit, which
will always be zero!) So while the ufixed + operator does not roll
over, the - operator for ufixed does, however by some perverse stroke
of luck, you still have to manually resize the result:

variable n : ufixed(nsize - 1 downto 0);
....
-- ufixed subtract does the rollover,
-- resize is still required
n := resize(n - 1, n);

Comparatively, with integers:

variable n : integer range 0 to 2**nsize - 1;
....
-- integer mod does the rollover
n := (n - 1) mod 2**nsize;

And with unsigned:

variable n : unsigned(nsize - 1 downto 0);
....
-- unsigned subtract does the rollover
n := n - 1;

Andy


 
Reply With Quote
 
vipin lal
Guest
Posts: n/a
 
      04-02-2010
On Mar 22, 8:33*pm, Andy <(E-Mail Removed)> wrote:
> The fixed point packages can be used, by specifying zero fractional
> (negative indexed) bits, to represent signed and unsigned integer
> arithmetic. The fixed point packages assume a more integer-like tilt
> toward numeric accuracy than numeric_std does, by expanding the sizes
> of results to accurately handle the possible nnumeric range of those
> results. So adding two n bit ufixed operands results in an n+1 bit
> result. This means that intermediate results in expressions are
> numerically accurate (not subject to truncation, except for division),
> but due to the inability to override assignment operators inVHDL, the
> results usually must be manually re-sized to store in a variable or
> signal. Just like with integers, synthesis should be able to do a good
> job of removing bits and logic associated with expanded intermediate
> results if they do not contribute to those bits retained in storage.
>
> So an up counter would look something like:
> variable n : ufixed(nsize - 1 downto 0);
> ...
> -- resize does the rollover
> n := resize(n + 1, n);
>
> My biggest disappointment with the fixed point package is that
> subtraction of two ufixed operators does not expand the result to
> sfixed (but it does expand the size of the results by one bit, which
> will always be zero!) So while the ufixed + operator does not roll
> over, the - operator for ufixed does, however by some perverse stroke
> of luck, you still have to manually resize the result:
>
> variable n : ufixed(nsize - 1 downto 0);
> ...
> -- ufixed subtract does the rollover,
> -- resize is still required
> n := resize(n - 1, n);
>
> Comparatively, with integers:
>
> variable n : integer range 0 to 2**nsize - 1;
> ...
> -- integer mod does the rollover
> n := (n - 1) mod 2**nsize;
>
> And with unsigned:
>
> variable n : unsigned(nsize - 1 downto 0);
> ...
> -- unsigned subtract does the rollover
> n := n - 1;
>
> Andy


Thanks Andy..
I started using fixed_pkg and wrote some simple programs also.But when
I tried to synthesis the code it came "Library ieee_proposed cannot be
found."
I successfully simulated the same design.
Is Library ieee_proposed not synthesisable????????
pls help...
 
Reply With Quote
 
vipin lal
Guest
Posts: n/a
 
      04-02-2010
On Apr 2, 12:04*pm, vipin lal <(E-Mail Removed)> wrote:
> On Mar 22, 8:33*pm, Andy <(E-Mail Removed)> wrote:
>
>
>
>
>
> > The fixed point packages can be used, by specifying zero fractional
> > (negative indexed) bits, to represent signed and unsigned integer
> > arithmetic. The fixed point packages assume a more integer-like tilt
> > toward numeric accuracy than numeric_std does, by expanding the sizes
> > of results to accurately handle the possible nnumeric range of those
> > results. So adding two n bit ufixed operands results in an n+1 bit
> > result. This means that intermediate results in expressions are
> > numerically accurate (not subject to truncation, except for division),
> > but due to the inability to override assignment operators inVHDL, the
> > results usually must be manually re-sized to store in a variable or
> > signal. Just like with integers, synthesis should be able to do a good
> > job of removing bits and logic associated with expanded intermediate
> > results if they do not contribute to those bits retained in storage.

>
> > So an up counter would look something like:
> > variable n : ufixed(nsize - 1 downto 0);
> > ...
> > -- resize does the rollover
> > n := resize(n + 1, n);

>
> > My biggest disappointment with the fixed point package is that
> > subtraction of two ufixed operators does not expand the result to
> > sfixed (but it does expand the size of the results by one bit, which
> > will always be zero!) So while the ufixed + operator does not roll
> > over, the - operator for ufixed does, however by some perverse stroke
> > of luck, you still have to manually resize the result:

>
> > variable n : ufixed(nsize - 1 downto 0);
> > ...
> > -- ufixed subtract does the rollover,
> > -- resize is still required
> > n := resize(n - 1, n);

>
> > Comparatively, with integers:

>
> > variable n : integer range 0 to 2**nsize - 1;
> > ...
> > -- integer mod does the rollover
> > n := (n - 1) mod 2**nsize;

>
> > And with unsigned:

>
> > variable n : unsigned(nsize - 1 downto 0);
> > ...
> > -- unsigned subtract does the rollover
> > n := n - 1;

>
> > Andy

>
> Thanks Andy..
> I started using fixed_pkg and wrote some simple programs also.But when
> I tried to synthesis the code it came "Library ieee_proposed cannot be
> found."
> I successfully simulated the same design.
> Is Library ieee_proposed not synthesisable????????
> pls help...

I am using Xilinx ISE 10.1
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
VHDL-2002 vs VHDL-93 vs VHDL-87? afd VHDL 1 03-23-2007 09:33 AM
Beginners VHDL: VHDLBABY VHDL 5 04-11-2006 10:47 AM
VHDL 2002 vs VHDL 1993 dude VHDL 1 03-23-2006 01:18 PM
multiD-vhdl: Multi Dimensional Arrays (allowing generics on each dimension) for VHDL (including ports) albert.neu@gmail.com VHDL 2 03-21-2006 04:05 PM
what's the difference between VHDL 93 CONCATENATION and VHDL 87 CONCATENATION? walala VHDL 3 09-18-2003 04:17 AM



Advertisments