RE: $table_model() requirements

I agree, the functionality may be available, but
it is certainly not in Verilog-AMS, so in tools
which only support Verilog-AMS or its analog
subset it is not available.

However, since most of these tools still support
the $table_model, I think extending $table_model
may be a good interim solution while we are
waiting for SystemVerilog-AMS to become a reality.

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 1:25 PM
To: verilog-ams
Subject: 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.

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