Re: $table_model() requirements

I suspect most of the functionality required for a parser is probably
available, and if it's not in AMS it will be in SV, so it would be a
better use of time to work on SV integration.

Kev.

Muranyi, Arpad wrote:
> Kevin,
>
> This is true, but in order to let the user to
> do all this themselves, the language should have
> all the file read and string parse capabilities,
> which it doesn't.
>
> Arpad
> ================================================
>
>  
>
> -----Original Message-----
> From: owner-verilog-ams@server.eda.org [mailto:owner-verilog-ams@server.eda.org] On Behalf Of Kevin Cameron
> Sent: Monday, May 14, 2007 10:21 AM
> To: patrick@tiburon-da.com
> Cc: verilog-ams@server.eda.org
> Subject: Re: $table_model() requirements
>
> 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.
>
>   




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