RE: $table_model() requirements

Another reason it would be good to keep the file
input option for $table_model is that Verilog-AMS
has practically no file reading/parsing capabilities
in the language and the file input for $table_model
is the only way we can get data into a model from
a file...
 
Thanks,
 
Arpad
=====================================================

________________________________

From: owner-verilog-ams@server.eda.org [mailto:owner-verilog-ams@server.eda.org] On Behalf Of Patrick O'Halloran
Sent: Monday, May 14, 2007 8:47 AM
To: 'K. Cameron'; verilog-ams@server.eda.org
Subject: 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 <http://www.mailscanner.info/> , and is 
believed to be clean. 

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