shift_right/ shift_left
ZHIQUAN
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
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" <threei...@gmail.com> wrote in message
news:1177579359....@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
> "ZHIQUAN" <threeinchn...@gmail.com> wrote in message
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
"Ben Jones" <ben....@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...@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html
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
"Martin Thompson" <martin.j...@trw.com> wrote in message
news:u647jt...@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
> 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
> "Martin Thompson" <martin.j.thomp...@trw.com> wrote in message
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 :-)
Ben Jones
>> 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
> 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
<ben....@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...@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
>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
Apr 2007 21:55:24 +0100, 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". [..]
[..]"
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
"Jonathan Bromley" <jonathan...@MYCOMPANY.com> wrote in message
news:2rc733pfrsqng7jos...@4ax.com...
> On Fri, 27 Apr 2007 14:07:47 +0100, "Ben Jones"
> <ben....@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 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
"Ben Jones" <ben....@xilinx.com> wrote:
> 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.
Jim Lewis
>> 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?
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
Jim Lewis
> 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;
> std_logic_vector.
>
> Ieee.std_logic_arith.all can do that.
Actually, std_logic_arith does not support std_logic_vector operations
(other than std_logic_vector results from either a type signed or unsigned
operation). It is std_logic_unsigned that allows math with std_logic_vector
and there is no reason (other than it offends some) that you can not use
it with numeric_std.
If you feel too much pressure about using std_logic_unsigned, you can
always use type unsigned everywhere you originally used type
std_logic_vector.
While I prefer to use numeric_std and do the conversions, the use of
std_logic_unsigned does not offend me.
> But if I included
> ieee.numeric.std.all and ieee.std_logic_arith. ISE cannot recongize
> the '+' and 'shift'.
The types unsigned and signed in numeric_std and std_logic_arith are
distinct, eventhough, they have the same name. What should happen
if you include both is the names unsigned and signed should disappear
from direct selection and you must use their fully selected names:
ieee.numeric_std.unsigned. For an object of this type, it will only
use operators and subprograms from the numeric_std package.
Cheers,
Jim
SynthWorks VHDL Training
www.synthworks.com
Ben Jones
"Jonathan Bromley" <jonathan...@MYCOMPANY.com> wrote in message
> 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" ?
Hehe, I love it!
> 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.
Ah yes, the appeal to industry standards - just as convincing as an appeal
to authority, but much less falacious. :-)
Cheers,
-Ben-
Mike Treseler
> 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.
Jonathan has covered the main points.
Add spin as needed.
Add references if that would help the case.
This is a public forum.
-- Mike Treseler
Jonathan Bromley
Mike Treseler <mike_t...@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 :-)
Ben Jones
"Jonathan Bromley" <jonathan...@MYCOMPANY.com> wrote in message
> 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...@MYCOMPANY.com> wrote in message
> news:2pfg3355s1bnn1sal...@4ax.com...
>> 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
> 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.
Mike Treseler
> 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.
True, but I can't afford buying beer
for that as well :)
-- Mike Treseler