Extracting type - Not possible or would it be useful in a fu

[Tricky]

I have just come across a situation where it might be beneficial to
return the type of something so another type can be created.

For example: I have this type defined in a package.

type rec_t is record
num : ufixed(7 downto 0);
end record rec;

type rec_array_t is array(integer range <&gt of rec_t;

then in a design file I want to create an array. The purpose of this
array is simply to extract the "num" elements from a rec_array_t. At
the moment I have to define:

type local_array_t is array(integer range <&gt of
ufixed(rec_t.num'range);

the problem comes when the "num" element is changed from a ufixed to a
sfixed. I then have to manually redefine the local_array_t to cope
with the type change.

Am I overthinking a problem that might be worked around with a
function (and by-passing the need for a local_array_t) or would this
prove useful in the language?

 

[Andy]

Just shooting from the hip, but I suppose you already tried:

type local_array_t is array(integer range <&gt of rec_t.num;

One would think that 'base should be usable for this, but the spec
clearly says that the attribute is only usable as a prefix for another
attribute. Still seems like a reasonable enhancement request,
especially if the above does not work (not sure why they limited 'base
to use as a prefix in the first place).

As a work-around, if you defined a named subtype for use in the record
definition, and referenced that subtype in the local array definition,
that would solve your problem. Then you could change the base type of
the subtype definition, and both the record and the local array would
be updated.

Andy

 

[KJ]

On Sep 7, 4:42 am, Tricky <trickyh...@gmail.com> wrote:

I have just come across a situation where it might be beneficial to
return the type of something so another type can be created.

For example: I have this type defined in a package.

type rec_t is record
  num : ufixed(7 downto 0);
end record rec;

type rec_array_t is array(integer range <&gt of rec_t;

then in a design file I want to create an array. The purpose of this
array is simply to extract the "num" elements from a rec_array_t. At
the moment I have to define:

type local_array_t is array(integer range <&gt of
ufixed(rec_t.num'range);

the problem comes when the "num" element is changed from a ufixed to a
sfixed. I then have to manually redefine the local_array_t to cope
with the type change.

Well, that's just the start of it though. You would then also have to
change the type of any signals that are using the local array also.

Am I overthinking a problem that might be worked around with a
function (and by-passing the need for a local_array_t)

In this particular case, one might be able to say that your package
that defines the type should also have a function that returns an
array of particular elements since that apparently may be a generally
useful function to have when using your package. That would avoid
having to do some editing in the area that you mentioned, but as I
pointed out, you must have signals that want to use the local array so
those declarations would be affected as well, you'll still be editing
multiple places when you change a data type.

However, it's probably not difficult to imagine there could also be
much more 'nichy' functions that are useful in only very limited
areas. One could say that those 'nichy' functions probably should not
be cluttering up the package, but there really isn't a good argument
for 'Why not?'. What looks like 'clutter' to one person is
'consolidation' to somebody else. Why not have 'nichy' as well as
'generally useful' functions that work with a type in the same
package? In other words all functions that work with that type go in
the same package...one stop shopping. Over time that package grows to
pick up more 'generally useful' functions as well as 'nichy' functions
that might end up finding other niches to fill. If you think it looks
'cluttered', that is most likely a commentary on your editing skills
rather than the idea of packaging all functions together.

Of course, in the end, there will be functions that really want to
work with things of two different types and then the question about
which package to put those functions in will rear its head.

or would this
prove useful in the language?

Probably useful...but...

At some point as you start to parameterize your design to make it more
self-documenting you create the situation where it becomes difficult
to look at the code and answer a simple question like "What type is
signal xyz?" because the declaration becomes buried under mounds of
'self-documenting code' that refers to something here that refers to
something there...

Kevin Jennings

 

[Paul Colin Gloster]

Andy <jonesandy@comcast.net> sent on September 7th, 2010:

|---------------------------------------|
|"[..] |
| |
|[..] |
|[..] (not sure why they limited 'base |
|to use as a prefix in the first place).|
| |
|[..]" |
|---------------------------------------|

Not in the first place. 'Base can be liberally used in Ada.

Regards,
Paul Colin

 

[JimLewis]

As mentioned in the other posts, subtypes are probably the way to go
now.

VHDL-2008 adds a new attribute:
O'SUBTYPE
Kind: Subtype.
Prefix:
Any prefix O that is appropriate for an object, or an alias thereof.

Result:
The fully constrained subtype that is the subtype of O, together with
constraints defining any index ranges that are determined by
application
of the rules of 5.3.2.2. (If O is an alias for an object, then the
result is determined by the declaration of O, not that of the object.)