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

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.