Re: $table_model() requirements

Patrick O'Halloran wrote:
>
> 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.
>
For long-term language development I think it helps to move stuff into 
user-domain by making it programmable rather than a built-in special 
case. I would just make the format in the LRM a "suggested" format and 
provide sample code that reads it, then let the users do what they want.

We could start a standard-functions sub-committee that looks after the 
code for reading odd data file formats - that committee would probably 
stay on at Accellera when the language itself gets absorbed into SV (at 
the IEEE) so that it can easily accept donations and distribute them as 
open-source.

Kev.
>
> 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> [mailto:owner-verilog-ams@eda.org] On Behalf
> Of Kevin Cameron
> Sent: Thursday, May 10, 2007 9:59 AM
> To: verilog-ams@eda.org <mailto: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.