RE: $table_model() requirements

Good luck convincing a tool vendor to support
something that is not in a specification...

Arpad
============================================= 

-----Original Message-----
From: Kevin Cameron [mailto:kevin@sonicsinc.com] 
Sent: Monday, May 14, 2007 2:01 PM
To: Muranyi, Arpad
Cc: verilog-ams
Subject: Re: $table_model() requirements

Muranyi, Arpad wrote:
> 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.
>   
Just need to support the subset of SV stuff needed for parsing data 
files in SV.

Kev.
> 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.