proposal to enhance $tablemodel in Verilog-AMS

For discussion at todays committee meeting ....

Proposal to enhance $tablemodel in Verilog-AMS
----------------------------------------------
--Martin O'Leary 1/17/2004

1. Introduction
===============

The $table_model has been a popular extension to the Verilog-AMS language.

However the existing definition has a number of limitations that effect its usefulness.

These will be called out in turn and proposals made to address them

2. Limitations and Proposals to Address them
============================================

2.1 only 1 dimension is supported
----------------------------------

Proposed Resolution a:

This should be changed so that vendors are required to support at least 3.

However the data is required to be laid out as isolines.

The interpolation algorithm is ... (I need more time to specify this clearly in pseudo-code and diagrams but it generally involves working creating a splines in a dimension and then interpolating these to create points to generate splines in the next dimension. Data exception conditions would also be described.)

Proposed Resolution b:
This resolution is an extension/supplement of 'a' not an alternative.

If the interpolation always linear then scattered data should be supported by $table_model

Algorithm is TBD. I see this as a later extension but if someone wants to work on this now - fine by me.

2.2 Data tolerances
-------------------

If the input data is measured, it might be noisy which would break the isoline requirement.

Proposed Resolution:

The user should be allowed to specify a tolerance for all dimensions but also a tolerance for specific dimensions.

Abstol and reltol would be supported.

Reltol would be relative to different between the maximum and minimum value in a particular dimension.

This would be done by addition arguments in the control string.

$table_model(in1,in2,in3,out1,out2,"mydata.dat",".ireltol(1e-9), .ireltol1(1e-10)");

ireltol is for input reltol.

By default ireltol is 1-6 and iabstol is 0.

2.3 Skipping data in the input columns
--------------------------------------

Users have requested when a table is constructed that it should be possible to skip some of the columns in the data file. This is because the data file could contain additional inputs or outputs that the user does not want to model.

Proposed Resolution: (see resolution for 2.4)

2.4 Multiple outputs
---------------------

Customers have also requested that it possible to have more than 1 output from a $table_model function

Proposed Resolution:

The control string should be extended so that it specifically indicates which columns in the input table are input and which are output.

e.g.;
$table_model(in1,in2,in3,out1,out2,"mydata.dat",".inputs(1,3,4), .outputs(2,5)");

The arguments list to the $table_model would hence be;

$table_model(<list of inputs expressions>,[<list of outputs variables>],<table_source>,<control_string>);

$table_model would return the value of its first output for backward compatability.

2.5 discrete inputs
-------------------

Users have requested and I seen in customer data that some input columns are discrete numbers which should not be interpolated.

Eg 'state' in the following example is a discrete number.

state vin vout
0 1.1 5.1
0 2.1 5.0
1 1.1 4.9
1 2.1 4.8
2 1.1 3.3
2 2.1 3.0

Proposed Resolution:

A new "interpolation" character, 0, should be added to support this. The user would be required to only enter values that appear in the table data for this argument. An error would result if this did not occur.

2.6 Named arguments
-------------------

The table model is now starting to have a lot of arguments. From a usability point of view it would be nice if $table_name supported named arguments.

e.g. $table_model(.i1(a),.i2(b), ... etc

However named arguments are not supported in system tasks in Verilog-AMS or in systemVerilog.

They however supported in function calls in SystemVerilog.

This would be a nice and natural extension to make to the language.

Proposed Resolution:

Changing SystemVerilog is not going to be the easiest thing to do at this point.

For now I propose that we use the named argument syntax inside the control string as it is more readable and will be easy to convert when the standard is changed.

Most of previous proposals are written taking the named argument approach inside the control string.

Existing control string arguments should be supported in this form as well.
Received on Mon Jan 17 13:36:37 2005