Table Model Proposal

Here is a revised proposal that myself and Patrick worked out last week.
I hope we can discuss this today at the LRM meeting.
Thanks,
--Martin, Patrick

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Table Model 2.3 Proposal, Jan. 2005.
------------------------------------

Patrick O'Halloran, Tiburon-DA.
Martin O'Leary, Cadence.

The data based modeling feature in LRM 2.2 needs to be extended and
documented further.

The main goals/issues are,
  - Support a well defined input data format with the aim being
    that vendors are obliged to support this format, but may
    also support any number of vendor specific formats.
  - Allow the input data to be on a set of isolines or
    scattered.
  - Allow more than one dependent variable in the data file and
    allow the user to specify which dependent should be
    interpolated.
  - Allow a 'closest lookup' rather than an interpolation
    in any given dimension.
  - Allow interpolation on a log scale in addition to a linear
    scale.
  - Allow units to be associated with the data.
  - Support the concept of "sections" in the datafile.
  
Table model controls are logically broken into two categories,

 1. Those which are associated with the data itself, or with
    defining the source of that data.
 2. Those which control the interpolation of the data.

This prompts our main design modifications,

 1. Storage of meta-data in the input file.
 2. Breaking the operation into two functions. One which
    builds a data table and one which interpolates it.

Meta-data (for example "data units" (k,m,u,...)), should be stored in
the data file. In addition, structural information associated with the
data also needs to be stored in the file. For example, if the data is
sampled on a set of isolines or if the sampling is scattered, then that
should be apparent from looking at the file, either through the
structure of the data in the file or through meta-data in the file.

Instead of inventing a format, it seems most reasonable to say - we have
data with some multidimensional structure and some associated meta-data,
then let's describe that in XML format. Let's make use of XML syntax and
potentially XML tools, rather than inventing a Verilog-A specific file
format.

While we have had some thoughts on how this file might be structured we
need to spend more time defining exactly what that structure might be. A
simple example might look like this:

<dataset>
    <name>S-parameters</name>
    <isoline>
        <indep>
            <name>freq</name>
            <units>Hz</units>
            <scale>linear</scale>
            <data>
                1.0, 2.0, 3.0, 4.0, 5.0
            </data>
        </indep>
        <depend>
            <name>S11</name>
            <data>
                0.1, 0.2, 0.3, 0.4, 0.5
            </data>
        </depend>
     </isoline>
     .......
</dataset>

The above shows:

  - That the structure of the data is clear. The main advantage
    being we may easily define how scattered data and data
    on isolines are specified. There is no issue wrt data
    tolerances, data order, etc. Also, we can add new sampling
    schemes such as "uniform sampling" and this information can
    be clearly and efficiently described in the file via an
    appropriate tag.
  - How information such as units, scale, etc, are attached to a
    particular variable.

Some advantages of using XML as the base format are:

   - XML is well documented
   - lots of people understand it
   - it's a simple text file
   - open source readers/writers are available
   - the actual layout can be rigidly defined in the LRM by a
     DTD/Schema.

Disadvantages:
 
   - overkill for what we need? A lot of work to design the
     format and implement the design.
   - XML readers are probably not tuned for large datasets
   - XML is not a commonly used format in CAE

Since the structure is clear and since the interpolation algorithm can
depend on that structure, any ambiguity introduced by allowing vendor
specified file formats is reduced. Vendors can document how their format
maps to the LRM definition of multidimensional data and the user can be
confident that the result they obtain is not dependent of the file
format used.

The existing "flat file" format and array format should continue to be supported, though probably not extended. The LRM will to define how these formats map to the LRM-XML format.

Now that a data format is clearly defined we can talk about the second
component of the design. That is, optionally breaking the 2.2
$table_model() into two functions. One function to build a data table,
and another to do the interpolation.

We introduce a new function to build a data table,

  hdl = $build_table("filename" {, "format" {,"attr", val}* })

The new function takes a filename and a format. There is one format
string defined in the standard, called "std" (or any other name we
prefer). This is the XML based format described above, and it is the
default if no format string is specified. If the vendor decides to
support multiple formats their particular format string may have
multiple values, for example "touchstone", "citifile", etc.

The remaining arguments (the third and beyond) are format dependent.
An example of this may be "section" specification for the "std" format.
For example, we have several corners in the data file, perhaps in a file
called corners.dat as:

  <dataset>
      <section>
          <name>FastFast</name>
          .....
      </section>
      <section>
          <name>FastSlow</name>
          .....
      </section>
  </dataset>

Then the $build_table function call might look like,

  hdl = $build_table("corners.dat",,"section", "FastFast")

This pulls a "FastFast" section from the file, and will later be passed
to $table_model() for interpolation.

[Aside: We only discuss building a data table from a file here, we omit
building from a Verilog-A array set.]

Now we have a "handle" for a data table. The only use of the handle is
as the "data source" argument to the $table_model() function. The
$table_model() function remains largely unchanged with the addition of a
simple dependent selector argument:

 $table_model(indep1 {,indep2}*,
              dataSource {, interpCntl {, depname|depIndex}} )

The strange existing argument sequence remains, with the dependent
selector appended to the end, and the "dataSource" now being one of:

  - a filename
  - an array set
  - a table data handle

The example on page 235 of LRM 2.2 may still be used as it, or it may be
written as:

    module measured_resistance(a,b);
    electrical a, b;
    int hdl;
    analog begin
        hdl = $build_table("example.tbl");
        I(a,b) <+ $table_model(V(a), V(b), hdl, "L,L");
    end
    endmodule
        
The data file on page 234 is actually arranged on isolines, so to
complete the example we should re-format it here. However the structure
is still in flux so we'll defer that for the moment.

The dependent selector may be a name or index. It is always required
when there is more than one dependent in the file. It is optional when
there is only a single dependent present.

With this design we can,

 1. Add all the table model features requested.
 2. Continue to provide a simple use model which is compatible
    with the existing definition.

If there is agreement on these design modifications, and next step is to
investigate exactly the file layout we might use.

Notes.
------

Example of possible multidimensional data file in XML format.
-------------------------------------------------------------

1. Define a variable, in this case drain current (Id):

  <variable>
        <name>Id</name>
         <isoline>
                <isoline>
                        0.01, 0.05, 0.10, 0.10, 0.10
                </isoline>
                <isoline>
                        0.02, 0.07, 0.15, 0.15, 0.15
                </isoline>
        <isoline>
  </variable>

The above might be typically a dependent, but in this scheme it could
also be an independent, but let's just define two independents, Vgs, and
Vds to keep the example simple. Id is 2-D with 2 points on the outer
dimension and 5 points on the inner, so we might have two more
variables, Vgs and Vds,

Vgs, a 1-D outer independent:

  <variable>
        <name>Vgs</name>
        <isoline>
                0.6, 0.7
        </isoline>
  </variable>

And Vds a 2-D inner,

  <variable>
        <name>Vds</name>
         <isoline>
                <isoline>
                        1.0, 2.0, 3.0, 4.0, 5.0
                </isoline>
                <isoline>
                        1.0, 2.0, 3.0, 4.0, 5.0
                </isoline>
        <isoline>
  </variable>

Now we form a "dataset" by combining these variables:

  <dataset>
          <name>DC IV Curve</name>
        <indep var="Vgs">
                <indep var="Vds">
                        <depend var="Id"/>
                        <depend var="Ig"/>
                </indep>
        </indep>
  </dataset>

This dataset has two dependents Id and Ig (only Id defined here) and
these dependents are 2-D with 2 independents, Vgs and Vds.

The data is clearly on a set of isolines (IV curve in this case). It's
structure is very clear and attributes may be added in a structured way
to add meta data that table_model can access.

1. Interpolation on Log scale [USER REQUEST]
------------------------------------------
A flag must be available to indicate that particular column is data
which must be interpolated in the log domain.
   
         Example 1:
        1 0
        10 0
        100 -20
        1000 -40
        10000 -60
        100000 -80

On a log plot, this data is piecewise linear:
  0 between 1 and 10, -20 per 10log(10)
        
For an input of 31622, the correct output is -70

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Received on Mon Jan 31 10:20:14 2005