Copying the type

[Thomas Reinemann]

Hi,

usually we have statements like this kind, to copy the value of a signal.

pgen_data : process (sclk) is
begin -- process pgen_data
if rising_edge(sclk) then -- rising clock edge

sfifo_alt <= sfifo_data_in;

end if;
end process pgen_data;


To do it right, we have to figure out the type of the right value and
copy it. During debugging this can be time consuming and can led to
errors. Just my wish, the possibility to copy the type of a signal via
a certain keyword perhaps "copy_type".

Bye Tom

 

[Symon]

Hi,

usually we have statements like this kind, to copy the value of a signal.

pgen_data : process (sclk) is
begin -- process pgen_data
if rising_edge(sclk) then -- rising clock edge

sfifo_alt <= sfifo_data_in;

end if;
end process pgen_data;


To do it right, we have to figure out the type of the right value and
copy it. During debugging this can be time consuming and can led to
errors. Just my wish, the possibility to copy the type of a signal via
a certain keyword perhaps "copy_type".

Bye Tom

Hi Tom,
I think that by forcing the coder to specifically define the type of all
signals and to make them match, VHDL is aiding, not hindering, the debugging
process.
YMMV, Syms.

 

[KJ]

Hi,

usually we have statements like this kind, to copy the value of a signal.

To do it right, we have to figure out the type of the right value and
copy it.  During debugging this can be time consuming and can led to
errors.

1. It's a 'good' thing that one needs to explicitly define the type of
all signals and variables...there's a lot of value to strong typing.

2. Actually you can't even start debugging (i.e. running the simulator
and testing for functional correctness) until you've found and fixed
all of the type mismatches. But darn near all of the time spent doing
this 'time consuming' step is fixing actual design errors that would
have to be caught during simulation if you had such a loosely typed
language. Bottom line is that it is always faster to fix design
errors that get flagged by a compiler then it would be to debug down
to the error yourself.

Kevin Jennings

 

[Andy]

VHDL doesn't (as far as I know) allow you to determine the type
of an object. However, it does let you determine the subtype
(vector range, etc) - as perhaps you already know:

entity bar;
generic (N: positive := 8);
port ( P: in std_logic_vector(N-1 downto 0);
Y: out integer range 1 to N );
end;
architecture foo of bar is
signal S: std_logic_vector(P'range);
signal I: integer range Y'range;
begin
S <= P; -- S definitely has the correct subtype
Y <= I; -- I definitely has the correct subtype
end;

What you are asking for is something much more like a
type generic (Ada) or template type (C++) and I'm sure
VHDL <=2002 lacks such things - although there have been
some interesting developments in the VHDL-200x proposals;
someone else may be able to expand on that.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
(e-mail address removed)://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

I'm not sure Y'range will work. The 'range attribute is limited to
constrained arrays or aliases or types thereof. You can determine the
bounds of a type or subtype using 'high and 'low, for example, but not
of a scalar object or port. In other words, if Y was of type my_int,
you could use "range my_int'low to my_int'high", but if Y was defined
as my_int, you could not use Y'low or Y'high.

Otherwise Jonathan's example is very good. If a local signal/variable
vector must be the same or related length as a port, it should be
coded as such. That way you are reminding the reader (which may be you
in a few weeks/months/years) that this object needs to have a certain
relation to that port. If you just use the same explicit range,
without using an attribute, the reader does not know whether it is
merely a coincidence, or it has to be the same range.

Taken a step further, this technique allows using unconstrained ports,
which become constrained when they are bound to signals in the
instantiation port map. The architecture must use these attributes to
determine the actual vector index range for that instantiation.

Andy