Re: syntax for $limit

Verilog has both escaped names and hierarchical name too so you can have
something like \my_sim::my_func as an identifier or spice.func_name (if
you make spice a special object).

I think the preference going forward in SystemVerilog is to use "." or
"::" syntax where possible since it works with class objects, and avoid
creating new keywords.

My personal preference would be to use the "::" syntax e.g.

    SPICE::pnjlin // built-in spice function

i.e. reserve the word SPICE and use SPICE::<spice object> to reference
simulator built-ins.

The SystemVerilog CC committee has defined a "Direct Programming
Interface" for declaring external functions supplied by the simulator or
other compiled code, so you can just say something like the following
and have it resolved at link time:

  import "DPI" mySim_fetlim = function fetlim;

Kev.

Geoffrey.Coram wrote:

>Forwarded to the list because I don't have an easy answer...
>
>
>Chandrasekaran Srikanth-A12788 wrote:
>
>
>>Geoffrey,
>>
>>You might have some problems defining the BNF if you just have identifier (instead of allowing both string and fn_ident for second arg)...I have mentioned both the syntax below...let me know your thoughts on the same. Lets call the second argument to $limit in BNF terminology as limit_fn_identifier, and I am having a go at how this will be defined
>>
>>Option 1:
>>limit_fn_identifier
>> : spice_identifier
>> | analog_fn_identifier
>>
>>spice_identifier : pnjlim
>> | fetlim
>> | simulator_specific_lim
>>
>>Option 2:
>>limit_fn_identifier:
>> string_identifier
>> | analog_fn_identifier
>>
>>where string_identifier is a quoted string (referring to spice function) or an user defined func (UDF) identifier if not quoted
>>
>>In option1, I have differentiated spice_identifier and analog_fn_identifier because the grammer has to define things till the leaf levels and I have to introduce spice_identifier otherwise it will make the grammer incomplete (or always search for analog_fn_identifier). But on doing so, we will have to introduce some keywords (if the second argument is not quoted) which will be good to avoid. But with option1, if the simulator has a function with a name, model writter cannot overwrite with UDF with same name (he cannot change the precedence, but ofcourse there may not be any reason to do that). The advantage however of this option is that, if user writes a UDF which is later inbuilt into the simulator there is no need to change the model.
>>
>>Advantage of option 2: Model writter can clearly distinguish from the grammer whether he wants a user defined function or spice function (if both exist). If for some reason the designer wants to write a different version of pnjlim they can do it, and distinguish the two by the usage. The advantage of this is, if user has specified spice, and if that inbuilt fn does not exist then i/p is just passed through. However, if user has specified UDF and if the fn does not exist - its an error. (so the availability of the function can be handled differently depending whether its spice or UDF). Disadvantage ofcourse, is explicit change to model to go from UDF to a spice fn when UDF is supported by simulator at latter date. Probably this might be a good thing also.
>>
>>Probably I have made all this more complicated and confusing than whats it is originally intended for, but I think it will be good to clarify the BNF and also semantics when its being proposed. Also, probably my poor phrasing makes it look complicated. :)
>>
>>Regards,
>>Sri
>>
>>

-- 
Kevin Cameron, CPU Technology, CA 94588, Tel.: (925) 225 4862