shift_right/ shift_left

[ZHIQUAN]

shift_right(ARG:signed;Count:Natural) return signed

I check the syntax of the shift_right from a vhdl book. I try to use
it according to the syntax but still get the Error : shift_right can
not have such operands in this context.

Is there some special requirement for using this command? Any help
about this is very appreciated.

 

[Mike Treseler]

shift_right(ARG:signed;Count:Natural) return signed

That syntax looks ok.

I check the syntax of the shift_right from a vhdl book. I try to use
it according to the syntax but still get the Error : shift_right can
not have such operands in this context.

Maybe a type mismatch.
Check you declarations.

Did you
use ieee.numeric_std.all;
?

See sync_template.vhd here:
http://home.comcast.net/~mike_treseler/
for a related example using rotate_left(reg_v,1)

If that doesn't do it. Post your code.


-- Mike Treseler

 

[ZHIQUAN]

That syntax looks ok.


Maybe a type mismatch.
Check you declarations.

Did you
 use ieee.numeric_std.all;
?

See sync_template.vhd here:http://home.comcast.net/~mike_treseler/
for a related example using rotate_left(reg_v,1)

If that doesn't do it. Post your code.

       -- Mike Treseler

I have tried your sync_template. It is no problem. I guess mine
doesn' work because of the 'Signed' type. The libraries I used are :
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.numeric_bit.all;
use IEEE.numeric_std.all;
library UNISIM;
use UNISIM.VComponents.all;
library work;
use work.systemsize.all;
--------------------------------------------------------
signal thtdoutb: std_logic_vector(31 downto 0);
signal signthtdoutb：signed(31 downto 0);
signthtdoutb <= signed(thtdoutb);

variable tmpb :signed(31 downto 0);
tmpb := shift_left(signthtdoutb,1);
-----------------------------------------------------
previously I use
tmpb(31 downto 1):=signthtdoutb(30 downto 0);
tmpb(0) :='0';
There is no problem.
I have to do such a similar thing many places in my codes. I thought
using 'Shift_left'/' Shift_right' will be better.

When I did not use the 'SHIFT_LEFT/RIGHT' in my codes. The 'CHECK
SYNTAX' is no problem.
But when I use Modelsim, it gives the error : Identifier "signed" is
not directly visible
I heard that ieee.std_logic_arith and numeric_std have 'SINGED'
function. Even though I remove one of them, it doesn't work either;

 

[Ben Jones]

ZHIQUAN wrote:
The libraries I used are :
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.numeric_bit.all;
use IEEE.numeric_std.all;

Aaaaaaaaaaaaaaaaarrrrrrrrrgh! Stop the madness!

Just use:

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

The others are unnecessary and/or not recommended and/or downright evil.

-Ben-

 

[ZHIQUAN]

Aaaaaaaaaaaaaaaaarrrrrrrrrgh! Stop the madness!

Just use:

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

The others are unnecessary and/or not recommended and/or downright evil.

-Ben-

Yeah, It looks messy. I have seen the template of Mike. He only
included the 2 libraries like you have given. But if i removed them,
They will get errors as well like : Undefined symbol
'conv_std_logic_vector; + can not have such operands in this context.

 

[Martin Thompson]

Hi Ben,

Just use:

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

The others are unnecessary and/or not recommended and/or downright
evil.

Hi Ben,

Do you have any clout in Xilinx to get all the standard templates and
appnote code to do that instead of _unsigned and _arith all over the place?

Cheers,
Martin

 

[Mike Treseler]

Yeah, It looks messy. I have seen the template of Mike. He only
included the 2 libraries like you have given. But if i removed them,
They will get errors as well like : Undefined symbol
'conv_std_logic_vector; + can not have such operands in this context.

That function does not exist in numeric_std.
Use the signed type and functions here:
http://www.eda.org/rassp/vhdl/models/standards/numeric_std.vhd
If you just use signed type for all the
signed vectors, you won't need conversions at all.

-- Mike Treseler

 

[Ben Jones]

Hi Ben,

Do you have any clout in Xilinx to get all the standard templates and
appnote code to do that instead of _unsigned and _arith all over the
place?

Wow, if only!

I have the power to complain vociferously about it in internal code reviews,
which I exercise at every opportunity. I also have the power to file CRs on
the documentation, but it's a tough thing to get changed. The worst
offenders are the XST manual and the Synthesis and Simulation Design Guide.

But the XST engineers are too busy developing XST to be able to justify
spending time on replacing one working code example A with another working
code example B, whatever the relative merits of A and B. You can't expect a
technical writer to do it because it needs to be tested and working before
it goes into the documentation.

And when some new code example needs to go into the documentation, of course
the first thing that happens is the author goes and fetches some existing
example as a starting point, so they can make sure they're consistent with
the prevailing practice. Whoops!

Appnote code is the hardest to fix. When code originates within the tools
and/or IP organisations it's usually gone through a review process against
some coding standard. Appnotes often come from outside this bubble and the
release process for those, to be honest, seems to be optimized for "getting
working stuff to customers" rather than "checking for rigorous compliance
with some standard or other".

Here are the raw numbers of occurances of the different library names in as
of the latest build I have installed:

xst.pdf sim.pdf
std_logic_unsigned: 61 22
std_logic_signed: 8 5
std_logic_arith: 13 5
numeric_std: 14 3

Sheesh. If enough people offer to buy me beer, I will sit down one evening
(or several!), go through all the example code which has "bad" libraries,
upgrade it to numeric_std, re-test the code against the latest tools, and
submit my changes. This does *not* guarantee that the documentation will end
up fixed, but I'm willing to try it anyway. Be prepared to add your names to
some sort of petition when I go to file the CR.

Can people let me know if there are any other documents I've missed that are
suffering from VHDL Library Disease, or any other pertinent information that
might save me some of the pain from my impending martyrdom?

Cheers,

-Ben-

 

[Mike Treseler]

Here are the raw numbers of occurances of the different library names in as
of the latest build I have installed:

xst.pdf sim.pdf
std_logic_unsigned: 61 22
std_logic_signed: 8 5
std_logic_arith: 13 5
numeric_std: 14 3

Sheesh. If enough people offer to buy me beer, I will sit down one evening
(or several!), go through all the example code which has "bad" libraries,
upgrade it to numeric_std, re-test the code against the latest tools, and
submit my changes.

I'll buy the beer.

-- Mike Treseler

 

[ZHIQUAN]

Wow, if only!

I have the power to complain vociferously about it in internal code reviews,
which I exercise at every opportunity. I also have the power to file CRs on
the documentation, but it's a tough thing to get changed. The worst
offenders are the XST manual and the Synthesis and Simulation Design Guide.

But the XST engineers are too busy developing XST to be able to justify
spending time on replacing one working code example A with another working
code example B, whatever the relative merits of A and B. You can't expect a
technical writer to do it because it needs to be tested and working before
it goes into the documentation.

And when some new code example needs to go into the documentation, of course
the first thing that happens is the author goes and fetches some existing
example as a starting point, so they can make sure they're consistent with
the prevailing practice. Whoops!

Appnote code is the hardest to fix. When code originates within the tools
and/or IP organisations it's usually gone through a review process against
some coding standard. Appnotes often come from outside this bubble and the
release process for those, to be honest, seems to be optimized for "getting
working stuff to customers" rather than "checking for rigorous compliance
with some standard or other".

Here are the raw numbers of occurances of the different library names in as
of the latest build I have installed:

xst.pdf sim.pdf
std_logic_unsigned: 61 22
std_logic_signed: 8 5
std_logic_arith: 13 5
numeric_std: 14 3

Sheesh. If enough people offer to buy me beer, I will sit down one evening
(or several!), go through all the example code which has "bad" libraries,
upgrade it to numeric_std, re-test the code against the latest tools, and
submit my changes. This does *not* guarantee that the documentation will end
up fixed, but I'm willing to try it anyway. Be prepared to add your names to
some sort of petition when I go to file the CR.

Can people let me know if there are any other documents I've missed that are
suffering from VHDL Library Disease, or any other pertinent information that
might save me some of the pain from my impending martyrdom?

Cheers,

-Ben-

I will buy the beer too .^^ thanks

 

[Martin Thompson]

Sheesh. If enough people offer to buy me beer, I will sit down one evening
(or several!), go through all the example code which has "bad" libraries,
upgrade it to numeric_std, re-test the code against the latest tools, and
submit my changes. This does *not* guarantee that the documentation will end
up fixed, but I'm willing to try it anyway. Be prepared to add your names to
some sort of petition when I go to file the CR.

Count me in!

Martin

Can people let me know if there are any other documents I've missed that are
suffering from VHDL Library Disease, or any other pertinent information that
might save me some of the pain from my impending martyrdom?

I seem to recall the ISE editors templates used to suffer also, but I
haven't used it since 6.something so I could be wrong

Cheers,
Martin

 

[ZHIQUAN]

That function does not exist in numeric_std.
Use the signed type and functions here:http://www.eda.org/rassp/vhdl/models/standards/numeric_std.vhd
If you just use signed type for all the
signed vectors, you won't need conversions at all.

 -- Mike Treseler

In my codes, I need read/ write my RAM. So I cannot avoid to do the
address （std_logic_vector） addition or subtration. How to solve the
prblem if only using ieee. std_logic_116 and use
ieee.numeric_std.all;
ieee.numeric_std cannot do the '+'/'-' operations in the type of
std_logic_vector.

Ieee.std_logic_arith.all can do that. But if I included
ieee.numeric.std.all and ieee.std_logic_arith. ISE cannot recongize
the '+' and 'shift'.

 

[Ben Jones]

I seem to recall the ISE editors templates used to suffer also, but I
haven't used it since 6.something so I could be wrong

Good point...

Aw no, this is *awful*. Every single example is full of "if <clock>='1' and
<clock>'event then"... <retch>
I think I need a lie down.

Thankfully most of the code templates don't have any libraries in them at
all (there's a particularly obnoxious barrel shifter in there which needs
attention though).

Is there a good, authoritative book/article/webpage by some respected
industry figure that explains why these things are considered bad practice?
I know why, and I can explain why, but it would be nice to have a good
citation to back up my argument.

Cheers,

-Ben-

 

[Mike Treseler]

In my codes, I need read/ write my RAM. So I cannot avoid to do the
address （std_logic_vector） addition or subtration. How to solve the
prblem if only using ieee. std_logic_116 and use
ieee.numeric_std.all;

Look at the example I gave you:

q <= std_logic_vector(reg_v);

Do the math in signed/unsigned
then cast the output port assignment.

-- Mike Treseler

 

[Jonathan Bromley]

Is there a good, authoritative book/article/webpage by some respected
industry figure that explains why these things are considered bad practice?
I know why, and I can explain why, but it would be nice to have a good
citation to back up my argument.

I take the point, but.... engineering isn't like that.... good
arguments stand or fall on their own merits, not on whether
they match "authority". I'll do whatever the heck I like,
thanks, provided I can prove convincingly that:

a) it works
b) it can be used and understood by others, not just me
c) it's portable across tools
d) it gives me something that can be re-used across projects

Using numeric_std in preference to std_logic_horrible
can, I think, be shown to satisfy all these!
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Gerhard Hoffmann]

Using numeric_std in preference to std_logic_horrible
can, I think, be shown to satisfy all these!

Wouldn't it be better, now, that things have stabilized, to move features like
signed, unsigned, std_logic into the language itself instead of keeping them
in somewhat arbitrary libraries?

The compiler could be sure that a constant mangled through a conversion
function is still a constant, there could be more dependable default behaviour
and we could do away with, or at least deprecate some constructs.

Example: How do we asign an address:

int: 16#abcd#
slv for multiples of 4 bits: x"abcd"
slv for 17 bits: slv(to_unsigned(4711, 17))
slv for 35 bits: slv(to_unsigned( ooohps, I have a 32 bit computer only...

There are just too many ways to express the same thing.

regards, Gerhard

 

[Colin Paul Gloster]

In timestamped Sat, 28
Apr 2007 21:55:24 +0100, Jonathan Bromley
<[email protected]> posted:
"On Fri, 27 Apr 2007 14:07:47 +0100, "Ben Jones"

Is there a good, authoritative book/article/webpage by some respected
industry figure that explains why these things are considered bad practice?
I know why, and I can explain why, but it would be nice to have a good
citation to back up my argument.

I take the point, but.... engineering isn't like that.... good
arguments stand or fall on their own merits, not on whether
they match "authority". [..]

[..]"


Good "arguments stand or fall on their own merits" to a logician,
whereas truth is not as important as popularity when it comes to too
many trend followers.

 

[Ben Jones]

I take the point, but.... engineering isn't like that.... good
arguments stand or fall on their own merits, not on whether
they match "authority".

I would love to be able to agree with that but, pragmatically, perhaps
unfortunately, engineering *is* like that. Which one of these arguments do
you think would sound more convincing to an engineering manager:

"We should change the VHDL syntax in our example code because one of our
hundreds of engineers says he doesn't like the existing syntax."

vs.

"We should change the VHDL syntax in our example code because Mike
Treseler
and Jonathan Bromley and Ray Andraka and Jim Lewis and Ken Chapman and
Bob
Perlman and [insert more gurus] say the existing syntax is bad practice,
and those guys are respected and know what they're talking about."

I might be *right*, but it doesn't mean anyone will *listen*. For what it's
worth, Xilinx is much better than other places I've seen in this respect,
but still: to some extent experience does matter, and as far as I can see it
always will.

If an argument falls on its own merits in the middle of a forest and there's
no-one there to hear it, does it make a noise?

-Ben-

 

[Jonathan Bromley]

Which one of these arguments do you think would
sound more convincing to an engineering manager:

[...]

OK, I admit defeat

Would it be too cynical to try
"We should change our templates because lots of people
are making fun of what we do right now" ?

Or, perhaps less outrageously,

numeric_std has been part of the IEEE VHDL standard for
a long time; std_logic_[un]signed and std_logic_arith
are not.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Jim Lewis]

Gerhard,

Wouldn't it be better, now, that things have stabilized, to move features like
signed, unsigned, std_logic into the language itself instead of keeping them
in somewhat arbitrary libraries?

In Accellera 1076-2006-D3.0, these packages were moved from their
current individual standard into the main 1076 standard, however,
they still are in separate packages. This is consistent with the
VHDL style as even the "standard" library is in a package - it is
just implicitly visible. I lobbied for these packages to be
implicitly visible, however, there is concern about conflicts
with existing user code.

We did introduce context design units though. This gives one the
ability with a single reference to include a set of libraries
and packages.

The compiler could be sure that a constant mangled through a conversion
function is still a constant, there could be more dependable default behaviour
and we could do away with, or at least deprecate some constructs.

Example: How do we asign an address:

int: 16#abcd#
slv for multiples of 4 bits: x"abcd"
slv for 17 bits: slv(to_unsigned(4711, 17))
slv for 35 bits: slv(to_unsigned( ooohps, I have a 32 bit computer only...

Bit strings literals have been upgraded to allow a length prefix:
17X"ABCD" is 17 bits.

With a length specification, we can also now do decimal:
8D"255" - nice for > 31 bit values with array types


Accellera 1076-2006-D3.0 was standardized in July 2006.
Vendors should already be implementing it (I know some
that are well into their implementation).

Cheers,
Jim