numeric_std resize function

[Peter]

I was surprised by how the resize function works. My intention was to
substract two 32-bit signals (std_logic_vectors, but representing 2-
complement numbers) and decrease the signal width from 32 bits to 14.
The code below does not work:

daout <= std_logic_vector( resize((signed(tx_mix_i) - signed
(tx_mix_q)),14) );

But this code does:

idaout <= std_logic_vector( signed(tx_mix_i) - signed(tx_mix_q) );
daout <= idaout(31 downto 18);

I seems as the rezise function selects the 14 lowest bits in the
argument instead of the 14 highest.

Any comments?

/Peter

[Tricky]

As to exactly why, Im sure someone knows better, but thats exactly
what it says in the package in the comments/documentation (as the
comments are pretty much the only docs on the package afaik).

-- Id: R.1
function RESIZE (ARG: SIGNED; NEW_SIZE: NATURAL) return SIGNED;
attribute builtin_subprogram of
RESIZE[SIGNED, NATURAL return SIGNED]: function is
"numstd_resize_sns";
-- Result subtype: SIGNED(NEW_SIZE-1 downto 0)
-- Result: Resizes the SIGNED vector ARG to the specified size.
-- To create a larger vector, the new [leftmost] bit
positions
-- are filled with the sign bit (ARG'LEFT). When truncating,
-- the sign bit is retained along with the rightmost part.

This implies that if you declare your signed value as s(0 to n)
instead of downto, you will get the desired outcome (and looking at
the actual function, it uses the 'left attribute rather than 'high
when taking the return value).

[Peter]

>   --         are filled with the sign bit (ARG'LEFT). When truncating,
>   --         the sign bit is retained along with the rightmost part.
>
> This implies that if you declare your signed value as s(0 to n)
> instead of downto, you will get the desired outcome (and looking at
> the actual function, it uses the 'left attribute rather than 'high

> when taking the return value).-

I should have checked the most recent version of numeric_std. I had v
1.2 printed out, which is somewhat cryptic on whats coming out.

Thanks, Peter.

[Bert_Paris]

Peter a utilisￜ son clavier pour ￜcrire :

I'm not sure I understand your concern.
By principle & definition, "resize" does not change the number coded in
the vector. For example resize("000011",4) returns "0011", still the
same number +3.

"resize" is great because :
- at simulation, it checks that the truncation doesn't alter the number
(in the example aboven resize to two bits as signed vectors would get
you a warning because the result would be -1)
In the submitted case, it's a great feature !
- it does sign-extend when appropriate (up-sizing signed vectors).

Bert

[Andy]

On Apr 27, 5:30 am, Bert_Paris <do_not_s...@me.com> wrote:
> Peter a utilisé son clavier pour écrire :

> Bert- Hide quoted text -
>
> - Show quoted text -

I agree with Bert. The whole purpose of numeric_std is to apply
numeric interpretations to SLV-like vectors. Resizing a number should
not alter the numeric value, and resize() will issue a warning if it
does so.

As to the indexing order, numeric_std defines 'left as the numerically
MSB, not 'high. So with signed(0 to n), bit 0 is MSB, not LSB, and is
still treated as MSB by resize() and other numeric_std functions/
operators.

Andy

[Peter]

> I agree with Bert. The whole purpose of numeric_std is to apply
> numeric interpretations to SLV-like vectors. Resizing a number should
> not alter the numeric value, and resize() will issue a warning if it
> does so.
>

I believe you are right and that the resize function does what its
supposed to do.
I think I jumped to the wrong conclusion and that my problem has to do
with overflow and scaling of the data.

/Peter

[Rob Anderson]

The resize function is to change the number of bits without changing the value. If you want to select a field you can use a variable and select the (31 downto 18) bits.