Re: [vhdl-200x] Proposal for improved physical types

On 14/01/2015, at 9:22 am, <ryan.w.hinton@L-3com.com> <ryan.w.hinton@L-3com.com> wrote:

>    CLOCK_RATE => 100 MHz,
>  
> instead of seeing
>  
>   CLOCK_RATE => 100,  -- MHz? or kHz? or ns?!


Nitpicking aside that rate implies time (interval) and not frequency...

You could note that synthesis generally precludes uses of physical types that are not at least globally static. Historically as in XST physical literals are ignored. There is generally no way to synthesize time.

Note values of a physical type that can fit in a target implementation defined integer range from an implementation defined physical type range type conversion can be used produce an integer that is useable by synthesis tools.

In any case you appear to be up against implementation limits noting that it would be possible to convert a 2**63 sized physical type to a bit oriented element array type for synthesizing things with a greater than positive range specified by the minimum.

As Tristan notes the implementation defined range limit of physical types is defined as a minimum in the -1987 or later standard for type TIME,leaving the limit open to being increased. It seems universal to implement the predefined physical type TIME with a greater range, seemingly implying type universal_integer be greater too.

The range is implementation limited (see 5.2.4.1 paragraphs 4 and 5, a physical type is an anonymous type, the range selected by implementation, each bound of a range constraint is a locally static expression of some integer type).

I'd modify Kevin's original post statement

> The current implementation of user defined physical types in VHDL is tied to the implementation of integer which is a problem with most tools only supporting 32-bit integers. ..

And point out that the implementation  of user defined physical types is only generally tied to 'some integer type', 5.2.4.1 paragraph 5 "Each bound of a range constraint that is used in a physical type definition shall be a locally static expression of some integer type, but the two bounds need not have the same integer type. (Negative bounds are allowed)", which implies at least universal_integer which is tied to a commonly expanded range of type TIME.

That tie is demonstrated by the predefined multiply operators "/","mod" and "rem" as well as predefined  attributes 'POS, 'VAL implying a physical type range constraint should fit in type universal_integer which is derived from CONLAN's univ@.

There is also a requirement for detecting constraint errors in the target of a type conversion, see 9.3.6 Type conversions, paragraph 8 "In the case of conversions between numeric types, it is an error if the result of the conversion fails to satisfy a constraint imposed by the type mark". The type mark being the target type. This is the only place you can imply the range constraint of universal_integer has a relationship with type INTEGER and if their range constraints are different some conversions will generate errors.

So all the limits you are encountering are implementation dependent and the physical types you wish to define are not otherwise precluded in the VHDL standard. And Tristan with the range constraint allowing  universal_integer'HIGH (2**63 - 1) as an upper range
demonstrates this with ghdl, allowing user defined physical types with a range greater than +/- 2*31.

And all that leaves open user defined integer types with wider ranges than predefined type INTEGER, too.  And a quick check shows ghdl does that too, although I haven't tested all the predefined operators.

All roads lead to vendor implementation defined limits, in this case type universal_integer, independent of type INTEGER range constraints support by any synthesis vendors.

I seem to recall talk of a proposal to create a new INTEGER type with a larger range?


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