RE: Final text for $table_model in 2.3

Hi Jonathan,

I'm not a big fan of the cryptic nature of the control string. However,
having reviewed what needs to be done to really make data based modeling
more flexible in VAMS, I decided for 2.3 we would keep things simple. No new
functions or file formats, only simple mods to the existing function. [See
earlier LRM reflector discussions for some thoughts on using an XML format.
In a later presentation we were thinking perhaps of adding a YAML header to
the file
http://www.eda.org/verilog-ams/htmlpages/public-docs/table_model_LRM_23_prop
osal_1.pdf.]

In the future I think we need to consider adding a data type that has
independent and dependent components and a set of functions that operate on
the that type (one of those functions needs to be a table interpolate type
function). If that ever happens, we'll probably leave the existing
table_model function as is, and not continue to extent its functionality via
characters in a control string.

Regards,
Patrick


-----Original Message-----
From: Jonathan David [mailto:jb_david@yahoo.com] 
Sent: Thursday, June 28, 2007 1:19 PM
To: patrick@tiburon-da.com; Verilog-AMS LRM Committee
Cc: patrick@tiburon-da.com
Subject: Re: Final text for $table_model in 2.3

Now I'm really sorry I missed the meeting.. (I'm assuming I did)
-- I don't like the  "integer" based lookup system for the data file where
there are multiple dependent variables.. 
wouldn't it be better to use some sort of XML like string definition in the
file to define the dependent and independent variable names for the Iso
lines, so I can look up the Dependent variable value by NAME? 
using integers is FINE if you automate the whole thing, but if you have
OpenOffice calc dump the datafile, I'd much prefer to pick up the column  by
name rather than by integer!.
and having a clear distinction between the dependent variables and
independent ones in the data file would let the elaborator identify cases
where you specified (or ignored) 3 control vars, and now there are 4! 

In this case, id probably just use one dependent variable per file, as the
file name would give me that control, but from a memory usage point of view
a single file would probably be better..
I would suggest that we allow multiple format types with another (optional)
control character.. 
 this space separated one,  a CSV one (ie dumped from a spreadsheet - use
the last Text column as the NAMES) ) and an XML style format where
properties can be specified nicely.. (even the interpolation and
extrapolation info - so that the user would only need to specify that info
in the model if he doesn't want to use the default.. 


Another application for this might be where you want to use a paramset to
select which column to read the data from.. (if the data are typical,
bestcase, worstcase
temperature could be an outside (discrete) variable.. while 
--  THAT would be a good subject for a BMAS paper.. 

 


Jonathan David
j.david@ieee.org
jb_david@yahoo.com
http://ieee-jbdavid.blogspot.com
Mobile 408 390 2425
Work:
jbdavid@scintera.com
http://www.scintera.com
408 636-2618

----- Original Message ----
From: Patrick O'Halloran <patrick@tiburon-da.com>
To: Verilog-AMS LRM Committee <verilog-ams@eda.org>
Cc: patrick@tiburon-da.com
Sent: Wednesday, June 27, 2007 11:15:46 PM
Subject: Final text for $table_model in 2.3

Hi,

The final text for $table_model in 2.3 is available at this temporary
location

www.tiburon-da.com/lrm-docs/table_model_2.pdf

Geoffrey will probably upload the file to the usual location before the
meeting tomorrow.

Regards,
Patrick

Patrick O'Halloran
Tiburon Design Automation
www.tiburon-da.com
707-539-7368 (office)
707-321-0400 (cell)




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





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