[ibis-macro] Re: BIRD 117 AMI parameter uniqueness
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 10 Apr 2012 23:56:11 +0000
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]
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]
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
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
---------------------------------------------------------------------
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:
