Ken, We have done the exactly the same thing, for the same reasons. Walter From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ken Willis Sent: Friday, March 25, 2011 9:30 AM To: wkatz@xxxxxxxxxx; Arpad_Muranyi@xxxxxxxxxx; 'IBIS-ATM' Subject: [ibis-macro] Re: AMI Info Model_Specific parameters: Market Speed vs Standards Speed Walter, I think there are some differences here with regards to Sigrity, Gennum, and back-channel. For a new capability like back-channel, you need to do proof-of-concept first. One good way to do this is with an external customer, who also has vested interest in the capability. This is what we have done. Then we went and brought it to IBIS in efforts to work towards standardization. But note that the effort is to standardize it in IBIS. We are not simply pushing through what we have already implemented. The first discussion of back-channel the IBIS-ATM committee had on this brought some significant changes to what we had done initially. This is all part of the process, and is expected. Note also that the Gennum models have been implemented so that you can turn back-channel "off" and use them as standard IBIS-compliant AMI models. There is nothing blocking anyone from using any IBIS-compliant tool with these models. Thanks, Ken Willis Sigrity, Inc. 860-871-7070 kwillis@xxxxxxxxxxx _____ From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz Sent: Thursday, March 24, 2011 4:30 PM To: Arpad_Muranyi@xxxxxxxxxx; 'IBIS-ATM' Subject: [ibis-macro] AMI Info Model_Specific parameters: Market Speed vs Standards Speed Arpad, The fundamental problem that we face is the need for IC Vendors to supply System Companies with models that they can use today to design next generation high speed products. Info parameters in BIRDS 121-124 are required to do this today. The market cannot wait for IBIS to approve this, and then wait for EDA vendors to support it. It is critical that when it is required to add information to a .ami file that a simulator must use (e.g. a Model_Specific Info parameter), that the parameter be published by submitting a BIRD to make it a Reserved_Parameters. The need for this was described in the OpalT document, and in numerous IBIS-ATM discussions. In the meantime EDA Vendors have the information they need to support these advanced capabilities as their markets require them. This is exactly what Sigrity and Gennum have done with their backchannel proposed BIRD, and SiSoft will determine when the specification of backchannel is firm enough, and then support it in our tool when our customers require it. Walter From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Thursday, March 24, 2011 2:54 PM To: IBIS-ATM Subject: [ibis-macro] Re: Table Clarification BIRD If I remember correctly, we spent a considerable time on this topic in the last ATM teleconference. In that discussion I think I heard Walter state something along the lines of who cares, the EDA tool just copies everything to the parameter string for DLL and doesn't need to know whether the first column is a row number or useful data. Then the question was raised, how about (Usage Info) in which case the table is to be consumed by the tool, and in that case the tool would have to know what the first column is. This brought us to the topic of syntax consistency and ease of parsing, etc. But this also raises another issue, namely whether the Model_Specific parameters should ever be (Usage Info). Note that this is not a problem with Reserved_Parameters, which supposed to be well defined in the spec. Comments? Arpad ========================================================== Walter Katz wkatz@xxxxxxxxxx Phone 303.449-2308 Mobile 720.333-1107