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

Discussion in 'VHDL' started by Tricky, Sep 7, 2010.

  1. Tricky

    Tricky Guest

    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?
     
    Tricky, Sep 7, 2010
    #1
    1. Advertising

  2. Tricky

    Andy Guest

    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
     
    Andy, Sep 7, 2010
    #2
    1. Advertising

  3. Tricky

    KJ Guest

    On Sep 7, 4:42 am, Tricky <> 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
     
    KJ, Sep 8, 2010
    #3
  4. Re: Extracting type - Not possible or would it be useful in a futurestandard?

    Andy <> 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
     
    Paul Colin Gloster, Sep 15, 2010
    #4
  5. Tricky

    JimLewis Guest

    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.)
     
    JimLewis, Sep 21, 2010
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Thomas Heller

    crossplatform py2exe - would it be useful?

    Thomas Heller, Aug 6, 2003, in forum: Python
    Replies:
    21
    Views:
    823
    Marc Wilson
    Aug 10, 2003
  2. Stephen Horne
    Replies:
    2
    Views:
    404
    Stephen Horne
    Feb 22, 2004
  3. Fao, Sean

    Would a PermissionProvider Be Useful?

    Fao, Sean, Aug 23, 2007, in forum: ASP .Net
    Replies:
    0
    Views:
    413
    Fao, Sean
    Aug 23, 2007
  4. Juha Nieminen

    Why export templates would be useful

    Juha Nieminen, Mar 29, 2010, in forum: C++
    Replies:
    33
    Views:
    1,017
    David Vandevoorde
    Apr 13, 2010
  5. Replies:
    1
    Views:
    162
Loading...

Share This Page