[ibis-macro] Re: question on Model_Specific branch name in input parameter string
- From: "Todd Westerhoff" <twesterh@xxxxxxxxxx>
- To: <radek_biernacki@xxxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
- Date: Thu, 18 Mar 2010 22:52:42 -0400 (EDT)
Radek,
I like what you've said below abut the relationship between the DLL input
and .ami files, but I'd like to switch the wording around to describe the
original problem we were trying to solve.
Let's say a TX DLL with 4 taps (1 precursor, cursor & 2 post-cursor)
expects a control string in the following format to set the tap
coefficients:
((tap_filter(-1 0)(0 1)(1 0)(2 0))
Let's also say that each of the taps is allowed to vary between -1 and 1,
and that the default setting for the taps is to be 0, 1, 0 and 0,
respectively.
That's easy to describe in text (I just did), but how do we specify this
to a simulator? Moreover, if the simulator wanted to present the 4 tap
settings to the user and allow the user to specify the settings to be used
for simulation, how could the simulator ensure that the user's selections
were within the ranges the model could support, and ensure that those
selections were properly formatted for presentation to the model?
That's exactly the problem the .ami syntax was designed to solve:
(tap_filter (Description "Transmit de-emphasis tap weights")
(-1 (Usage InOut)(Range 0.0 -1.0 1.0)(Type Tap)(Default 0)
(Description "Pre-cursor tap weight"))
(0 (Usage InOut)(Range 1.0 -1.0 1.0)(Type Tap)(Default 1)
(Description "Main tap weight"))
(1 (Usage InOut)(Range 0.0 -1.0 1.0)(Type Tap)(Default 0)
(Description "First post-cursor tap weight"))
(2 (Usage InOut)(Range 0.0 -1.0 1.0)(Type Tap)(Default 0)
(Description "Second post-cursor tap weight"))
)
The model doesn't read the .ami file directly; the simulator does, for the
purpose of deciding what input string to present to the model and how to
format it. That's a departure from traditional SPICE models, which are
typically subcircuit netlists that are to be included as part of the main
netlist.
The Reserved_Parameter data was NEVER intended to be presented to the DLL,
as this branch contains information that the simulator needs to know how
to run the model and how to process the results.
I'm not going to take a position on whether the DLL control string and
.AMI syntaxes are two different languages or not. The important point, I
think, is that the two are RELATED to each other, and in fact, the .AMI
file provides the information necessary to decide what is a legal DLL
control string and what isn't. To me, the .ami file has two purposes:
1) Define how to construct a DLL control string the model can process -
what Model-Specific parameters are supported, what their allowable values
are, and how they should be formatted (in the case of a number). This is
the purpose of Model-Specific parameters.
2) Provide control information for the simulator that documents the
capabilities of the model, how results should be interpreted and any other
information the simulator needs to know to run the model correctly. This
is the purpose of Reserved Parameters.
The two purposes are accomplished using a common syntax, because we
thought that made sense. The unintended consequence of this was confusion
over how a simple simulation control switch was to be specified. For
example, if the .AMI file was declaring that the model supported impulse
response processing, was the correct syntax
(Init_Returns_Impulse (Usage Info) (Type Boolean) (Default True)
(Description "Impulse response returned."))
Or
(Init_Returns_Impulse (Usage Info) (Type Boolean) (Value True)
(Description "Impulse response returned."))
Or
(Init_Returns_Impulse (Usage Info) (Type Boolean) (Format Value
True)
(Description "Impulse response returned."))
Or
(Init_Returns_Impulse (Usage Info) (Type Boolean) (Format Value
True)
(Default True) (Description "Impulse response returned."))
???
Again, I'm not going to take a position here, other that to point out the
intent of all four of these alternatives is clear ... the model supports
impulse response processing. The intent was always clear to me, although
it's become evident that it wasn't clear to everyone else.
My goal in stating all this was simply to put the .ami syntax in context -
what problem we were trying to solve, and why the syntax looks the way it
does.
If anyone found this explanation useful, then it worth the time it took to
write it. If not, well, then it was worth what you paid for it ;-)
Todd.
________________________
Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh@xxxxxxxxxx
www.sisoft.com
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of
radek_biernacki@xxxxxxxxxxx
Sent: Wednesday, March 17, 2010 9:32 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: question on Model_Specific branch name in input
parameter string
Hi Bob,
It is not really a distinction of two different syntaxes. The
input/output DLL string is simply reduced do the name/value pairs, yet
still in the hierarchy specified by the *.ami file. The choices for the
values must be consistent with what is specified in the *.ami file. What
I am saying is that the parameter hierarchy, data types, usage, format,
etc., is (should be) governed by the content of the *.ami file alone,
and the DLL should be compliant.
The only freedom in handling the input/output DLL strings (as I recall
it) is (should be) that not all the parameters from the *.ami files need
to be included, and the parsers (at both ends: EDA platform and DLL)
should simply ignore unknown parameters. This way, the *.ami file can
describe a superset of parameters that go in to or out from the DLL.
Radek
-----Original Message-----
From: Bob Ross [mailto:bob@xxxxxxxxxxxxx]
Sent: Wednesday, March 17, 2010 6:00 PM
To: BIERNACKI,RADEK (A-Sonoma,ex1)
Cc: ibis-macro@xxxxxxxxxxxxx
Subject: Re: [ibis-macro] Re: question on Model_Specific branch name in
input parameter string
Radek:
The distinction is on two levels
The .ami syntax has elements that have different functions.
Some of these to my understanding are not supported in the
EDA to DLL interface. So a single value for an input that
as part of the input string to the dll such as <par_name 5)
might be expressed in a 1-to-1 way with a different
syntax in the .ami file ((Format Value 5) (Type Integer)
(Usage In) (Description "integer 5") (Default 5)
But 5 could also can be the consequence of a Range selection
through a user interface where 5 is selected, but not
explicitly specified. So the syntaxes can be different,
and the In parameter source may from outside the .ami file.
Bob
radek_biernacki@xxxxxxxxxxx wrote:
> Bob,
>
> I disagree. As far as the content of AMI_parameters_in and
> AMI_parameters_out in DLL calls is concerned, the *ami file is (should
> be) the only source of information on how the DLL expects to
communicate
> with the EDA platform.
>
> Radek
>
> -----Original Message-----
> From: ibis-macro-bounce@xxxxxxxxxxxxx
> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross
> Sent: Wednesday, March 17, 2010 5:01 PM
> To: Arpad_Muranyi@xxxxxxxxxx
> Cc: ibis-macro@xxxxxxxxxxxxx; bob@xxxxxxxxxxxxx
> Subject: [ibis-macro] Re: question on Model_Specific branch name in
> input parameter string
>
> Arpad and Radek:
>
> The confusion is that we are talking about two different syntaxes.
> The syntax between the DLL and the EDA tool appears to be
> a rigidly defined syntax, and succinctly based on fairly good
> BNF principles. Not so for the .ami syntax.
>
> All the documents to date do an insuffient job of explaining
> the process. The .ami syntax was intended to be a similar
> type syntax, but in practice we have so many exceptions
> (e.g., context-sensitive stuff) that it can be viewed as
> a totally different syntax. It happens to be somewhat
> similar to the DLL to EDA syntax in that there might
> be a similar hierarchy structure of branches to branches.
>
> At the extreme, these are just two different syntaxes and
> this should be stated clearly and up front. Special rules
> are added .ami syntax. The EDA tool is in the middle and does the
> translation of the .ami content to interact with the DLL. We
> could have used IBIS keywords or some other language for
> the .ami syntax.
>
> That is why we need the context diagram, and we need to
> be careful everywhere in the text when we talk or refer
> to parameter tree issues. The answer to any simple
> question could be different with respect to DLL syntax
> and .ami syntax.
>
> Syntactical purity has never has existed, and never can be
> a reason for removing existing funtionality that is
> well-established in the industry.
>
> Bob
>
>
> Muranyi, Arpad wrote:
>
>>Radek,
>>
>>Thank you for bringing this up. I was equally confused about this
>>topic many moons ago, and tried to ask the same questions. They
>>are probably in the archives if our email reflector has one...
>>
>>When I asked questions about this, the answers I got made me feel
>>a little that I was mentally retarded because they made it seem
>>that this was clearly described in the spec and it was totally
>>obvious how the EDA tool had to formulate the parameter string
>>for the DLL. I am glad to hear that I am not the only one who
>>is lost and all of the sudden I am starting to feel normal again...
>
> :-)
>
>>
>>I agree that it would be a lot more consistent to do it the way you
>>described it (without removing those branches and moving things up
>>a level). The question after all these months and released models
>>is whether we can make a change for the sake of consistency at the
>>expense of braking existing models... Since this procedure is not
>>described in the existing specification (or not adequately), part
>>of me says that we have the freedom to describe it now any whichever
>>way we feel is right, since the models which were released up to now
>>were made based on non existing or speculative rules.
>>
>>Thanks,
>>
>>Arpad
>>======================================================================
>>
>>
>
>
------------------------------------------------------------------------
>
>>From: ibis-macro-bounce@xxxxxxxxxxxxx
>>[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of
>>radek_biernacki@xxxxxxxxxxx
>>Sent: Wednesday, March 17, 2010 6:18 PM
>>To: ibis-macro@xxxxxxxxxxxxx
>>Subject: [ibis-macro] Re: question on Model_Specific branch name in
>>input parameter string
>>
>>Hi Ambrish,
>>
>>
>>
>>I recall some e-mail exchanges on this subject several months ago, but
>
> I
>
>>do not remember the conclusions.
>>
>>
>>
>>What you are saying sounds like another flaw in the current spec. I
>>would expect the input/output DLL strings to conform COMPLETELY to the
>
>
>>parameter tree hierarchy specified in the *.ami file. The reason is
>>simple: by the principles of a parameter tree we can have exactly the
>>same leaf or sub-branch name in two or more branches. Therefore,
>>stripping a branch (removing it and bringing the entire sub-tree one
>>level up) should not be allowed. Any exceptions from this rule must be
>
>
>>explicitly stated.
>>
>>
>>
>>So, are you saying that stripping the two branches
>
> (Reserved_Parameters
>
>>and Model_Specific) is a de-facto standard?
>>
>>
>>
>>Radek
>>
>>
>>
>>From: ibis-macro-bounce@xxxxxxxxxxxxx
>>[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ambrish Varma
>>Sent: Wednesday, March 17, 2010 12:41 PM
>>To: ibis-macro@xxxxxxxxxxxxx
>>Subject: [ibis-macro] Re: question on Model_Specific branch name in
>>input parameter string
>>
>>
>>
>>Hi Fangyi,
>>
>>It will be
>>
>>
>>
>>(mySampleAMI
>>
>> (ntap 5)
>>
>>)
>>
>>
>>
>>The keywords Reserved_Parameters and Model_Specific are meant for
>>organizing the parameters in the ami file only and not supposed to be
>>passed to the model.
>>
>>
>>
>>Thanks,
>>
>>Ambrish.
>>
>>
>
>
------------------------------------------------------------------------
>
>>From: ibis-macro-bounce@xxxxxxxxxxxxx
>>[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of
>
> fangyi_rao@xxxxxxxxxxx
>
>>Sent: Wednesday, March 17, 2010 3:32 PM
>>To: ibis-macro@xxxxxxxxxxxxx
>>Subject: [ibis-macro] question on Model_Specific branch name in input
>>parameter string
>>
>>
>>
>>Hi, Experts;
>>
>>
>>
>>Based on the current AMI standard should the Model_Specific branch
>
> name
>
>>appear in the input parameter string to the AMI Init call? For
>
> example,
>
>>for the following .ami file
>>
>>
>>
>>(mySampleAMI
>>
>> (Reserved_Parameters
>>
>> ?
>>
>> )
>>
>>
>>
>> (Model_Specific
>>
>> (ntap (Usage In) (Type Integer) (Format Value 5))
>>
>> )
>>
>>)
>>
>>
>>
>>Shall the input parameter string be
>>
>>
>>
>>(mySampleAMI
>>
>> (Model_Specific
>>
>>(ntap 5)
>>
>> )
>>
>>)
>>
>>
>>
>>or
>>
>>
>>
>>(mySampleAMI
>>
>> (ntap 5)
>>
>>)
>>
>>
>>
>>I understand that if the proposed BIRD is accepted then Model_Specific
>
>
>>and Reserved_Parameter branchs will disappear. But for models written
>>based on the current standard it?s not clear which format EDA tools
>>should feed to models.
>>
>>
>>
>>Thanks in advance.
>>
>>
>>
>>Fangyi
>>
>>
>>
>
>
>
--
Bob Ross
Teraspeed Consulting Group LLC Teraspeed Labs
121 North River Drive 13610 SW Harness Lane
Narragansett, RI 02882 Beaverton, OR 97008
401-284-1827 503-430-1065
http://www.teraspeed.com 503-246-8048 Direct
bob@xxxxxxxxxxxxx
Teraspeed is a registered service mark of Teraspeed Consulting Group LLC
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
Other related posts:
