Re: [vhdl-200x] Fwd: P1076.1 standard packages

Chuck,

 

This is an idea, but unless I am missing something it seems to just shift the problem to the other package. The standard would have to define the name of the additional package and state that it shall include a declaration for a type xyz whose content is implementation defined. I am not sure what is gained compared to declaring type xyz directly in the original package. You mention strong typing, but I believe the same is accomplished with the original approach because an implementor would in fact have to provide a full definition of the type in his version of the package for the package to be analyzable. Portability across implementations, one of the important goals of a standard, is guaranteed as long as a design unit does not peek into an object of the type in both cases.

 

Ernst
 

On Tue, 8 May 2012 14:52:37 -0700, chuck and teril swart <chuckterilswart@gmail.com> wrote:

 

 I haven't given this a great deal of thought, but it occurs to me that
you might accomplish your goal if each implementation were required to
support
an additional package that contained descriptions of the relevant data
types. The interface to these data types would be standard, and
described in the
main  package. This approach would support strong typing while
allowing different implementations for different vendors.
Chuck Swart

On Tue, May 8, 2012 at 8:13 AM, Jim Lewis <Jim@synthworks.com> wrote:
> Hi All,
> Here is a forwarded question from the 1076.1 working group.
>
 > Best Regards,
> Jim
>
 > -------- Original Message --------
> Subject:        P1076.1 standard packages
> Date:   Tue, 8 May 2012 08:02:31 -0700
> From:   Ernst Christen <christen.1858@comcast.net>
> To:     Jim Lewis <Jim@SynthWorks.com>
>
 >
 >
 > Jim,
> I hope all is well. Unfortunately I don't have the bandwidth to attend the
> P1076 meetings, but being on the reflector keeps me at least informed. I had
> a change of affiliation recently after Lynguent
> went out of business, and I am with Mentor Graphics now working on their AMS
> products.
> You may remember that in P1076.1 we are in the process of developing two
> packages that you said could also be of interest to the P1076 standard:
> table-driven modeling and vector/matrix operations. In
> that context you mentioned that at some point the packages should be
> reviewed by ISAC. We are not quite that far along, but a question has come
> up that we want to resolve before moving further, except
> that AFAIK ISAC no longer exists. The issue is this.
> The TDM package is organized into two sets of subprograms. Routines in the
> first set, typically called during elaboration, read data from various file
> formats, while routines in the second set are run
> time functions to do the appropriate interpolation. The elab time functions
> do all consistency checks on the data, and they transform the data into an
> organization optimized for quick run time
> performance. The table data is then assigned to an object, typically a
> constant, that is passed as an actual to the runtime function. The issue now
> is that different implementations may have different
> ideas about how to optimize the run time performance, which will likely
> require different data layout. To address this issue we have been
> considering to declare just the name of the type in the
> standard, but not the data layout, similar to how it's done for
> universal_integer and universal_real: type XYZ is record
> implementation_defined end record; The result would be that the constant
> acts
> like a handle to the data without giving the model access to the data except
> through functions in the package.
> I wonder what the successor of ISAC would think about such an approach to
> define an opaque data type. Is there a better way to address this issue?
>
 > Regards.
> Ernst
> --
> Ernst Christen, christen.1858@comcast.net on 5/8/2012
>
 >
 > --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>