Re: std_logic_vector vs unsigned

Hi Martin,
In the past, I've kept the entity ports as slv, just using unsigned etc.
within the architecture. Partly because of reuse, easier for others to
understand on a multiple person team, etc. Now that numeric.std has been
standardised, I wonder if there's a reason to do this anymore?
cheers, Syms.

"Martin Thompson" <> wrote in message
news:...
> Why not define these as "unsigned(31 downto 0)"? You're representing
> real numbers after all, not just large collections of bits (which is
> all a std_logic_vector implies).
>

Symon

Symon wrote:
> In the past, I've kept the entity ports as slv, just using unsigned etc.
> within the architecture. Partly because of reuse, easier for others to
> understand on a multiple person team, etc. Now that numeric.std has been
> standardised, I wonder if there's a reason to do this anymore?

If you have unsigned as primary IOs on your FPGA, xilinx tools will
replace them with slv on the gate level model and break your testbench.
-JCC

Jeff Cunningham

"Jeff Cunningham" <> wrote in message
news:hPeqc.2181$...
> Symon wrote:
> > In the past, I've kept the entity ports as slv, just using unsigned etc.
> > within the architecture. Partly because of reuse, easier for others to
> > understand on a multiple person team, etc. Now that numeric.std has been
> > standardised, I wonder if there's a reason to do this anymore?
>
> If you have unsigned as primary IOs on your FPGA, xilinx tools will
> replace them with slv on the gate level model and break your testbench.

This was part of my problem, one of the slv's was part of the input
specification to the pwm unit (8 bits of 'current count' data), comparing an
SLV to an unsigned gives an error message (something about 6 possible ways
to interpret the result), even unsigned(slv) gives that error, but
unsigned/unsigned compares work as do slv/slv compares. I was just curious
if the slv/slv compare was done by default as signed or unsigned.

--Chuck

Chuck McManis

"Chuck McManis" <> writes:

> "Jeff Cunningham" <> wrote in message
> news:hPeqc.2181$...
> > Symon wrote:
> > > In the past, I've kept the entity ports as slv, just using unsigned etc.
> > > within the architecture. Partly because of reuse, easier for others to
> > > understand on a multiple person team, etc. Now that numeric.std has been
> > > standardised, I wonder if there's a reason to do this anymore?
> >
> > If you have unsigned as primary IOs on your FPGA, xilinx tools will
> > replace them with slv on the gate level model and break your testbench.
>

Yes - I tend to keep unsigned's for within module use, although I do use
them on certain entity's that won't go to the outside.

> This was part of my problem, one of the slv's was part of the input
> specification to the pwm unit (8 bits of 'current count' data), comparing an
> SLV to an unsigned gives an error message (something about 6 possible ways
> to interpret the result), even unsigned(slv) gives that error, but
> unsigned/unsigned compares work as do slv/slv compares. I was just curious
> if the slv/slv compare was done by default as signed or unsigned.
>

If you're using the synopsys std_logic_[un]signed or arith libraries
then it will get done however those libraries happen to do it - which
I've never been clear on, as I stick to numeric_std! If you're using
numeric_std, then I don't think slv/slv compares should work.

Cheers,
Martin

--

TRW Conekt, Solihull, UK
http://www.trw.com/conekt

Martin Thompson

Chuck McManis wrote:


> This was part of my problem, one of the slv's was part of the input
> specification to the pwm unit (8 bits of 'current count' data), comparing an
> SLV to an unsigned gives an error message (something about 6 possible ways
> to interpret the result), even unsigned(slv) gives that error, but
> unsigned/unsigned compares work as do slv/slv compares.

use IEEE.numeric_std.all;


if ((unsigned)some_slv = some_unsigned_vector) then
...


Just convert both vectors to the same type. It cost you a little time
for typing, but a well-defined behavior for unsigned / signed data.


Ralf

Ralf Hildebrandt