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

I've added a new proposal for better physical types
<http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/PhysicalTypeRange> to the wiki
that is largely the same as my original email. I've added an alternative
implementation option that leverages existing syntax as others have pointed
out here but still would add an explicit requirement that it must be
possible to create user-defined physical types of equal range to time. I
want to stress that this is not intended as a way to get a backdoor
implementation of 64-bit integers. It is strictly focused on making
user-defined physical types have the same expressiveness as time.
Implementers would still be able to use the minimum-sized 32-bit range for
the integer type.

I've also added an practical example using a frequency type to derive a
synthesizable constant with numeric computation that is copied below:

The following is a snippet of real code used to implement an I2C
<http://www.eda-twiki.org/cgi-bin/edit.cgi/P1076/I2C?topicparent=P1076.PhysicalTypeRange;nowysiwyg=0>
slave. The I2C standard supports a range of clock frequencies and different
setup times on the SDA line apply depending on the speed. This example
permits the specification of the system clock frequency and the I2C bus
frequency in their natural units where they can be easily verified by
inspection. The internal clock cycle calculation uses various conversion
functions to transform from the *frequency* typed generics to a
synthesizable integer used to load a delay counter.

  generic (
    SYS_FREQ : frequency := 10 MHz;  -- Main system clock frequency
    I2C_FREQ : frequency := 100 kHz; -- Used to calculate SDA setup time

...

    -- When clock stretching we have to ensure the clock is released
after meeting the
    -- min setup time on SDA.
    -- Min SDA setup times from I2C standard:
    -- Standard  (100 kHz):   250 ns
    -- Fast      (400 kHz):   100 ns
    -- Fast-Plus   (1 MHz):    50 ns

    -- Power regression on this data results in the approximation:
    -- min setup ~= 0.0007646 * (I2C clock period) ** 0.695899

    constant MIN_SDA_SETUP_CYCLES : natural :=
to_clock_cycles(0.0007646 * to_real(to_period(I2C_FREQ)) ** 0.695899,
SYS_FREQ);

 The typical values for the frequency generics in this case will fit within
a 32-bit implementation but it serves to demonstrate that user-defined
physical types are more than just an odd curiosity of the language and have
real practical application.


--
Kevin Thibedeau

On Tue, Jan 13, 2015 at 6:39 PM, David Koontz <diogratia@gmail.com> wrote:

>
> 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* <http://www.mailscanner.info/>, and is
> believed to be clean.
>

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