Kukal, I agree that the use model in BIRD 116-118 is convoluted and ODD. Opal, and BIRD 122 (which SiSoft introduced and supports) has the following flow: I start with IBIS-model1 -> This gives me a pointer to AMI-model -> Tool reads .ami settings and then picks AMI-Analog model for characterization - this quite natural. The only real objection to BIRD 122 from the IBIS-ATM committee is that is has only four predefined analog templates; Tx Touchstone, Rx Touchstone, Tx simple RC circuit Rx simple RC circuit. Many members of the IBIS-ATM committee (the other EDA Vendors) objected to this because they wanted to have the ability to have more flexible and user definable RC (IBIS-ISS) circuits. I do not object to this at all, I just think that the definition of these subckts should be done in the .ami file, not as [External Model] in the IBIS file. Walter From: Taranjit Kukal [mailto:kukal@xxxxxxxxxxx] Sent: Thursday, January 20, 2011 1:42 AM To: wkatz@xxxxxxxxxx; 'IBIS-ATM' Subject: RE: [ibis-macro] Re: BIRD-124: Dependency tables - question? Thanks for detailed explanation Walter I understand that we need different IO-driver-strength models corresponding to different AMI-dll parameter settings; and I am not contesting that - (I also understand that v-i/v-t model has limitations) My concern is on the way we are building this dependency - the whole use-flow becomes round-robin. I start with IBIS-model1 -> This gives me a pointer to AMI-model -> Tool reads .ami settings and then picks IBIS-model2 for characterization - this seems ODD. We should come out with a better use-model so that it is clean/straight-forward and scalable. Top of my head, I see following ways: 1. Keep different ami files (with different settings) for different IBIS-models - so same dll but different ami files (Enhance the AMI section to allow different names of ami files) 2. Move AMI section out of IBIS-model and bring to a MODEL SELECTOR level - and let dependency tables work to pick the model... [Model Selector] iobuf_hss [AMI SECTION HERE] iobuf34_hss iobuf34 iobuf40_hss iobuf40 iobuf48_hss iobuf48 3. Use combination of 1) and 2) and get rid of dependency tables (I prefer this :) ) [Model Selector] iobuf_hss [AMI SECTION HERE pointing to only dll and not ami-file] iobuf34_hss iobuf34 <ami_file1> iobuf40_hss iobuf40 <ami_file2> iobuf48_hss iobuf48 <ami_file3> My 2 cents... rgds ..kukal _____ From: Walter Katz [mailto:wkatz@xxxxxxxxxx] Sent: Wednesday, January 19, 2011 7:25 PM To: Taranjit Kukal; 'IBIS-ATM' Subject: RE: [ibis-macro] Re: BIRD-124: Dependency tables - question? Kukal, There are two fundamental things going on here. First, IBIS fundamentally does not have the ability to represent broadband differential drivers or receivers. More important to your question is the fact that SerDes drivers (and to a lesser extent receivers), are configurable. They contain registers that control equalization, strength and drive impedance. Each configuration of the buffer, particularly when modifying the strength of the Tx, changes the impedance (i/v) of the buffer. There are two choices, the first is to use a model selector and a large number of IBIS models, each one pointing to a different .ami file configuration. This become rapidly unwieldy, and uses v-i/v-t models that are demonstrably inaccurate for SerDes AMI buffers. So it is only natural that when the buffer programming (as defined in the .ami file) is chosen, the .ami file must determine the analog model that the EDA tool must use to determine the impulse response of the channel. Opal, and BIRD 122 describe a simple parameterized generic buffer model that does a sufficient job of describing many SerDes Tx and Rx buffer analog models. The broadband (Touchstone) buffer model, an alternative option described in Opal and BIRD 122 is a more accurate representation of SerDes Tx and Rx buffer analog models. BIRD 124 is a method that we and several IC Vendors came up with that documents to the EDA tool how the Touchstone file, or the values of the parameters that control the generic buffer model. The short answer is that the selection of values of .ami parameters determine the analog model that the EDA tools needs to use to generate the impulse response of the channel. This is uncontested, and accepted by the IBIS-ATM committee. If you believe your tool can give more accurate results using (IBIS v-i/v-t model) then BIRD 124 allows you to do that by letting you use the reserved dependency table "In" or "Independent" parameter [Model]. A simple example is a Tx model that had an AMI parameter "Strength" that has 128 allowed values (0:127). IBIS file can have a model selector for this Tx buffer with [Model] Tx_0 to Tx_127. The dependency table would have two columns [Model} and Strength. The user can select a specific [Model] (e.g. Tx_107), and the dependency table would map that into Strength 107. BIRD 124 does support his flow, but we very much do not recommend it because the (IBIS v-i/v-t model) has been proven to be an inaccurate representation of high speed SerDes devices. Walter From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Taranjit Kukal Sent: Tuesday, January 18, 2011 10:57 PM To: wkatz@xxxxxxxxxx; 'IBIS-ATM' Subject: [ibis-macro] Re: BIRD-124: Dependency tables - question? Hi Walter, I am confused here. The parent is the IBIS model and has a pointer to AMI dll (Child) - the association is fixed - so how can AMI dll decide the analog-IO model that needs to be picked. Please explain with an example/flow-steps on how the analog model (IBIS v-i/v-t model) would be registered. rgds ..kukal _____ From: Walter Katz [mailto:wkatz@xxxxxxxxxx] Sent: Monday, January 17, 2011 8:26 PM To: Taranjit Kukal; 'IBIS-ATM' Subject: RE: [ibis-macro] Re: BIRD-124: Dependency tables - question? Kukal, Your first sentence is not correct, it should have said: "Looks like the Intent is to associate Analog IO model (different IO-model strengths) to AMI-parameter so that correct Analog IO-model is picked when s specific portion of AMI-code gets executed." Point being that the user configures the registers in a model, and that the registers in the model not only determine how the algorithmic model works but also determine the analog model needed to generate the impulse response of the channel for the algorithmic simulation. Walter From: Taranjit Kukal [mailto:kukal@xxxxxxxxxxx] Sent: Monday, January 17, 2011 9:17 AM To: wkatz@xxxxxxxxxx; 'IBIS-ATM' Subject: RE: [ibis-macro] Re: BIRD-124: Dependency tables - question? Hi Walter, Help me understand this further. Looks like the Intent is to associate Analog IO model (different IO-model strengths) to AMI-parameter so that correct portion of AMI-code gets executed according to Analog IO-model that is picked. However, what I fail to understand is that how this association gets utilized. If the user has to manually set a Key-parameter as per the IBIS buffer-strength to allow picking of dependent parameters then why are not let ami-code do it (Let tables be coded inside of AMI dll). To me, it looks like "Good to have" rather than a real need. Please explain with small example if I am missing the point. rgds ..kukal _____ From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz Sent: Thursday, January 13, 2011 8:32 PM To: Taranjit Kukal; 'IBIS-ATM' Subject: [ibis-macro] Re: BIRD-124: Dependency tables - question? Kukai, The impulse response of the channel must be determined before the AMI DLL is called. The AMI file contains the switches that program the Tx or Rx model. The value of these switches determine the analog model of the driver that is required to determine the impulse response of the channel. Walter From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Taranjit Kukal Sent: Thursday, January 13, 2011 2:11 AM To: IBIS-ATM Subject: [ibis-macro] BIRD-124: Dependency tables - question? Hi, The dependency tables would be useful only if we want to keep same AMI-code (dll) and just change the dependency outside of the code using .ami file. However, I do not see this as common use-model - I would assume that all such dependency should be handled inside of c-code (Algorithmic...) and that we should avoid overloading of .ami file such tables. AMI-code should be able to handle such dependency by coding the right values for dependent parameters based on Key parameters in ami file. Please let me know if I am missing a use-case where this cannot be handled inside the dll. rgds ..kukal Taranjit Kukal | Product Engineering Architect P: 91 120 3984000 <http://www.cadence.com/> www.cadence.com