[****] VHDL Compile Error ( +, & Operator )
iccra
i have some problem. " + ", " & " operator for different type
i'm using ALDEC VHDL.
====================================================
LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;
USE IEEE.STD_LOGIC_ARITH.ALL;
----------------------------------------------------
SIGNAL pc : STD_LOGIC_VECTOR (8 DOWNTO 0);
pc <= pc + "1";
----------------------------------------------------
Error: Operator "+" is not defined for such operands.
Error: Undefined type of expression.
----------------------------------------------------
SIGNAL a : STD_LOGIC_VECTOR(7 DOWNTO 0);
SIGNAL temp_b : STD_LOGIC_VECTOR(7 DOWNTO 0);
SIGNAL temp_carry : STD_LOGIC;
result <= ("0" & a) + temp_b + temp_carry
----------------------------------------------------
Error: Operator "&" is not defined for such operands.
Error: Undefined type of expression.
====================================================
thanks in advance...
Carlhermann Schlehaus
we are using ALTERA's MAX+PLUSII VHDL Package. This works with the following
corrections on this system:
>
>i have some problem. " + ", " & " operator for different type
>i'm using ALDEC VHDL.
>
>====================================================
>LIBRARY IEEE;
>USE IEEE.STD_LOGIC_1164.ALL;
>USE IEEE.STD_LOGIC_ARITH.ALL;
>
>----------------------------------------------------
>SIGNAL pc : STD_LOGIC_VECTOR (8 DOWNTO 0);
>pc <= pc + "1";
^^^^
pc <= pc + '1' as there is a single bit, no vector added
>----------------------------------------------------
>Error: Operator "+" is not defined for such operands.
>Error: Undefined type of expression.
>----------------------------------------------------
>SIGNAL a : STD_LOGIC_VECTOR(7 DOWNTO 0);
>SIGNAL temp_b : STD_LOGIC_VECTOR(7 DOWNTO 0);
>SIGNAL temp_carry : STD_LOGIC;
>
>result <= ("0" & a) + temp_b + temp_carry
of how many bits does the 'result' contains ?
I would suggest to define result as STD_LOGIC_VECTOR (9 DOWNTO 0) to be sure
that the result of the addition is not larger than the max. representable
value
of 'result'.
This case you do not need to extend 'Signal' a with a extra bit (done by the
compiler...)
Otherwise you should use "00"&a, as you have to add two bits to correct the
length.
Using signed vectors: a(7)&a(7)&a (to preserve the sign bit @ extension).
This should be done for temp_b and temp_carry same way.
>----------------------------------------------------
>Error: Operator "&" is not defined for such operands.
>Error: Undefined type of expression.
>====================================================
>
>thanks in advance...
>
>
Your's sincerely, Carlhermann
Rickman
>
> i have some problem. " + ", " & " operator for different type
> i'm using ALDEC VHDL.
>
> ====================================================
> LIBRARY IEEE;
> USE IEEE.STD_LOGIC_1164.ALL;
> USE IEEE.STD_LOGIC_ARITH.ALL;
>
> ----------------------------------------------------
> SIGNAL pc : STD_LOGIC_VECTOR (8 DOWNTO 0);
> pc <= pc + "1";
> Error: Operator "+" is not defined for such operands.
> Error: Undefined type of expression.
> ----------------------------------------------------
> SIGNAL a : STD_LOGIC_VECTOR(7 DOWNTO 0);
> SIGNAL temp_b : STD_LOGIC_VECTOR(7 DOWNTO 0);
> SIGNAL temp_carry : STD_LOGIC;
>
> result <= ("0" & a) + temp_b + temp_carry
> Error: Operator "&" is not defined for such operands.
> Error: Undefined type of expression.
> ====================================================
>
> thanks in advance...
I am not familiar with the details of the Aldec VHDL compiler, but I
know the the ability to interpret "1" as a valid vector is not
universal. A program I wrote under Orcad VHDL which used this construct
did not compile under Metamor until I changed it to '1'. I believe this
was in conjunction with the concatenation operator as in ('0' & a).
As for your math operation, I have not found any consistent way to
express an adder or counter. Again when I switched from Orcad to
Metamor, I had to change my syntax.
--
Rick Collins
ric...@XYwriteme.com
remove the XY to email me.
Andy Peters
<#$8KbJbv...@news4.netsgo.com>...
>
> i have some problem. " + ", " & " operator for different type
> i'm using ALDEC VHDL.
>
> ====================================================
> LIBRARY IEEE;
> USE IEEE.STD_LOGIC_1164.ALL;
> USE IEEE.STD_LOGIC_ARITH.ALL;
>
> ----------------------------------------------------
> SIGNAL pc : STD_LOGIC_VECTOR (8 DOWNTO 0);
> pc <= pc + "1";
> ----------------------------------------------------
> Error: Operator "+" is not defined for such operands.
> Error: Undefined type of expression.
> ----------------------------------------------------
"1" is, as others have pointed out, a vector - but it's a vector of
length one. That vector is not the same size as PC, which has a
length of nine. The standard functions only operate on vectors of
the same length:
You can do one of two things:
pc <= pc + "000000001";
or if you use (in addition to your USEs above):
library SYNOPSYS;
use SYNOPSYS.std_logic_arith.all;
use SYNOPSYS.std_logic_unsigned.all;
You can simply do a:
pc <= pc + 1; -- note no '' or ""
because the Synopsys libraries overload the addition operator and
there's some magic involved that translates the integer 1 into a
std_logic_vector of the proper length. I use the Metamor tool, too,
and the above works.
> SIGNAL a : STD_LOGIC_VECTOR(7 DOWNTO 0);
> SIGNAL temp_b : STD_LOGIC_VECTOR(7 DOWNTO 0);
> SIGNAL temp_carry : STD_LOGIC;
>
> result <= ("0" & a) + temp_b + temp_carry
> ----------------------------------------------------
> Error: Operator "&" is not defined for such operands.
> Error: Undefined type of expression.
> ====================================================
Weird; your errors don't match mine. ModelSim complained about "No
feasible entries for infix op: "+" and "Bad Expression" and "Type
error resolving infix expression."
I assume you're trying to do an adder, and result is declared as
signal result : STD_LOGIC_VECTOR(7 downto 0);
In any event, your example has a couple of problems:
0) Signed or unsigned????
1) First, try using the SYNOPSYS library as I did above. The module
will then compile without complaints. However, it's doubtful that
the logic is correct.
2) When adding two eight bit numbers, the result is nine bits long.
So, declare result as STD_LOGIC_VECTOR(8 downto 0).
3) Your ("0" & a) looks like sign extension, and that's what you need
to do for temp_b and carry, too:
result <= (('0' & a) + ('0' & temp_b)) + ("00000000" & temp_carry);
The MSB of result, result(8), is your new carry bit.
-andy
--
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatories
ape...@noao.edu.NOSPAM
Jan Decaluwe
>
> iccra <ic...@netsgo.com> wrote in article
> <#$8KbJbv...@news4.netsgo.com>...
> >
> > i have some problem. " + ", " & " operator for different type
> > i'm using ALDEC VHDL.
> >
> > ====================================================
> > LIBRARY IEEE;
> > USE IEEE.STD_LOGIC_1164.ALL;
> > USE IEEE.STD_LOGIC_ARITH.ALL;
> >
> > ----------------------------------------------------
> > SIGNAL pc : STD_LOGIC_VECTOR (8 DOWNTO 0);
> > pc <= pc + "1";
> > ----------------------------------------------------
> > Error: Operator "+" is not defined for such operands.
> > Error: Undefined type of expression.
> > ----------------------------------------------------
>
>
>
> pc <= pc + "000000001";
Bwaark!
>
> or if you use (in addition to your USEs above):
^^^^^^^^ (sic)
>
> library SYNOPSYS;
> use SYNOPSYS.std_logic_arith.all;
> use SYNOPSYS.std_logic_unsigned.all;
This then is the "brute force" approach: let's just import
everything and see if it "works" (understanding what we're doing
is not important). If you take this route, forget every hope
for maintainable and portable code.
Synopsys' std_logic_unsigned/std_logic_signed should be banned forever
because they mess with a standard. std_logic_vector was *not* intended
for arithmetic and it should be kept like that. You have ample choice
for arithmetic types: signed/unsigned (from std_logic_arith or num_std)
or (even better) *integer*.
So the correct answer to the original poster is that he's using
the wrong type. He imports std_logic_arith (that defines - if it's
the Synopsys version - signed/unsigned) but then attempts to use
std_logic_vector - which shows he hasn't a clue what and why he's
importing in the first place. An advise: when the simulator complains
about "Operator "+" not defined for such operands" - take it seriously.
>
> You can simply do a:
>
> pc <= pc + 1; -- note no '' or ""
Note that you can "simply" do this with integers without importing
anything.
Regards, Jan
--
===================================================================
Jan Decaluwe === Easics ===
Design Manager === VHDL-based ASIC design services ===
Tel: +32-16-395 600 ===================================
Fax: +32-16-395 619 Interleuvenlaan 86, B-3001 Leuven, BELGIUM
mailto:ja...@easics.be http://www.easics.com
Jan Decaluwe
> As for your math operation, I have not found any consistent way to
> express an adder or counter. Again when I switched from Orcad to
> Metamor, I had to change my syntax.
Something called an 'integer' was invented as a consistent way to count.
No doubt an obscure feature - but VHDL has them!
Geir Harris Hedemark
> for arithmetic types: signed/unsigned (from std_logic_arith or num_std)
> or (even better) *integer*.
I don't agree that integers are better than signed/unsigned, provided
you are writing synthesizable code. An integer type will synthesize to
a 32-bit signed value. You will get more control - and the same
functionality - if you use a "signed" type instead. Or an unsigned
type, which is my favourite just now.
Geir
Bart Willems
>
> Jan Decaluwe <ja...@easics.be> writes:
> > for arithmetic types: signed/unsigned (from std_logic_arith or num_std)
> > or (even better) *integer*.
>
> I don't agree that integers are better than signed/unsigned, provided
> you are writing synthesizable code. An integer type will synthesize to
> a 32-bit signed value.
>
That is *not* true. E.g. if you define a signal/variable as being
of type integer range 0 to 255, any decent synthesis tool will
synthesize this to an 8-bit wide signal. Of course if you use
unconstrainted integer types, you will end up with 32-bit wide
signals/variables. But, what do you think you will get if you use
unconstrainted unsigned variables/signals?
Regards, Bart
--
===================================================================
Bart Willems === Easics ===
ASIC Design Engineer === VHDL-based ASIC design services ===
===================================
mailto:ba...@easics.be http://www.easics.com/
Tel: +32-16-395 608
Jan Decaluwe
>
> Jan Decaluwe <ja...@easics.be> writes:
> > for arithmetic types: signed/unsigned (from std_logic_arith or num_std)
> > or (even better) *integer*.
>
> I don't agree that integers are better than signed/unsigned, provided
> you are writing synthesizable code. An integer type will synthesize to
> a 32-bit signed value.
Only if it's unconstrained.
> You will get more control - and the same
> functionality - if you use a "signed" type instead. Or an unsigned
> type, which is my favourite just now.
Integers should be used with range constraints (just as you do
with signed/unsigned) or under the form of integer subtypes -
not just for good synthesizability, but as good design practice
in general:
variable ATMCount is integer range 0 to 52;
variable Index is integer range -1 to 3;
From a "high-level" design perspective, this the superior solution because:
- You don't have to worry about bit-widths and signed/unsigned
representation - the synthesis tool takes care of that for you.
You just declare what matters: the integer range.
- Certain operators, such as indexing, that permit to write highly
efficient and elegant code, are defined using integers in VHDL,
and would require cumbersome type conversions otherwise.
- You have run-time checks on valid values of the variable/signal,
which you can't get with signed/unsigned. This provides much
earlier feedback on typical bugs like overrun/underrun conditions.
Regards, Jan
--
===================================================================
Jan Decaluwe === Easics ===
Design Manager === VHDL-based ASIC design services ===
Tel: +32-16-395 600 ===================================
Fax: +32-16-395 619 Interleuvenlaan 86, B-3001 Leuven, BELGIUM
bour...@my-dejanews.com
"iccra" <ic...@netsgo.com> wrote:
>
> i have some problem. " + ", " & " operator for different type
> i'm using ALDEC VHDL.
>
> ====================================================
> LIBRARY IEEE;
> USE IEEE.STD_LOGIC_1164.ALL;
> USE IEEE.STD_LOGIC_ARITH.ALL;
>
> ----------------------------------------------------
> SIGNAL pc : STD_LOGIC_VECTOR (8 DOWNTO 0);
> pc <= pc + "1";
> ----------------------------------------------------
> Error: Operator "+" is not defined for such operands.
> Error: Undefined type of expression.
> ----------------------------------------------------
> SIGNAL temp_b : STD_LOGIC_VECTOR(7 DOWNTO 0);
> SIGNAL temp_carry : STD_LOGIC;
>
> result <= ("0" & a) + temp_b + temp_carry
> ----------------------------------------------------
> Error: Undefined type of expression.
>
> thanks in advance...
>
>
I tried the following code:
LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;
USE IEEE.STD_LOGIC_ARITH.ALL;
entity test is
end test;
architecture a of test is
SIGNAL pc : STD_LOGIC_VECTOR (8 DOWNTO 0);
SIGNAL a : STD_LOGIC_VECTOR(7 DOWNTO 0);
SIGNAL temp_b : STD_LOGIC_VECTOR(7 DOWNTO 0);
SIGNAL temp_carry : STD_LOGIC;
signal result : std_logic_vector(8 downto 0);
begin -- a
pc <= pc + "1";
result <= ("0" & a) + temp_b + temp_carry;
end a;
I know of two versions of the package Std_Logic_Arith.
One is from Synopsys (and has been misleadingly put in the IEEE library) and
provides types SIGNED and UNSIGNED and arithmetic operations on them. With
this package, I've the error messages that the + operators are not
defined for the operand types. (I've no report about the & operator).
With the other version, which provides arithmetic operation on
std_logic_vectors, I've no error messages.
As far as I understand VHDL, this is the expected behavior in the two cases.
You should check and perhaps report the bug to your vendor.
Yours,
-- Jean-Marc
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Dave Farrance
>Geir Harris Hedemark wrote:
>[snip]
>That is *not* true. E.g. if you define a signal/variable as being
>of type integer range 0 to 255, any decent synthesis tool will
>synthesize this to an 8-bit wide signal. Of course if you use
>unconstrainted integer types, you will end up with 32-bit wide
>signals/variables. But, what do you think you will get if you use
>unconstrainted unsigned variables/signals?
With unsigned, you get consistent rollover from the maximum value to
zero when you add one (like real logic). Try that with integers and
your simulator will object.
--
Dave Farrance
Jan Decaluwe
>
> With unsigned, you get consistent rollover from the maximum value to
> zero when you add one (like real logic).
"Real logic" can behave in other useful ways, e.g. take a
saturating counter. Rollover counters are just one useful type
with interesting characteristics: they have an efficient hardware
implementation and you can describe them with a one-liner.
> Try that with integers and
> your simulator will object.
Try this one-liner:
Count := (Count + 1) mod 2**8;
Bart Willems
>
> Bart Willems <ba...@easics.be> wrote:
>
> >Geir Harris Hedemark wrote:
> >[snip]
> >That is *not* true. E.g. if you define a signal/variable as being
> >of type integer range 0 to 255, any decent synthesis tool will
> >synthesize this to an 8-bit wide signal. Of course if you use
> >unconstrainted integer types, you will end up with 32-bit wide
> >signals/variables. But, what do you think you will get if you use
> >unconstrainted unsigned variables/signals?
>
> your simulator will object.
>
That was not my point. I objected against the fact that the poster
mentioned as a drawback of integer types the fact that the synthesis
tool would generate 32-bit wide buses for integer signals. The fact
is that you have to constraint the integer signal to the size that
you need it to be. So, as I mentioned as an example, if you want an
integer which can take on the the values 0 to 255 you have to define
it like this:
signal MyIntegerSignal: integer range 0 to 255;
In exactly the same way, if you want an 8-bit wide unsigned signal,
you have to define it like this:
signal MyUnsignedSignal: unsigned (7 downto 0);
My point was that, if you define a signal this way:
signal MyUnsigned: unsigned;
then the synthesis tool will not generate an 8-bit wide bus for it.
If you want to compare the advantages/disadvantages of integer
types and unsigned types, you should at least compare analogous
things.
Bart
--
===================================================================
Bart Willems === Easics ===
ASIC Design Engineer === VHDL-based ASIC design services ===
===================================
mailto:ba...@easics.be http://www.easics.com/
Tel: +32-16-395 608
Geir Harris Hedemark
> My point was that, if you define a signal this way:
>
> signal MyUnsigned: unsigned;
>
> then the synthesis tool will not generate an 8-bit wide bus for it.
The synthesis tool will actually object, since the above line is not
valid VHDL, afaik.
signal MyInt : integer;
is legal VHDL, however, and it will synthesize just fine. It might not
give you the desired hardware.
I want code that is easy for beginners to write. Integers are easy to
use - true. But they are also easy to use wrong.
Geir
Andy Peters
Jan Decaluwe <ja...@easics.be> wrote in article
<35C6CA2F...@easics.be>...
> Andy Peters wrote:
> >
> >
> >
> > You can do one of two things:
> ^^^^^^^^^^ (sic)
> >
> > pc <= pc + "000000001";
>
> Bwaark!
> > library SYNOPSYS;
> > use SYNOPSYS.std_logic_arith.all;
> > use SYNOPSYS.std_logic_unsigned.all;
>
> This then is the "brute force" approach: let's just import
> everything and see if it "works" (understanding what we're doing
> is not important). If you take this route, forget every hope
> for maintainable and portable code.
I agree that it's somewhat brute force. I keep having to look and
see what fargin' library handles what.
> Synopsys' std_logic_unsigned/std_logic_signed should be banned
forever
> because they mess with a standard. std_logic_vector was *not*
intended
> for arithmetic and it should be kept like that. You have ample
choice
> for arithmetic types: signed/unsigned (from std_logic_arith or
num_std)
> or (even better) *integer*.
How about getting Synopsys to support VHDL'93? Perhaps by Y2K.
Bastids.
Here's a question: what libraries SHOULD we use?
Another query: is there a list somewhere of what functions are in
what library? What's in std_logic_arith, anyway? Ditto for num_std?
Or is that numeric_std?
> So the correct answer to the original poster is that he's using
> the wrong type. He imports std_logic_arith (that defines - if it's
> the Synopsys version - signed/unsigned) but then attempts to use
> std_logic_vector - which shows he hasn't a clue what and why he's
> importing in the first place. An advise: when the simulator
complains
> about "Operator "+" not defined for such operands" - take it
seriously.
The ol' salt about C compiling: turn all warnings on all the time and
heed them.
> > You can simply do a:
> >
> > pc <= pc + 1; -- note no '' or ""
>
> Note that you can "simply" do this with integers without importing
> anything.
Agreed.
Rickman
>
> Rickman wrote:
>
> > As for your math operation, I have not found any consistent way to
> > express an adder or counter. Again when I switched from Orcad to
> > Metamor, I had to change my syntax.
>
> Something called an 'integer' was invented as a consistent way to count.
> No doubt an obscure feature - but VHDL has them!
Like I said, I have not found a consistent way to express an adder or
counter. This implies the hardware which often includes such features as
carry in and carry out. There is nothing in integers which indicate
carry in or carry out in an efficient manner. To make full use of the
hardware available I had to use Logiblox.
Integers and VHDL may be wonderful things. But it can be hard to get it
to do what you want.
Another problem I had when trying to use integers as counters is
converting them to std_logic_vector when using the result. It would seem
that some compilers support the std packages differently.
Rickman
> Here's a question: what libraries SHOULD we use?
>
> Another query: is there a list somewhere of what functions are in
> what library? What's in std_logic_arith, anyway? Ditto for num_std?
> Or is that numeric_std?
This is one of my big compaints about the VHDL tools. When I program in
C, I don't remember every (or any) routine in the standard libraries.
But I have help at my fingertips. Type in a function name and hit F1,
poof! up comes a complete discription of the routine and some info on
how to use along with links to related functions. If I had that in VHDL
I would have learned how to use the libraries by now!!!
It would seem that VHDL now is where C was over 10 years ago!
How long do you think it will take to catch up???
Geir Harris Hedemark
> This is one of my big compaints about the VHDL tools. When I program in
> C, I don't remember every (or any) routine in the standard libraries.
> But I have help at my fingertips. Type in a function name and hit F1,
This has got nothing to do with either C or VHDL. It is your editor
that is at fault.
I would have no problems getting Emacs to find an arbitrary function
definition in a standard library, provided I wrote the Lisp to do
it. But I don't think you would like emacs much.
Geir
Dave Farrance
>How about getting Synopsys to support VHDL'93? Perhaps by Y2K.
>Bastids.
Seems they're getting a reputation like the Microsoft of ASIC
synthesis: Industry standards? OUR way is the standard!
>Here's a question: what libraries SHOULD we use?
>
>Another query: is there a list somewhere of what functions are in
>what library? What's in std_logic_arith, anyway? Ditto for num_std?
>Or is that numeric_std?
Well, numeric_std is defined in IEEE 1076.3-1997 and, suprisingly for
an IEEE document, it seems readable for the average VHDL user.
std_logic_arith was present in all the synthesisers and simulators
that I've used but I can't find any definition for it. I can guess
where it originated, though.
--
Dave Farrance
Geir Harris Hedemark
> Seems they're getting a reputation like the Microsoft of ASIC
> synthesis: Industry standards? OUR way is the standard!
Well, they are right, aren't they?
Obtw: Microsoft has never cooperated with an IEEE working group to
make an open vhdl-for-synthesis standard. From what I've heard,
Microsoft has used incompatabilities as a leverage to push their own
products. I have never experienced this from Synopsys, although their
HDL compiler is a shoddy product at best.
> std_logic_arith was present in all the synthesisers and simulators
> that I've used but I can't find any definition for it. I can guess
> where it originated, though.
The definition can, afair, be found on Synopsys' web site. From the
header of std_logic_arith.vhd, found in the DC installation tree
(packages/IEEE/src/std_logic_arith.vhd)
-- Copyright (c) 1990,1991,1992 by Synopsys, Inc. All rights reserved. --
-- --
-- This source file may be used and distributed without restriction --
-- provided that this copyright statement is not removed from the file --
-- and that any derivative work contains this copyright notice. --
Geir
ems
<gei...@hridil.ifi.uio.no> wrote:
>d...@technologist.com (Dave Farrance) writes:
>> Seems they're getting a reputation like the Microsoft of ASIC
>> synthesis: Industry standards? OUR way is the standard!
>
>Well, they are right, aren't they?
>
>Obtw: Microsoft has never cooperated with an IEEE working group to
>make an open vhdl-for-synthesis standard. From what I've heard,
>Microsoft has used incompatabilities as a leverage to push their own
>products. I have never experienced this from Synopsys, although their
>HDL compiler is a shoddy product at best.
I wonder what would have happened if Synopsys *hadn't* cooperated on
1076.6... maybe we'd have got a standard that paid more than just lip
service to VHDL'93.
If this isn't using an incompatibility as leverage to push your own
products, I don't know what is.
Evan
Spikey
Rickman wrote:
> Andy Peters wrote:
> > Here's a question: what libraries SHOULD we use?
> >
> > Another query: is there a list somewhere of what functions are in
> > what library? What's in std_logic_arith, anyway? Ditto for num_std?
> > Or is that numeric_std?
>
> This is one of my big compaints about the VHDL tools. When I program in
> C, I don't remember every (or any) routine in the standard libraries.
> But I have help at my fingertips. Type in a function name and hit F1,
> poof! up comes a complete discription of the routine and some info on
> how to use along with links to related functions. If I had that in VHDL
[snip]
Any decent simulator should provide the source code for packages compiled
into the IEEE or any other supplied library.
For example ModelSim has a directory called vhdl_src in the installation
directory
which contains the source code for ieee, synopsys & vital packages
The package (as opposed to the package body) will give you the full range
of
options available.
If you don't know what's in these packages you're referencing, how can you
expect to use them effectively?
Geir Harris Hedemark
> If this isn't using an incompatibility as leverage to push your own
> products, I don't know what is.
What? Is someone's synthesizer incompatible with 1076.6? I would think
that was more or less impossible, given the small number of allowable
constructs. ;)
Geir
Andy Peters
<35C8786A...@NOSPAM.esperan.com>...
I might add that the full range of options is bewildering.
> If you don't know what's in these packages you're referencing, how
can you
> expect to use them effectively?
****Why should I have to thumb through the source code to find out
what functions I should use?**** I certainly don't thumb through the
source code for stdio.h if I want to do a printf(). I open my C
programming book and look at the library reference and it's all
there.
I also don't have to figure out whether the functions I want to use
are in the IEEE library, or the SYNOPSYS library, or the METAMOR
library, or some other place. Do I use the SYNOPSYS version of
std_logic_arith, or the IEEE version?
ems
wrote:
>Spikey <br...@NOSPAM.esperan.com> wrote in article
><35C8786A...@NOSPAM.esperan.com>...
>>
>>
>> Rickman wrote:
>>
>> > Andy Peters wrote:
>> > > Here's a question: what libraries SHOULD we use?
>> > >
>> > > Another query: is there a list somewhere of what functions are
>in
>> > > what library? What's in std_logic_arith, anyway? Ditto for
>num_std?
>> > > Or is that numeric_std?
>> >
>I also don't have to figure out whether the functions I want to use
>are in the IEEE library, or the SYNOPSYS library, or the METAMOR
>library, or some other place.
>Do I use the SYNOPSYS version of std_logic_arith, or the IEEE version?
interestingly, they're both the same thing (both synopsys). for some
obscure reason people normally put the synopsys package in the IEEE
library. my favourite theory is that it's FUD.
the only two obvious choices are the IEEE's numeric_std and synopsys's
std_logic_arith. metamor's version of numeric_std is NUM_STD, and i'd
recommend that you use this. the abbreviated name is due to the
appalling library handling in metamor. if you use a simulator as well,
then you should alias this (in your simulator setup file, or whatever)
to the simulator vendor's numeric_std.
numeric_std is free code, and it's not overly surprising that there
isn't official documentation. however, the source is simple, and
you're (much) better off checking the source than reading someone
else's documentation. if you want a quick summary, pick up the '1164
packages quick reference card' from qualis's web site
(http://www.qualis.com). you'll have to turn on cookies, if you've got
them disabled, or you'll end up going round in circles and getting
*very* annoyed.
evan
Spikey
Andy Peters wrote:
> Spikey <br...@NOSPAM.esperan.com> wrote in article
> <35C8786A...@NOSPAM.esperan.com>...
> [snip]
>
> > If you don't know what's in these packages you're referencing, how
> > can you expect to use them effectively?
>
> ****Why should I have to thumb through the source code to find out
> what functions I should use?**** I certainly don't thumb through the
> source code for stdio.h if I want to do a printf(). I open my C
> programming book and look at the library reference and it's all
> there.
OK you don't necessarily have to wade through the sourcecode, the package
header gives all the options without the
source
e.g
package std_logic_arith is
...
function "+"(L: UNSIGNED; R: UNSIGNED) return UNSIGNED;
function "+"(L: SIGNED; R: SIGNED) return SIGNED;
function "+"(L: UNSIGNED; R: SIGNED) return SIGNED;
function "+"(L: SIGNED; R: UNSIGNED) return SIGNED;
etc
Point taken tho' - there are a lot of options...
Jan Decaluwe
>
> I also don't have to figure out whether the functions I want to use
> are in the IEEE library, or the SYNOPSYS library, or the METAMOR
> library, or some other place. Do I use the SYNOPSYS version of
> std_logic_arith, or the IEEE version?
>
The short answer: as far as I can judge, it is industry standard
practice to use the Synopsys std_logic_arith package, analyzed in the
IEEE library.
The longer story, as briefly as possible: (years 1990 to now or so)
Originally Synopsys defined signed/unsigned in the std_logic_arith
package and put in a SYNOPSYS library. All this was very right.
Then they put it (also) in the IEEE library, giving the impression
it is a standard while it's not. This was very wrong.
Then other vendors like Cadence and Mentor created a different package with
the same name in the same library, but completely different functionality
(that you don't want to know about). This was extremely wrong.
Hence the mess. Looks like a right-wing conspiracy against VHDL to me!
The latest on this is that the already infamous "Design Reuse Manual",
co-authored by Synopsys, contains an example using std_logic_arith,
which would only work with their competitors' package!
It 's really a mess.
Regards, Jan
--
===================================================================
Jan Decaluwe === Easics ===
Design Manager === VHDL-based ASIC design services ===
Tel: +32-16-395 600 ===================================
Fax: +32-16-395 619 Interleuvenlaan 86, B-3001 Leuven, BELGIUM
Andy Peters
<35c97b5e...@news.dial.pipex.com>...
> On 5 Aug 1998 18:11:45 GMT, "Andy Peters" <ape...@noao.edu.NOSPAM>
> wrote:
> >Do I use the SYNOPSYS version of std_logic_arith, or the IEEE
version?
>
> interestingly, they're both the same thing (both synopsys). for
some
> obscure reason people normally put the synopsys package in the IEEE
> library. my favourite theory is that it's FUD.
OK, then here's one to ponder. I originally did my current Xilinx
design using the Metamor tools that came with Foundation 1.4.
Everything compiled/analyzed/etc and I got a chip out that *barely*
met timing - one of my nets took 39.3 ns and I've got a 40 ns clock.
OK, I figured it would be fun to try FPGA Express and see what I
could do to tweak it - it's got that nice constraint entry
spreadsheet so I don't have to futz with the .ucf file (and what did
the synthesizer call my clock signal after synthesizing, anyway?).
OK, great. With Metamor, my modules had the following library uses:
library IEEE;
use IEEE.std_logic_1164.all;
library SYNOPSYS;
use SYNOPSYS.std_logic_arith.all;
use SYNOPSYS.std_logic_unsigned.all;
OK, FPGA Express, being a Synopsys tool, should recognize its own
damn library, huh? WRONG. (Unless there was a configuration thing I
missed somewhere.) Nope, gotta do a
use IEEE.std_logic_arith.all;
use IEEE.std_logic_unsigned.all;
instead!
I think that when the revolution comes, the people at Synopsys are
gonna be the first with their backs to the wall.
> the only two obvious choices are the IEEE's numeric_std and
synopsys's
> std_logic_arith. metamor's version of numeric_std is NUM_STD, and
i'd
> recommend that you use this. the abbreviated name is due to the
> appalling library handling in metamor. if you use a simulator as
well,
> then you should alias this (in your simulator setup file, or
whatever)
> to the simulator vendor's numeric_std.
OK, that explains my confusion with num_std vs numeric_std.
> numeric_std is free code, and it's not overly surprising that there
> isn't official documentation. however, the source is simple, and
> you're (much) better off checking the source than reading someone
> else's documentation. if you want a quick summary, pick up the
'1164
> packages quick reference card' from qualis's web site
> (http://www.qualis.com). you'll have to turn on cookies, if you've
got
> them disabled, or you'll end up going round in circles and getting
> *very* annoyed.
Off-topic: Speaking of cookies, WRQ has this tool called @guard,
which among other things, allows you to selective block/allow cookies
for various sites. It also kills ad banners and referrer fields and
all of those things Web Sites use to find out who you are. I
downloaded a beta version and actually got involved in the beta
testing (since it brought my NT box to a blue screen of death; that's
now fixed). It's at http://www.atguard.com/Welcome.html and might be
worth a look.
-andy
Paul J. Menchini
:> for arithmetic types: signed/unsigned (from std_logic_arith or num_std)
:> or (even better) *integer*.
: I don't agree that integers are better than signed/unsigned, provided
: you are writing synthesizable code. An integer type will synthesize to
: a 32-bit signed value. You will get more control - and the same
: functionality - if you use a "signed" type instead. Or an unsigned
: type, which is my favourite just now.
Don't forget the ability to specify a subrange
variable threeBit : integer range 0 to 7;
Paul
--
Paul Menchini | me...@mench.com | "Se tu sarai solo,
Menchini & Associates | www.mench.com | tu sarai tutto tuo."
P.O. Box 71767 | 919-479-1670[v] | -- Leonardo Da Vinci
Durham, NC 27722-1767 | 919-479-1671[f] |