Re: $table_model() requirements

Muranyi, Arpad wrote:
> Good luck convincing a tool vendor to support
> something that is not in a specification...
>
> Arpad
> ============================================= 
>   
What I meant was: rather than defining new stuff unique to AMS, we 
should adopt whatever bits of SV are required as part of the AMS 
standard - i.e. just copy and paste from one LRM to the other.

Assuming that SV and AMS are to be integrated anyway, that's the minimum 
work.

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