Basic question #4

[m]

signal AAA : std_logic_vector(4 downto 0);
signal BBB : std_logic_vector(9 downto 0);
....
BBB <= AAA(4 downto 2);

Does this assign AAA(4 downto 2) to the most significant three bits of
BBB?
Or the least significant three bits of BBB?
Or to BBB(4 downto 2)?

Thank you,

-Martin

 

[Thomas Stanka]

On 30 Sep., 08:13, m <martin.use...@gmail.com> wrote:

signal AAA : std_logic_vector(4 downto 0);
signal BBB : std_logic_vector(9 downto 0);
...
BBB <= AAA(4 downto 2);

Does this assign AAA(4 downto 2) to the most significant three bits of
BBB?
Or the least significant three bits of BBB?
Or to BBB(4 downto 2)?

This should not work properly and each good tool should complain.
I wonder what book you are using, the author must use other vhdl than
the language I'm using.

regards Thomas

 

[Tricky]

On 30 Sep, 07:13, m <martin.use...@gmail.com> wrote:

signal AAA : std_logic_vector(4 downto 0);
signal BBB : std_logic_vector(9 downto 0);
...
BBB <= AAA(4 downto 2);

Does this assign AAA(4 downto 2) to the most significant three bits of
BBB?
Or the least significant three bits of BBB?
Or to BBB(4 downto 2)?

Thank you,

-Martin

This wont synthesize, and it wont simulate, but it should compile
giving you a warning. In simulation you should get a fatal error (at
least I do in modelsim) saying the ranges dont match. Its quite easy
to miss when you start having different sized arrays based on generics
as warnings are not given, you can only catch them in simulation.

If this is in the legacy code you're looking at, does it work?

 

[John]

On 30 ÓĹÎÔ, 10:13, m <martin.use...@gmail.com> wrote:

signal AAA : std_logic_vector(4 downto 0);
signal BBB : std_logic_vector(9 downto 0);
...
BBB <= AAA(4 downto 2);

Does this assign AAA(4 downto 2) to the most significant three bits of
BBB?
Or the least significant three bits of BBB?
Or to BBB(4 downto 2)?

Thank you,

-Martin

Yes, this code can't work. But if you want do things like it, you can
use std_logic_arith.vhd library.
In this library defined EXT and SXT function. SXT function work with
signed numbers, EXT - unsigned.

 

[Tricky]

On 30 Sep, 11:25, John <isuva...@gmail.com> wrote:

On 30 ÓĹÎÔ, 10:13, m <martin.use...@gmail.com> wrote:

signal AAA : std_logic_vector(4 downto 0);
signal BBB : std_logic_vector(9 downto 0);
...
BBB <= AAA(4 downto 2);

Does this assign AAA(4 downto 2) to the most significant three bits of
BBB?
Or the least significant three bits of BBB?
Or to BBB(4 downto 2)?

Thank you,

-Martin

Yes, this code can't work. But if you want do things like it, you can
use std_logic_arith.vhd library.
In this library defined EXT and SXT function. SXT function work with
signed numbers, EXT - unsigned.

*Slaps forhead*

No. Use numeric.std instead. see some of the previous questions.

 

[Andy]

On Sep 30, 3:21 am, Tricky <Trickyh...@gmail.com> wrote:

Its quite easy
to miss when you start having different sized arrays based on generics
as warnings are not given, you can only catch them in simulation.

Depends on whether your simulator has a separate elaboration step that
is not lumped into the simulator. If it does, then you will get those
errors during elaboration.

Andy

 

[m]

This wont synthesize, and it wont simulate, but it should compile
giving you a warning. In simulation you should get a fatal error (at
least I do in modelsim) saying the ranges dont match. Its quite easy
to miss when you start having different sized arrays based on generics
as warnings are not given, you can only catch them in simulation.

If this is in the legacy code you're looking at, does it work?

This is out of production code. It compiled just fine. I didn't try
to write a testbench to see how it simulates. I am not posting the
actual code, of course. I can't do that. I'll review it again
tonight and see if I made a mistake somewhere. The indeces come from
generic declarations at the top of the module. In doing the math I
get the indeces as posted...which made no sense to me.

I'll combe back with a little more data later on.

Thanks,

-Martin

 

[Tricky]

On 30 Sep, 16:43, m <martin.use...@gmail.com> wrote:

This wont synthesize, and it wont simulate, but it should compile
giving you a warning. In simulation you should get a fatal error (at
least I do in modelsim) saying the ranges dont match. Its quite easy
to miss when you start having different sized arrays based on generics
as warnings are not given, you can only catch them in simulation.

If this is in the legacy code you're looking at, does it work?

This is out of production code.  It compiled just fine.  I didn't try
to write a testbench to see how it simulates.  I am not posting the
actual code, of course.  I can't do that.  I'll review it again
tonight and see if I made a mistake somewhere.  The indeces come from
generic declarations at the top of the module.  In doing the math I
get the indeces as posted...which made no sense to me.

I'll combe back with a little more data later on.

Thanks,

-Martin

That would be why it compiled. Until runtime the compiler has no idea
what the generics are going to be set to. So no warning can come up.
When you say you based your calculations on the generics at the top of
the module - do you actually mean the top of the source for the entity
(these would just be the default values if no value was set during
instantiation) or what the generics are set to when the entity is
instantiated?

 

[m]

Well, I wrote a quick little testbench to see what the story was with
this code and sure-enough, as I suspected and as others echoed here it
came down to a grinding halt and didn't run. Now I think somone
handed me code with problems either so I will fix them or to see if I
am awake! Well, what better way to learn VHDL than to find the dust
under the carpet.


Thanks,

-Martin

 

[Thomas Stanka]

On 30 Sep., 17:43, m <martin.use...@gmail.com> wrote:

This wont synthesize, and it wont simulate, but it should compile
giving you a warning. In simulation you should get a fatal error (at
least I do in modelsim) saying the ranges dont match. Its quite easy
to miss when you start having different sized arrays based on generics
as warnings are not given, you can only catch them in simulation.

If this is in the legacy code you're looking at, does it work?

This is out of production code. It compiled just fine. I didn't try
to write a testbench to see how it simulates. I am not posting the
actual code, of course. I can't do that. I'll review it again
tonight and see if I made a mistake somewhere. The indeces come from
generic declarations at the top of the module. In doing the math I
get the indeces as posted...which made no sense to me.

The story with Generics is not allways obvious. Maybe you just missed
to use the intended configuration (or instantiation) that sets the
Generics to reasonable values. It might be happen, that a module is
not working with default values seen in entity, but working with the
values used in the final design via configurations or instatiations. I
consider this as bad coding style, but you never know....
I'm just using an IP that seems to be used in a real lot of designs
around the world that has not fully constraint sensitivity lists for
combinatorial processes inside. A good synthesis tool throws a handful
of warnings and I really wonder if our company is the first to look at
warnings or just paid to less to get the correct release of the IP.

bye Thomas

 

[KJ]

On Oct 1, 1:18 am, m <martin.use...@gmail.com> wrote:

Well, I wrote a quick little testbench to see what the story was with
this code and sure-enough, as I suspected and as others echoed here it
came down to a grinding halt and didn't run.  

That's why the first question should always be "Does it simulate
correctly?"

Now I think somone
handed me code with problems either so I will fix them or to see if I
am awake!  

Or the person handing you the code doesn't believe in the value of
simulation...in this case it would be to their obvious detriment.

Good luck.

KJ