RE: EXTERNAL: Re: [vhdl-200x] Sizing of variables and signals from initial values

Jim:

> > I do exactly what you suggest: declare sizer constants, then use
their
> > 'subtype to declare the signals I want.  The whole point of my
original
> > question is that I don't see the need for this two-step process.
Let's
> > allow sizing of variables and signals from expressions, then it's
only a
> > one-step process.
> 
> I think we should also consider getting 'range to work on a return
value
> of an expression, so that the following would work:
>    entity e is
>    port (
>      B, C : in ufixed(7 downto -4) ;
>      . . .
>    ) ;
>    end entity E ;
>    architecture A of e is
>      signal A : ufixed( (B + C)'range ) ;
>    begin

That would be nice, too.

> It would have helped some of the resizing if 'range was a
> first class object and we could return a range from a function.

I've often wished I could pass around ranges.  I wonder if we could
consider a range as a subtype and pass it around as a type (generic).  I
don't think we can get scalar attributes (like 'low and 'high) from
current type generics because it might be a composite type.  Maybe we
need to refine type generics to "constrain" (perhaps "restrict" is a
better term) to an array or scalar type.  I know I've often intended an
incoming type to be an array type whose elements I want to iterate over.

> > It's not hard to define the mixed arithmetic (at least most of it).
I
> > have a few suggestions for numeric_std types at
> >
[http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/StandardPackages#numeric_st
> > d_Additions].  Jim pointed out that the mixed arithmetic for
> > signed/unsigned makes it hard to use literals in expressions (e.g. a
+
> > "1010") since the literal type is ambiguous.  I do it anyway because
I
> > don't use literals in that way -- or I qualify them if I do use
them.
> > (Personally, I think it's "evil" to *not* qualify signed/unsigned
> > literals.)
> 
> Yea, I am particular about a type having a literal
> that works with a type in simple expressions.
> 
> For mixing two types, you really should have a type qualifier
> designating the type change.   Isn't there a to_sfixed that
> takes care of the resizing of a ufixed object.

I agree that in most cases mixing types requires casting.  But signed
and unsigned aren't apples and oranges.  Instead, signed could be apples
and unsigned is restricted to crab apples.  In other words, unsigned is
a subset of signed.  In my mind, it's like the relationship between
integer and natural: natural is a subtype of integer with a restricted
range.  As such, mixed arithmetic is the norm.  I don't think it's
possible, but I would prefer unsigned to be a subtype of signed.  In
lieu of this, I like to have mixed-type operators.  

It sounds like there is enough variety of opinion that it probably
doesn't belong in the standard.  So I'll keep maintaining my own add-on
package so I can have my own preference.  And this is a perfectly
acceptable option.

Enjoy!

- Ryan


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.