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]

ZHIQUAN wrote:

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]

On 25 Apr, 00:46, Mike Treseler <mike_trese...@comcast.net> wrote:

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

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" <threeinchnail@gmail.com> wrote in message
news:1177579359.577802.15840@c18g2000prb.googlegroups.com...
On 25 Apr, 00:46, Mike Treseler <mike_trese...@comcast.net> wrote:

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]

On 26 Apr, 11:11, "Ben Jones" <ben.jo...@xilinx.com> wrote:

"ZHIQUAN" <threeinchn...@gmail.com> wrote in message

news:1177579359.577802.15840@c18g2000prb.googlegroups.com...
On 25 Apr, 00:46, Mike Treseler <mike_trese...@comcast.net> wrote:

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-

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,
"Ben Jones" <ben.jones@xilinx.com> writes:

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

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

 

[Mike Treseler]

ZHIQUAN wrote:

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]

"Martin Thompson" <martin.j.thompson@trw.com> wrote in message
news:u647jtai1.fsf@trw.com...

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]

Ben Jones wrote:

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]

On 4ÔÂ26ČŐ, ĎÂÎç5Ęą50ˇÖ, "Ben Jones" <ben.jo...@xilinx.com> wrote:

"Martin Thompson" <martin.j.thomp...@trw.com> wrote in message

news:u647jtai1.fsf@trw.com...

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-

I will buy the beer too .^^ thanks

 

[Martin Thompson]

"Ben Jones" <ben.jones@xilinx.com> writes:

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

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

 

[ZHIQUAN]

On 26 Apr, 17:18, Mike Treseler <mike_trese...@comcast.net> wrote:

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

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]

"Martin Thompson" <martin.j.thompson@trw.com> wrote in message
news:uirbis1bg.fsf@trw.com...

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

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]

ZHIQUAN wrote:

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]

On Fri, 27 Apr 2007 14:07:47 +0100, "Ben Jones"
<ben.jones@xilinx.com> wrote:

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
jonathan.bromley@MYCOMPANY.com
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]

On Sat, 28 Apr 2007 21:55:24 +0100, Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> wrote:

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

 

[Jonathan Bromley]

On Tue, 01 May 2007 09:48:01 -0700,
Mike Treseler <mike_treseler@comcast.net> wrote:

Jonathan has covered the main points.
Add spin as needed.
Add references if that would help the case.

I confess that I'm not a great lover of textbooks
in general, but I had a quick look through those that
fell to hand and didn't find very much at all about
this issue. I wish I could have found Ben some good
documentary backup, but I honestly can't!

This is a public forum.

But not one that carries a lot of academic clout.
Somehow I don't quite see this working...

[Treseler2007] Treseler M, On the inadvisability of
unnecessary introduction of signals, Proc. comp.lang.vhdl...

If you see what I mean
--
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
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

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

 

[Ben Jones]

"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message
news:2pfg3355s1bnn1saln9c7igjuummnc54ai@4ax.com...

I confess that I'm not a great lover of textbooks
in general, but I had a quick look through those that
fell to hand and didn't find very much at all about
this issue. I wish I could have found Ben some good
documentary backup, but I honestly can't!

This always seems to happen in matters of "best practice": most textbook
authors want to tell you what *can* be done, not always what *should* be
done. Having said that, in the software engineering world the situation
seems quite a lot better.

What I feel we need is something like the "Exceptional C++" / "More
Exceptional C++" books, but for VHDL.

This is a public forum.
But not one that carries a lot of academic clout.
Somehow I don't quite see this working...
[Treseler2007] Treseler M, On the inadvisability of
unnecessary introduction of signals, Proc. comp.lang.vhdl...

It's worth a try, even if just to see if the reviewer at the other end is
paying attention!

-Ben-

 

[Mike Treseler]

"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message
news:2pfg3355s1bnn1saln9c7igjuummnc54ai@4ax.com...
But not one that carries a lot of academic clout.
Somehow I don't quite see this working...
[Treseler2007] Treseler M, On the inadvisability of
unnecessary introduction of signals, Proc. comp.lang.vhdl...

Ben Jones wrote:

It's worth a try, even if just to see if the reviewer at the other end is
paying attention!

Quoting scholarly journals would not help me
win an argument with my boss.
Evidence of what the competition is up to just might.
http://www.altera.com/support/examples/download/ram.zip


-- Mike Treseler

 

[Paul Uiterlinden]

Mike Treseler wrote:

Evidence of what the competition is up to just might.
http://www.altera.com/support/examples/download/ram.zip

OK: use of ieee.numeric_std.

Not OK: use of a signal for modeling a RAM.
That's a waist of memory and simulation speed.

--
Paul Uiterlinden
www.aimvalley.nl
e-mail addres: remove the not.