RE: $table_model() requirements

Hi Kevin,

 

There are two factors motivating a file based data model in 2.3

-          most users expect to build a data based model directly from an
file using a simple function call.

-          it's already part of 2.2.

 

Once you've decided that the data will be in a file, then if possible, it's
best to keep the information associated with that data in the same place.
Hence the idea to put  a header area in the existing file. 

 

On other file formats, to improve flexibility, I'm suggesting  there should
be mechanisms to allow vendors to add support for any format they wish. To
comply with the LRM they will of course always need to support the format
specified in the LRM.

 

Regards,

Patrick

 

From: K. Cameron [mailto:edas@v-ms.com] 
Sent: Friday, May 11, 2007 1:59 AM
To: patrick@tiburon-da.com
Cc: verilog-ams@eda.org
Subject: Re: $table_model() requirements

 

Patrick O'Halloran wrote: 

Hi Kevin,
 
The $table_model() function currently provides two ways to specify the data
- from a file or from an array. Most uses of the function that I've seen so
far rely of a file source. Rather than dropping a file based data source I
think we need to add flexibility and allow the use of other common data
formats (and possibly introduce the concept of a table handle where we can
hang not only the data but attributes of that data). 
  


Personally I'd rather not specify file formats, I'd rather ask the question:
can you write the parser in Verilog-AMS?
If the answer is no, then we need to add more functionality. And when/if you
can write the parser, just stick it in an appendix as sample code.

Doing the extra file-format stuff outside of the language proper isn't
really a good use of committee time (IMO) - people will argue over that
kind of thing  for years, particularly if it's cross committee. Being able
to write a parser in Verilog-AMS for whatever other (VHDL) committees
eventually decide is probably less effort for the language committee and
simulator developers (and more flexible for the users).

 
The proposed meta-data may go directly in the data file or go in a separate
file. The latter option provides backward compatibility with the 2.2
solution and may also be used with other formats (where you cannot modify
the data file). I consider things like what interpolation scheme to use, how
the extrapolate, etc to be attributes of the data and so it's natural to
keep that information in one place with the data rather than on every
$table_model() call. It also has the benefit of keeping the $table_model()
call clean and simple. 
  

I'd like it to be in one place: in the language proper. I think a less
simple call but keeping all the data together in Verilog-AMS is overall
cleaner.

Kev.

 
Regards,
Patrick
 
-----Original Message-----
From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On Behalf
Of Kevin Cameron
Sent: Thursday, May 10, 2007 9:59 AM
To: verilog-ams@eda.org
Subject: Re: $table_model() requirements
 
 
Can we do this without requiring a file format, i.e. can the $table 
functions just work off arrays and leave it up to the user how they 
populate those arrays (from files)?
 
 - you could just generate the table model directly as Verilog-AMS 
source, no need for splitting it into a Verilog wrapper around a .dat 
file - less chance you'll get the wrong file (or not find it).
 
Kev.
 
 
...
  

Hi All,
 
It's been a long time since we discussed improving the $table_model()
function in LRM 2.3 so I thought it would be best to start by reviewing
      

all
  

of the requirements gathered from the reflector and from users. Slides
attached.
 
Regards,
Patrick
 
Patrick O'Halloran
Tiburon Design Automation
    
      

  
    

 
 
  

 


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