Arpad and Radek, The fundamental issue with using Model_type Output for a redriver is that an output model requires a Pullup and a Pulldown curve. This contradicts directly with the behavior of the analog model of the redriver as it is merely a connector and transfers energy directly from the input to the output. Traditional Output model does not directly transfer energy from Input to Output and all the energy is from power or ground. It doesn’t matter if the stimulus to the Tx [Model] is the output of the Rx [Model] or the tool’s internal stimulus, if it is a traditional Output model, by definition, it will either pull up or pull down, defeating the purpose of the redriver. Of course, none of this is going to happen by design, but if we do not think about it now – and include something in the spec now – someone is going to try it and claim that something is broken. Regards, Ambrish. From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Monday, March 25, 2013 8:30 PM To: ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Re: redriver in spice simulation I tend to agree with Radek. In legacy simulations, the [Repeater Pin] keyword would simply associate a Tx (Output) and an Rx (Input) [Model] with each other so that the stimulus to the Tx (Output) [Model] is the output of the Rx (Input) [Model] instead of the tool’s internal stimulus. This is simple and easy to achieve. The only problem is that BIRD 131 doesn’t spell any of this out. Now that I am reading BIRD 131, I am noticing several other problems with it. 1) The “Statement of the issue” section is really not making a statement of an issue that we are solving with the BIRD. It contains a bunch of rules and/or assumptions which really should be under the Usage Rules if we intend them to be in the specification. I think these are important statements, and should be in the Usage Rules section, otherwise we will not know anything about these in the specification. 2) Some rules/requirements about pin names should also be spelled out in the Usage Rules, such as the pin names listed under this keyword must match pin names in the [Pin] keyword, and that no pin names are allowed under the [Repeater Pin] keyword which are not listed under [Pin]. The BIRD should also spell out what should happen when the [Model]s associated in the [Repeater Pin] keyword contain [Algorithmic Model]. For one, in that case both of the [Model]s should have the [Algorithmic Model] keyword. We should not allow only one or the other to have it, or if we do, then the Repeater Model should only work in legacy simulations(?). Also, we need to have words on how the [Algorithmic Model]s will be “connected” to each other, i.e. which GetWave output is the input to the other GetWave input, or which Init function gets the impulse response of the channel, in other words we need an AMI flow description for this case. I may be asking for a lot, but I think leaving it open to anyone’s own interpretation and implementation will only get us in trouble (and arguments) later on... Thanks, Arpad ==================================================================== From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of radek_biernacki@xxxxxxxxxxx Sent: Monday, March 25, 2013 6:07 PM To: ambrishv@xxxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Re: redriver in spice simulation Hi Ambrish, I am not sure whether it has any practical value or not, but I do not see any obstacles to simulate such models in non-AMI mode. That would be similar to simulating a single ended buffer for a [Pin] that also appears in the [Diff Pin] list. Radek From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ambrish Varma Sent: Monday, March 25, 2013 4:02 PM To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx> Subject: [ibis-macro] Re: redriver in spice simulation Hi Michael, We might have to go one step further. Currently, for an IBIS model with [Algorithmic Model]/[End Algorithmic Model] section, we can still use the models to simulate in an non-AMI mode. We will not be able to do that with a model with [Repeater Pin]. We might need: New Model_type for Repeaters (Repeater_Input, Repeater_Output ??) to accurately distinguish them from ‘regular’ I/O buffers. OR Specifically note somewhere that models used in [Repeater Pin] ‘Shall not be used for NON-AMI simulations’ Thanks, Ambrish. From: Mirmak, Michael [mailto:michael.mirmak@xxxxxxxxx] Sent: Monday, March 25, 2013 4:22 PM To: fangyi_rao@xxxxxxxxxxx<mailto:fangyi_rao@xxxxxxxxxxx>; Ambrish Varma; ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx> Subject: RE: [ibis-macro] Re: redriver in spice simulation Just a suggestion: it’s easier to loosen a specification than to tighten it. One simple possibility would be to add a line to BIRD131 that the [Algorithmic Model]/[End Algorithmic Model] keyword pair is required for any [Model] linked to a [Pin] number that appears under [Repeater Pin]. That would initially limit [Repeater Pin] to use with IBIS-AMI, and would be parsable, but that limitation could easily be removed in a future revision once non-IBIS-AMI support is more clear. I would argue that demand for repeater support for non-IBIS-AMI buffers is much smaller than demand for IBIS-AMI repeater support. - MM From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of fangyi_rao@xxxxxxxxxxx<mailto:fangyi_rao@xxxxxxxxxxx> Sent: Monday, March 25, 2013 9:02 AM To: ambrishv@xxxxxxxxxxx<mailto:ambrishv@xxxxxxxxxxx>; ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx> Subject: [ibis-macro] Re: redriver in spice simulation Ambrish; The problem is that BIRD131 has to answer the question of how a redriver model behave in non-AMI simulations, which what I try to avoid in my BIRD. Thanks, Fangyi From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ambrish Varma Sent: Friday, March 22, 2013 4:07 PM To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx> Subject: [ibis-macro] Re: redriver in spice simulation Fangyi, “If this proposal is strictly for AMI purposes, and the analog models are not designed to be used in non-AMI simulations in a redriver configuration, than the BIRD should state that. ” If this statement is true then there should be no issues with combining your version of the redriver BIRD with BIRD 131 – correct? I believe we should do that for the sake of a uniform, concise and meaningful discussion. Thanks, Ambrish. From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Monday, March 18, 2013 10:23 PM To: ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx> Subject: [ibis-macro] Re: redriver in spice simulation Fangyi, Thanks for the answers. 1) By “that” I was referring to “namely ignoring the connection between the Rx half and Tx half in SPICE/non-AMI”. If this proposal is strictly for AMI purposes, and the analog models are not designed to be used in non-AMI simulations in a redriver configuration, than the BIRD should state that. Otherwise we might have to answer questions like Ambish’s question every so often… 2) That’s an interesting point that I didn’t think of. The redriver’s Rx is a transmitter (Tx) for a link that might be tucked away between the redriver’s Rx and Tx blocks, and the redriver’s Tx might be a receiver (Rx) from that perspective. But the concept of having a channel inside the redriver is stretching the name of the redriver a little bit, and even though it is possible, I would keep the naming consistent with the primary purpose. But this is not what I was hung up on when I first commented on this. What bothered me the most is that people (you?) started to call blocks as “input” or “output” which to me meant a terminal into which a signal is going in or from where a signal is coming out. As a result, I started to read statements like “signal going into an output {terminal}”, which sounded like nonsense to me. Whatever we end up calling these repeater blocks, I would like to use names which can’t be shortened so that sentences could be grossly misinterpreted. 3) Please spell out the nature of the input to Tx GetWave. In the light of recent discussions I feel this would be important to have in the BIRD to eliminate any misinterpretations (and arguments) in the future. 4) Please try to work with Walter if possible on a common proposal so that the entire proposal/concept would be in one BIRD, and not sprinkled around in several BIRDs. Thanks, Arpad =============================================================================== From: fangyi_rao@xxxxxxxxxxx<mailto:fangyi_rao@xxxxxxxxxxx> [mailto:fangyi_rao@xxxxxxxxxxx] Sent: Monday, March 18, 2013 4:19 PM To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx> Subject: RE: [ibis-macro] Re: redriver in spice simulation Hi, Arpad; My answers are inserted. Regarding “So I tend to agree to Radek’s suggestion, namely ignoring the connection between the Rx half and Tx half in SPICE/non-AMI. But that’s beyond the scope of my BIRD.”, If that is the case, the BIRD should state that explicitly, and propose verbiage for the specification for a statement like that. But I am not sure how much of your BIRD text actually goes into the spec. Could you explain that? FR: what dose ‘that’ mean? I would suggest to change the words “input *** model” and “output *** model” to “receiver *** model” and “transmitter *** model” to eliminate possible confusions along the lines we just had in this thread. FR: It’s fine for me to use Rx/Tx instead of input/output, but I know there are people who would argue strongly against using Rx/Tx because in optical redriver models the first half actually transmits signal and the second half receives signal. Any suggestion for better terminology is welcome. Are you assuming that if the model is made for a redriver, the model maker will know that the Rx GetWave output should be (a +/- 0.5 V digital waveform) or make the Tx GetWave accept true analog waveforms? FR: Tx GetWave accepts continuous analog waveform. I can spell it out in the BIRD. Another question, which was also mentioned yesterday in the ATM meeting: If an .ibs file has multiple Rx and Tx AMI models, how would the simulator know which Rx goes with which Tx model? That’s addressed in Walter’s BIRD. Regards, Fangyi ==================================================================