shift_right/ shift_left

[Mike Treseler]

Paul Uiterlinden wrote:

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

 

[Colin Paul Gloster]

In news:2rc733pfrsqng7jos9v6sc6n1geboqki6i@4ax.com timestamped Sat, 28
Apr 2007 21:55:24 +0100, Jonathan Bromley
<jonathan.bromley@MYCOMPANY.com> posted:
"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". [..]

[..]"


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.bromley@MYCOMPANY.com> wrote in message
news:2rc733pfrsqng7jos9v6sc6n1geboqki6i@4ax.com...

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 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]

On Tue, 1 May 2007 15:56:27 +0100,
"Ben Jones" <ben.jones@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.
--
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.

 

[Jim Lewis]

Gerhard,

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]

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]

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

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]

Ben Jones wrote:

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