Fangyi, Thanks for your comments. You are absolutely correct that we need to define a few more rules for the situations you mentioned, but we also need to consider other situations, some of which were mentioned in the last ATM meeting this week. For example, the concept of Reserved and Model_Specific parameters may not apply to IBIS-ISS subcircuits at all, but since the [External Model] or [External Circuit] keywords could potentially instantiate VHDL-AMS or Verilog-AMS models which could potentially have algorithms like an AMI DLL, we can't completely do away with all AMI related parameter types and concepts... Thanks, Arpad ============================================================== From: fangyi_rao@xxxxxxxxxxx [mailto:fangyi_rao@xxxxxxxxxxx] Sent: Wednesday, April 04, 2012 11:14 AM To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx Subject: RE: TreeRootName at the end of IBIS file in BIRD117 Thanks for the clarification, Arpad. I agree that the TreeRootName way provides the potential of dependency between variables. On a separate note, what if TreeRootName points to Tx_Jitter which has the format of (Gaussian 0.0 0.1)? What about TreeRootName pointing to a parameter of Type UI (UI is not defined in ibis)? We should spell out the rules to ensure consistency. Regards, Fangyi From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]> On Behalf Of Muranyi, Arpad Sent: Monday, April 02, 2012 4:42 PM To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx> Subject: [ibis-macro] Re: TreeRootName at the end of IBIS file in BIRD117 Fangyi, Thanks for your comments. I can kind of see your point, but I don't think your suggestion would have as many capabilities as the proposed syntax in this BIRD draft. The TreeRootName syntax allows the usage of multiple trees in the same file (.ibs or .par, or even .ami). Also, the proposed Dependency Table would allow more than just a list of values for the parameter assignments. In addition, if we used the TreeRootName syntax for the .ami and .par files, but another syntax for the .ibs files, we would have to invent more new syntax that is not there yet in .ibs files. Is that worth it? I think the simplicity of using the same syntax for the parameter assignment whether the value comes from within the .ibs file or any external files is good. Is there a specific reason you DON'T want that? Thanks, Arpad ================================================================= From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]> On Behalf Of fangyi_rao@xxxxxxxxxxx<mailto:fangyi_rao@xxxxxxxxxxx> Sent: Monday, April 02, 2012 6:03 PM To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx> Subject: [ibis-macro] TreeRootName at the end of IBIS fiel in BIRD117 Hi, Arpad; I don't think the parameter definition section pointed to by TreeNodeName at the end of the .ibs file is necessary in BIRD117 (page 6). http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20120327/arpadmuranyi/BIRD%20117.4%20update%20draft%201/BIRD117_4_draft1.pdf By defining the parameter at the end of the ibis file you are not importing it from an external file. Then why do we still need to indirectly specify the value by using TreeRootName instead of directly assigning the value to the parameter? The only argument I heard is that the TreeRootName way allows multiple values to be specified for a parameter. But I think it's a hack for TreeRootName. I'd rather introduce a formal List syntax to address this issue. Regards, Fangyi