stumped on syntax yet again!

[Mike Treseler]

The function, as written, will return x*(2**sh)
up to the natural range. It knows nothing about
any other range unless you add a parameter
to to function.

I would use numeric_std.unsigned and the shift_left
function, and to_integer(my_uns, my_len) as needed.

function, and to_integer(my_uns) as needed.

 

[Nicolas Matringe]

Mike Treseler a écrit :

Declare it as a constant to give it a type.

That's good practice in any case.
I often declare zero constants for this:

RAM_addr <= my_adr_zero_c + data_in;

Declaring zero constants means declaring a constant for every possible
length (well, not actually every but still quite a lot)
I once had the idea of declaring a function for that (and I think it
worked quite well) :
function zero (n : natural) return std_logic_vector is
constant C_ZERO : std_logic_vector(n-1 downto 0) := (others => '0');
begin
return C_ZERO;
end function zero;

Nicolas

 

[Rob Dekker]

Shannon wrote: ...

Unfortunately I agree with James' and Rob's analysis.
I don't like it, but there must be some reason for the
restriction.

Jim

Hi Jim,

The restriction you talk about is probably the LRM 7.3.5 rule : "The type of the operand of a type conversion must be determinable
independent of the context (in
particular, independent of the target type)."

Why is this in there ?
I'm not entirely sure, but it does make sense from a wider point of view. Here is the type conversion in simplified syntax :

target_type( expression )

'expression' is 'cast' to type 'target_type'.
That means that 'target_type' is not the same as the expression type.
So how do we know which type 'expression' can or should be ? We don't !
That's why they put the rule in there that the type of the expression should be determinible without context info.

Later in 7.3.5, it is stated that the type conversion is only allowed if the target type is at least 'closely related' to the
expression type. 'closely related' is then defined as a certain dependency between expression type and target type. Other type
conversions are not allowed (except for some 'universal' implicit type conversions).
So it seems that they could have made the type-inference rule dependent on the 'closely related' semantics of the construct. Maybe
something like this :

"The type of the operand of a type conversion must be determinable independent of the context, but taken into consideration that the
type of the expression and the target type must be closely related."

This sentence is not entirely correct yet, since implicit (universal) type conversions would need to be included, but it would allow
for overloading to determine the expression type based on the target type in some form. This could be a headache for compiler
builders, since VHDL hardly ever has special-purpose type-conditions like this, and remember this was written before 1987, when
compiler technology was not yet so sophisticated as it is today. So I think that by making the type conversion rule simple, it would
be easier to bring out a full VHDL parser, and that's why the rules are a bit easier on the compiler.

Any way, that's my 2 cts on this issue.

Rob Dekker
Verific