shift_right/ shift_left

[Jim Lewis]

ZHIQUAN,

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.

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]

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]

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
(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.

 

[Ben Jones]

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]

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!

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.

 

[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