Hi Arpad, I was thinking if we had: Table tbl = $build_table(..); Then you might have functions like, y = $interp(tbl,.) // interpolate the table arr = $table_to_array(tbl, lookup_vars); // convert (possibly a cross section) of a table to an array Or, we could continue to add functionality into the existing function. That is, for a table of dimension n, and m lookup args, then return an array of dimension n-m. I'm more in favor of having a table object and a set of support functions - build it, interp it, translate it, etc. That keeps the common use of interpolation usable. Regards, Patrick From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On Behalf Of Muranyi, Arpad Sent: Monday, May 14, 2007 8:57 AM To: verilog-ams@eda.org Subject: RE: $table_model() requirements Having said that, I remember there was a time when I really wished that the $table_model had a feature to return the vector(s) as is in the tables of the file without any interpolation, or any massaging. Basically work as if it was a file to array function. Could this feature be considered for it? Thanks, Arpad ======================================================= _____ From: owner-verilog-ams@server.eda.org [mailto:owner-verilog-ams@server.eda.org] On Behalf Of Muranyi, Arpad Sent: Monday, May 14, 2007 8:53 AM To: verilog-ams@server.eda.org Subject: 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 <http://www.mailscanner.info/> MailScanner, and is believed to be clean. -- 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 <http://www.mailscanner.info/> 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.Received on Mon May 14 09:12:52 2007
This archive was generated by hypermail 2.1.8 : Mon May 14 2007 - 09:12:55 PDT