Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Extracting type - Not possible or would it be useful in a future standard?

Reply
Thread Tools

Extracting type - Not possible or would it be useful in a future standard?

 
 
Tricky
Guest
Posts: n/a
 
      09-07-2010
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 <>) 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 <>) 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?
 
Reply With Quote
 
 
 
 
Andy
Guest
Posts: n/a
 
      09-07-2010
Just shooting from the hip, but I suppose you already tried:

type local_array_t is array(integer range <>) 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
 
Reply With Quote
 
 
 
 
KJ
Guest
Posts: n/a
 
      09-08-2010
On Sep 7, 4:42*am, Tricky <(E-Mail Removed)> 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 <>) 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 <>) 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
 
Reply With Quote
 
Paul Colin Gloster
Guest
Posts: n/a
 
      09-15-2010
Andy <(E-Mail Removed)> 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
 
Reply With Quote
 
JimLewis
Guest
Posts: n/a
 
      09-21-2010
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.)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Extracting functions from C/C++ using Perl, would like Code Review Help if possible sln@netherlands.com Perl Misc 1 02-07-2009 06:36 PM
useful setting in device manager (may be useful to know!) jameshanley39@yahoo.co.uk Computer Information 2 07-07-2008 04:28 PM
Having trouble extracting useful directory details from ftplib.FTP Stephen Horne Python 2 02-22-2004 06:19 AM
A 1D Mark-II would have been useful here Andrew Digital Photography 7 02-04-2004 04:52 AM
Re: useful for your future and so just see it Jimchip Computer Support 0 08-12-2003 09:17 PM



Advertisments