Resizing a VHDL std_logic_vector

[shaiko]

Function "resize" works on types "signed" and "unsigned".
Is there a standard VHDL function that does the same on std_logic_vector?

 

[axcdd]

you can cast std to unsigned and use resize, or just use '&' aggregate

 

[shaiko]

you can cast std to unsigned and use resize, or just use '&' aggregate

Sure I can - this is what I do now.
I was asking about a function that does the same...

 

[TrickyDicky]

Function "resize" works on types "signed" and "unsigned".
Is there a standard VHDL function that does the same on std_logic_vector?

No there isnt, because resizing a std_logic_vector wouldnt make much sense. More logical to slice it or just append/prepend a load of '0's

Of course you can write your own resize function.

 

[ads-ee]

No there isnt, because resizing a std_logic_vector wouldnt make much sense. More logical to slice it or just append/prepend a load of '0's

Of course you can write your own resize function.

I can actually see shaiko's reasoning behind a resize function. Suppose you have a design that uses generics for the widths of your bus.

Now if you do the following how do you make it work with the N bit wide generic width?

---

Code VHDL - [expand]
1
2
3
4
5
6
7
sig1 : std_logic_vector(11 downto 0);
sigN : std_logic_vector(N-1 downto 0);
sig1assign : std_logic_vector(15 downto 0);
sigNassign : std_logic_vector(15 downto 0);
 
sigAassign = "0000" & sig1;
sigNassign = ???? & signN; -- how do you define the 16-N width of the ???? vector?

---

So how are you supposed to deal with the variable width signN vector? I'm not sure how you define the ????. I suppose I could look in the numeric_std package, but as I don't use VHDL much and am too lazy to find the package. ;-)

 

[shaiko]

I can actually see shaiko's reasoning behind a resize function.

You're example is very similar to the piece of code that made me post this question...

 

[Tetik]

You can use the attribute length of the signal

sigNassign <= resize(unsigned(sigN), sigNassign'length);

It should always work.

 

[ads-ee]

But conversion from std_logic_vector to unsigned requires another conversion back to std_logic_vector to assign it to sigNassign. That is not what shaiko or I want.

e.g in Verilog, the better language (said while wearing my NoMex suit ;-)) I would simply do the following:

---

Code Verilog - [expand]
1
2
3
4
5
parameter N = 12;
wire [N-1:0] sigN;
wire [15:0] sigNassign;
// appends the correct number of 0's to the beginning of sigN to make the assignment to sigNassign exactly 16-bits.
assign sigNassign = {{16-N{1'b0}}, sigN};

---

I'd like to see an equivalently simple way to do this in VHDL. Not some unreadable ugly type translation code.

 

[Tetik]

I agree with you ads-ee. It's ugly this type conversion mechanism. I checked a couple years ago to avoid this but I found nothing. It is true that VHDL is a strong type language.

 

[TrickyDicky]

You can use the attribute length of the signal

sigNassign <= resize(unsigned(sigN), sigNassign'length);

It should always work.

No it wont, because there is no standard resize function to work with std_logic_vector.

---

Code VHDL - [expand]
1
2
3
4
5
6
7
sig1 : std_logic_vector(11 downto 0);
sigN : std_logic_vector(N-1 downto 0);
sig1assign : std_logic_vector(15 downto 0);
sigNassign : std_logic_vector(15 downto 0);
 
sigAassign = "0000" & sig1;
sigNassign = ???? & signN; -- how do you define the 16-N width of the ???? vector?

---

So how are you supposed to deal with the variable width signN vector? I'm not sure how you define the ????. I suppose I could look in the numeric_std package, but as I don't use VHDL much and am too lazy to find the package. ;-)

This is going to all depend on several things, like whether N is always less than 16, or always bigger than 16, or possibly both. And also where is it assigned - in a process or outside a process?

If its assigned inside a process, its quite easy just to write:

sigNassign <= (others => '0')
sigNassign(sigN'range) <= sigN; --assuming N < 16

or outside a process:
sigNassign(sigNassign'high downto N) <= (others => '0');
sigNassign(N-1 downto 0) <= sigN;

for N > 16

sigNassign <= sigN(sigNassign'range) --or slice as appropriate

If N could be greater or smaller than 16, then theres probably some design fault here somewhere.

 

[ads-ee]

or outside a process:
sigNassign(sigNassign'high downto N) <= (others => '0');
sigNassign(N-1 downto 0) <= sigN;

This is the type of assignment I was thinking of (I think it might be the same for shaiko). Basically there isn't a more "elegant" way to do it using a single line? Now that I see this, I remember doing exactly this when I used to use VHDL regularly (It always seemed a bit hokey).

I suppose a function could be created that does this as a oneliner (and check for out of bound conditions)?

On a side note, it always bugged me how it seems like you have to create your own RTL language by creating a plethora of functions to get VHDL to look at least somewhat readable. I recall one design that had all the IO wrapped inside some functions that had all these cryptic cell names to signify all of it's attributes. To me that doesn't make things more readable.

IMO readability isn't for your benefit (the engineer who writes the code), but is for when you get fired/quit/layoff and the next schmuck has to take over. I've been that schmuck before trying to understand some cryptically written VHDL that was written I believe for job security by obfuscation (they must have been an idiot).

 

[TrickyDicky]

On a side note, it always bugged me how it seems like you have to create your own RTL language by creating a plethora of functions to get VHDL to look at least somewhat readable. I recall one design that had all the IO wrapped inside some functions that had all these cryptic cell names to signify all of it's attributes. To me that doesn't make things more readable.

IMO readability isn't for your benefit (the engineer who writes the code), but is for when you get fired/quit/layoff and the next schmuck has to take over. I've been that schmuck before trying to understand some cryptically written VHDL that was written I believe for job security by obfuscation (they must have been an idiot).

You could make the opposite arguments against Verilog. It contains many things that are just implied, and unless you understand the implications, you're going to see odd errors (truncation etc).

VHDL = Language knows best
Verilog = designer knows best.
SV = consistently inconsistent!

As with everything, badly written code in any language is still badly written code.

 

[mrflibble]

I like your SV interpretation. :grin: And unfortunately there's some truth to it. SV is a whole lot better than Verilog, but still has some curious stupidity in it that has a "design by commitee" smell to it. Still, of those three SV is the closest to usable IMO. But that is of course subject to personal taste.

 

[TrickyDicky]

I like your SV interpretation. :grin: And unfortunately there's some truth to it. SV is a whole lot better than Verilog, but still has some curious stupidity in it that has a "design by commitee" smell to it. Still, of those three SV is the closest to usable IMO. But that is of course subject to personal taste.

Its not my interpretation, I stole the line.
Its not design by comittee. It's design by gaffer taping several languages together (Verilog, SVA, Open Vera, Java).
Someone I work with wonders why they didnt just take the VHDL approach and just say the other languages are part of the standard instead of crowbaring them into the Verilog syntax. (PSL is included in the VHDL2008 Standard, unmodified)

Anyway, I learned that it does things natively that Ive have spent weeks developing in VHDL (queues, dynamic arrays etc) and it is now the defacto language for verification (using UVM).

Where I work all dev work is in VHDL, and we have some very complicated and well designed constrained random VHDL testbenches, but the verification is all moving to SV now.