Re: Proposal for two additional environment parameter functions

From: Geoffrey.Coram <geoffrey.coram_at_.....>
Date: Thu Jul 12 2007 - 04:27:10 PDT
Dave -
Are you just trying to extend OOMRs to spice elements?  It seems the
example you gave below could be done within the existing syntax,
   $strobe("%m: Value of '%s' in '%s' is %g", "x", "atop.ch", atop.ch.x);
since the elements are all Verilog instances.

If you are trying to extend OOMRs to spice elements, why not
just say so?  Then all the restrictions on their use will be
clear (as brought up by Gordon V on sv-bc).

I'm also uneasy about "." meaning "start from the top."  In
paramsets, we assign values with
   .vth = 0.7;
which assigns a value to the underlying module paramter.
I think SystemVerilog uses $root for the top of the hierarchy.
And OOMRs have some search algorithm; I think it looks locally
and then from the top.

-Geoffrey



David Miller wrote:
> Hi Bob,
> I think I was misleading before, sorry. I mean I currently have 
> $simprobe() implemented in my simulator as an extension. It needs to 
> actually get values from the simulation engine, I have to access values 
> and functions that are not accessible to users. So even if I implement 
> it as a VPI function, doesn't it mean that I still internally need code 
> that knows how to get the values from my simulator engine? And if 
> another simulator tried to use a model that contained $simprobe, 
> wouldn't it also need its own specific code to extract the values? What 
> am I missing?
> 
> As for $simparam, my first thought was to merge $simparam into $simprobe 
> where if the first argument to $simprobe was a empty string, the 
> behaviour would be the same as $simparam
> 
> $simprobe("","gmin") == $simparam("gmin")
> 
> But unfortunately this won't work as $simparam is already out there. 
> $simprobe does a lot more than $simparam, so I don't think it would be 
> able to be merged into $simparam cleanly. Plus the name of $simparam is 
> misleading, $simprobe, is not accessing parameter values, it is 
> accessing dynamic device quantities during simulation.
> 
> Cheers...
> Dave
> 
> Bob Floyd wrote:
>> Hi Dave,
>>
>> A. Can you explain why your current VPI implementation of `$simprobe` is
>> non-portable?
>>
>> B. Why not improve `$simparam` to support the proposed new features of
>> `$simprobe`?
>>
>> Bob
>>
>>> -----Original Message-----
>>> From: David Miller [mailto:David.L.Miller@freescale.com]
>>> Sent: Wednesday, July 11, 2007 4:53 AM
>>> To: Bob Floyd
>>> Cc: verilog-ams@eda.org
>>> Subject: Re: Proposal for two additional environment parameter functions
>>>
>>>
>>> Hi Bob,
>>> That is how I currently do it, but it means that models that we
>>> implement using
>>> this feature are non-portable which I want to avoid. I was
>>> thinking that this
>>> function is useful enough that it can be part of the language.
>>> Note that although the examples I show are Verilog-AMS, the main
>>> need for this
>>> function is to retrieve values from spice primitive and sub
>>> circuit devices. We
>>> currently have no way in the language to get values from the
>>> Spice engine apart
>>> from $simparam() which is too limited.
>>>
>>> Cheers...
>>> Dave
>>>
>>> Bob Floyd wrote:
>>>> Why not implement $simprobe as your own VPI function, thus minimizing
>>>> clutter in the language?
>>>>
>>>> -------------------------------------------
>>>> 2. $simprobe(instance, param_name [, expression])
>>>> Similar to $simparam(), this function will retrieve the value
>>> of a given
>>>> parameter from a given instance. If the instance/parameter does
>>>> not exist, it
>>>> will stop with an error. If the optional argument <expression> is
>>>> specified, it
>>>> will return this value in lieu of the error. This function is not
>>>> limited to
>>>> retrieving values from Spice elements, but also Verilog-AMS instances.
>>>>
>>>> [LRM TEXT]
>>>> $simprobe() allows the user to query the value of an element within the
>>>> specified instance. The function returns a real scalar value.
>>>> The general form of the $simprobe function is:
>>>>     $simprobe(instance, param_name [, expression])
>>>>
>>>> <instance> is a string constant (either a literal or string
>>>> parameter). If the
>>>> string is prefixed with a '.' character, then the characters
>>>> following the '.'
>>>> character make up the full hierarchical name of the instance to
>>>> query. If the
>>>> first character of the instance string is not a '.', then the
>>>> string is the
>>>> local name of the instance to query. It is a compilation error to use a
>>>> hierarchical instance name where the string is not prefixed with
>>>> a '.' character.
>>>>
>>>> <param_name> is the name of the parameter whose value is
>>> required. It is a
>>>> string constant (either a literal or string parameter). A
>>>> parameter can be any
>>>> valid scalar or indexed vector output parameter for the instance
>>>> in question.
>>>>
>>>> <expression> is an optional argument. It can be any valid Verilog-AMS
>>>> expression. When specified, its value will be returned in case of
>>>> an error.
>>>>
>>>> When <instance> is specified in the hierarchical form,
>>>> <param_name> will be
>>>> retrieved from <instance>. If <instance> or <param_name> does
>>> not exist an
>>>> error will be raised. If <expression> has been specified, it's
>>>> value will be
>>>> returned in lieu of raising the error.
>>>>
>>>> Example:
>>>> module grandchild();
>>>>    parameter string inst = ".atop.ch";
>>>>    analog $strobe("%m: Value of '%s' is %g", inst, 
>>>> $simprobe(inst,"x"));
>>>> endmodule
>>>> module child();
>>>>    real x;
>>>>    grandchild gc();
>>>>    analog x = 10;
>>>> endmodule
>>>> module top();
>>>>    real x;
>>>>    child ch();
>>>>    analog x = 5.0;
>>>> endmodule
>>>>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Thu Jul 12 04:27:36 2007

This archive was generated by hypermail 2.1.8 : Thu Jul 12 2007 - 04:27:50 PDT