Re: [vhdl-200x] VHDL-2008: Records and aggregates

From: Daniel Kho <daniel.kho@gmail.com>
Date: Tue Apr 14 2015 - 09:01:37 PDT
Yes, I've been hoping for something like this for some time now.

On 14 April 2015 at 21:45, Degroat, Joanne <degroat.1@osu.edu> wrote:

>  This is a neat idea and is consistent with the philosophy of the
> language.
>
>
>
> *From:* owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] *On
> Behalf Of *Lehmann, Patrick
> *Sent:* Monday, April 13, 2015 6:06 PM
> *To:* vhdl-200x@eda.org
> *Subject:* RE: [vhdl-200x] VHDL-2008: Records and aggregates
>
>
>
> I think it would be nice to have a type RANGE that defines some operations
> like add/sub/div/mult of length or shift of boundaries.
>
>
>
> Example definition:
>
> type myRange is RANGE 7 downto 0;
>
>
>
> This range can then be used in slices.
>
> signal mySignal1 : std_logic_vector(myRange); -- 7..0
>
> signal mySignal2 : std_logic_vector(myRange + 8); -- 15..8
>
> signal mySignal3 : std_logic_vector(myRange * 4); -- 31..0
>
>
>
Yes. I'd also like to specify the range of mySignal2 based on the length of
mySignal1. Something like:
    signal mySignal2: std_logic_vector(myRange + mySignal1'length);

I believe, with your definition of '+', the boundaries will move up based
on mySignal1's length, which would fit the intention nicely.


>  Examples for difficult definitions:
>
> a)
>
> signal mySignal3 : std_logic_vector(myRange * 4); -- 31..0
>
> We expect a range of 4 bytes to be 31..0 but strict arithmetic would say
> 28..0
>
>
>
We can perhaps define "*" as having the resultant range of the length of
the range multiplied by the multiplier:
    mySignal3'high = size of myRange * multiplier + lowest boundary of
myRange - 1
                           = 8 * 4 + 0 - 1 (for this case)
    mySignal3'low = lowest boundary of myRange
                         = 0 (for this case)


> b)
>
> What is range3 := range1 + range2?
>
> Ok length3 equals lenth1 + length2, but what about range3'low and 'high?
>
>
>
Should we allow null ranges in between or not? Say we have the following
ranges:
    type range1 is range 6 downto -1;
    type range2 is range 11 downto 9;

so, range3 intuitively would mean the concatenation of range1 and range2,
so I think range3 should be implicitly defined as:
    type range3 is range (11 downto 9, 6 downto -1);

Say we have:
    signal s: unsigned(range3);

so perhaps we can have the following aggregate:
    s <= (11 downto 9 => '1', 6 downto -1 => '0');
and allow all sub-slices that are within these ranges, otherwise it would
be an error.

s(8 downto 7) should be a null range.

As usual, any overlapping assignments would result in an error. So it would
be an error if we had:
    type range1 is range 7 downto 0;
    type range2 is range 3 downto -1;
and
    range3 := range1 + range2;    -- overlapping range 3 downto 0, error.



>   c)
>
> How to handle zero-length ranges (and negative ranges)?
>

I feel we got ourselves pretty much covered on negative ranges, or maybe I
may still be missing something?
Perhaps it's also time for us to interpret zero-length ranges the same way
as accessing a single index of an array? E.g. s(8 downto 8) is the same as
s(8)?

Regarding operations on null ranges, the result of a range assignment
should also be a null range IMO:
    type range1 is range 2 downto 3;
    type range2 is range 6 downto 0;

    range3 := range1 + range2;    -- should be null range?


-daniel

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue Apr 14 09:03:35 2015

This archive was generated by hypermail 2.1.8 : Tue Apr 14 2015 - 09:03:55 PDT