[ibis-macro] Re: BIRD 117 AMI parameter uniqueness
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 11 Apr 2012 19:57:48 +0000
Mike,
Are you sure about "no name can appear in both Reserved_Parameters and
Model_Specific"?
I am not aware of anything like that in the spec. Can you point me to
a page number?
Regarding "as long as we allow only one root", I thought we agreed in the
meeting
on 4/3 that we will allow multiple trees within a parameter file or within
the new keywords [Begin Parameter Trees]/[End Parameter Trees] surrounding
trees if they are there in the .ibs file.
If this whole concept of generalization requires the inclusion of file names
in the parameter reference, I think it would be kind of funny to start
with the file name, then have the root name, but skip the Reserved/Model
specific branch names and continue with the rest of the branches. I would
much rather just include them all. This would eliminate an unnecessary
"exception rule" to remember for all model makers, and parser developer.
Also, keep in mind that for parameter trees used for other than AMI purposes,
we might end up not using these two branches (Reserved and Model_Specific),
and then this skipping rules can become a nightmare.
Regarding the separator character, I feel the same about the parentheses
as you. They come in pairs (open and close) which is an easy source of
error, plus it makes the line longer if there are a lot of them. But I
don't think we can use the dot "." because those are used in file names.
I checked, semicolons ":" are illegal in file names, so those might be
a safe character to use for this purpose, but I am open to suggestions.
Thanks,
Arpad
============================================================================
From: labonte.mike@xxxxxxxxx [mailto:labonte.mike@xxxxxxxxx] On Behalf Of Mike
LaBonte
Sent: Wednesday, April 11, 2012 2:37 PM
To: Muranyi, Arpad
Cc: IBIS-ATM
Subject: Re: [ibis-macro] Re: BIRD 117 AMI parameter uniqueness
Yes, specifying the full path from the root on down would completely eliminate
the need to do any searching at all to find a value. However, since no name can
appear in both Reserved_Parameters and Model_Specific, that particular level
need not be specified to resolve ambiguity. And neither does the root name have
to be specified to resolve ambiguity, as long as we allow only one root. In
fact I am a bit queasy about depending on root name matching, because in LISP
style data formats the very first "car" atom is usually irrelevant, just a
placeholder. So it probably makes sense to specify only the relative path from
below Reserved_Parameters/Model_Specific on down, and have the tools checking
both trees to find the value.
As for whether to use parentheses or dots, I am OK with either. Dots take less
space and there is some precedent for them in that they appear in examples in
the spec, although I see no place where dots are formally specified in IBIS as
a separator. Parentheses serve as a visual reminder that you are invoking AMI
style parameters. But they also introduce one more way to mess up an IBIS file,
failure to balance the redundant right parentheses.
Mike
On Tue, Apr 10, 2012 at 10:26 PM, Muranyi, Arpad
<Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>> wrote:
Yes, that is an equivalent. But I don't want to
introduce too many different ways to achieve the
same thing...
Arpad
==================================================
-----Original Message-----
From: Walter Katz [mailto:wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>]
Sent: Tuesday, April 10, 2012 9:21 PM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: BIRD 117 AMI parameter uniqueness
Arpad,
Or
thisfile.ibs(TreeRootName(Model_Specific(Branch1(Branch2(Vinh))))))
Then if the AMI file in the executable statement was my_ami.ami you would
suggest:
my_ami.ami (TreeRootName(Model_Specific(Branch1(Branch2(Vinh))))))
my shortcut would be:
AMIfile(Branch1(Branch2(Vinh)))
A nose by any other name would still smell.
Walter
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>]
On Behalf Of Muranyi, Arpad
Sent: Tuesday, April 10, 2012 9:43 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: BIRD 117 AMI parameter uniqueness
Walter,
I was responding to your example:
(Root.(Model_Specific(Tap(-1 (Range 0 -.4 1.) (Usage In) (Type Float))) is
represented as Tap.-1 in Labels (e.g. "Tap.-2 Out_PWL")
where these is a dot after "Root". It wasn't clear to me why you put it
there since you also had an open parentheses, but I thought you "meant
it".
Either way, I don't want to go back to the "AMIfile()"
syntax now that we started going down the path of generalizing this whole
thing. I think the best might be to do this:
thisfile.ibs(TreeRootName(Model_Specific(Branch1(Branch2(Vinh)))))
or
thisfile.ibs:TreeRootName(Model_Specific(Branch1(Branch2(Vinh)))))
or
thisfile.ibs:TreeRootName:Model_Specific:Branch1:Branch2:Vinh
or
thisfile.ibs:TreeRootName(Model_Specific:Branch1:Branch2:Vinh)
or anything along those lines...
Thanks,
Arpad
====================================================================
-----Original Message-----
From: Walter Katz [mailto:wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>]
Sent: Tuesday, April 10, 2012 8:23 PM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: BIRD 117 AMI parameter uniqueness
Arpad,
The dot is in the parameter name, which is in (). So there is no parsing
problem at all.
thisfile.ibs:TreeRootName(Model_Specific(dfe.mode))
I do strongly believe that in the case of an IBIS AMI [Model], all that is
required is:
AMIfile(dfe.mode)
This shortcut is rigorously accurate, since we already have the constraint
of leaving off (Model_Specific in the calls to the BNF. We should consider
adding to IBIS 5.2 the rule that a branch or parameter off
(Reserved_Parameter cannot be the same name as a branch or parameter off
(Model_Specific.
I know this is going back to your original proposal which is now a
shortcut to you more general rule for accessing other parameter tree
structures which need not follow the context rule we put into the .ami
parameter tree requiring a Reserved and Model Specific branch.
Walter
-----Original Message-----
From: Muranyi, Arpad
[mailto:Arpad_Muranyi@xxxxxxxxxx<mailto:Arpad_Muranyi@xxxxxxxxxx>]
Sent: Tuesday, April 10, 2012 9:08 PM
To: Walter Katz; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: BIRD 117 AMI parameter uniqueness
Walter,
The dot "." might not work very well as the separator character because it
is a legal character in file names. This is why I was originally thinking
of using the semicolon ":", but I am beginning to wonder if we would be
better off using parentheses.
Thanks,
Arpad
================================================================
-----Original Message-----
From: Walter Katz [mailto:wkatz@xxxxxxxxxx<mailto:wkatz@xxxxxxxxxx>]
Sent: Tuesday, April 10, 2012 8:04 PM
To: Muranyi, Arpad; 'IBIS-ATM'
Subject: RE: [ibis-macro] Re: BIRD 117 AMI parameter uniqueness
Mike,
"dfe.mode" and "agc.mode" are the correct syntax. This is even mentioned
in the last page of BIRD 150:
Note that Hierarchical Parameter Names are represented using "." as the
hierarchical delimiter. For example, the name of the parameter (Root
.(Model_Specific(Tap(-1 (Range 0 -.4 1.) (Usage In) (Type Float))) is
represented as Tap.-1 in Labels (e.g. "Tap.-2 Out_PWL").
Walter
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>]
On Behalf Of Muranyi, Arpad
Sent: Tuesday, April 10, 2012 7:56 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: BIRD 117 AMI parameter uniqueness
Mike,
The next question then is "how far up" do we need to go from the parameter
name in the tree to have a "fully qualified"
reference?
I can see that the same parameter name might appear in the
Reserved_Parameters branch as well as in the Model_Specific branch. I
don't recall the spec prohibiting that either...
So should this parameter reference then include basically the whole "nine
yards" after the TreeRootName? For example, if we had a parameter tree
like this:
[Begin Parameter Trees]
(TreeRootName
(Description "Converter_Parameters illustration")
(Model_Specific
(TstoneFile (Usage In)(List "Typ.s4p" "Min.s4p" "Max.s4p" "SSS.s4p"
"FFF.s4p")(Type String)
(Vinh (Usage In)(List 0.8 0.7 0.9)(Type Float)
(Vinl (Usage In)(List 0.2 0.1 0.3)(Type Float)
(R1 (Usage In)(Range 50 45 55)(Type Float)
(Trf (Usage In)(Value 10.0e-12)(Type Float))
) | End Model_Specific
)
[End Parameter Trees]
should the assignment reference look like this:
thisfile.ibs:TreeRootName(Model_Specific(Vinh))
regardless of whether "Vinh" appears only once or multiple times within
the tree?
A refinement detail for the syntax is the question of what character
should be used as the separator character? I had a semicolon between the
file name and the TreeRootName above, but I wonder whether we should use
the same separator character in the entire reference syntax, like this:
thisfile.ibs(TreeRootName(Model_Specific(Vinh)))
or
thisfile.ibs:TreeRootName:Model_Specific:Vinh
Comments and suggestions are welcome from anyone.
Thanks,
Arpad
=============================================================
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>]
On Behalf Of Muranyi, Arpad
Sent: Tuesday, April 10, 2012 6:33 PM
To: IBIS-ATM
Subject: [ibis-macro] Re: BIRD 117 AMI parameter uniqueness
Mike,
You are making a good point. But instead of resolving this on the D_to_A
line, as you suggested:
D_to_A D_drive my_drive my_ref (Vd2a(low)) (Vd2a(high)) (Td2a(fall))
(Td2a(rise)) Typ
this should be resolved on the parameter assignment line:
Converter_Parameters MyVinl = thisfile.ibs:TreeRootName(Vd2a(high))
because the converter parameter name on the D_to_A line is just a
parameter name in the .ibs file (defined by the "Converter_Parameters"
subparameter), not the parameter name in the parameter tree...
Thanks,
Arpad
=============================================================
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>]
On Behalf Of Mike LaBonte
Sent: Saturday, April 07, 2012 8:03 AM
To: IBIS-ATM
Subject: [ibis-macro] BIRD 117 AMI parameter uniqueness
As we have been discussing BIRD 117, which offers a way to reference
AMI-style parameters trees, I am wondering if we might suffer from name
ambiguity. Consider this fragment of a .ami file:
(Model_Specific
(dfe
(mode (Usage In)(Type Integer)(List 0 1)(Description "DFE on/off
control"))
)
(agc
(mode (Usage In)(Type Integer)(List 0 1)(Description "AGC on/off
control"))
)
)
The parameter "mode" appears twice, but as far as I can tell that is legal
because it follows the BIRD 127 rule that "Each sub-branch of a branch
must have a unique name.". I can't find any rule disallowing two
parameters with the same name in different branches.
EDA tools handle this ambiguity by using a syntax like "dfe.mode" and
"agc.mode" when giving users control. But nothing like that is suggested
in BIRD 117. The examples there are simple parameter names like "MyTrise".
It seems it would be up to the EDA tool to walk through the various branch
levels until it finds a parameter at any level with a matching name. If
only one is found, great. If more than one is found ... then what?
I would feel more comfortable if parameters were always referenced by full
hierarchy. For example:
| D_to_A d_port port1 port2 vlow vhigh trise
tfall corner_name
D_to_A D_drive my_drive my_ref MyVlow MyVhigh1 MyTfall MyTrise
Typ
could be...
| D_to_A d_port port1 port2 vlow vhigh trise
tfall corner_name
D_to_A D_drive my_drive my_ref (Vlow) (Vhigh1) (Tfall) (Trise)
Typ
or...
| D_to_A d_port port1 port2 vlow vhigh trise
tfall corner_name
D_to_A D_drive my_drive my_ref (Vd2a(low)) (Vd2a(high))
(Td2a(fall)) (Td2a(rise)) Typ
depending on where the parameters fall in the tree hierarchy.
Mike
---------------------------------------------------------------------
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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:ibis-macro-request@xxxxxxxxxxxxx>
Subject: unsubscribe
Other related posts:
