Todd, I can see all these reasons, but I want to make sure everyone else understands the differences, and agrees with it too. Also, how are we going to do correlation with measurements, if we can't generate an Rx pad waveform? Or, are you saying that for that purpose we would have to select a different value for "Use_Init_Ouput" and redo the simulation? Arpad =================================================== -----Original Message----- From: ibis-macro-bounce@freelists.org [mailto:ibis-macro-bounce@freelists.org] On Behalf Of Todd Westerhoff Sent: Sunday, April 06, 2008 3:26 PM To: ibis@eda.org; 'IBIS-ATM' Subject: [ibis-macro] Re: BIRD107: Update to Algorithmic Modeling API (AMI) Support in IBIS Arpad, The flow Tx Init -> Tx GetWave -> Rx Init -> Rx GetWave Was what I was thinking last Thursday when I modified the BIRD text. I don't think it works, though. In the flow above, you'd need to take the output of Tx_Init and convolve it with b(t) x p(t) before presenting it to Tx_Getwave. You can't present the result to Rx_Init, because Rx_Init only knows how to process impulse responses, and you've already got a waveform that needs to be processed in blocks. Slide 3 in the DesignCon presentation (and slide 5 in last Tuesday's, which was lifted directly from a Dec 2006 presentation) were both developed before we realized that the model maker needed to be able to specify the desired relationship between AMI_Init and AMI_Getwave calls. What's now clear in retrospect is that Cadence thought Use_Init_Output would _always_ be True, and SiSoft thought Use_Init_Output would _always_ be False. We each thought there was only one way models would be developed and used, we each thought everyone saw it the same way we did, and we each believed different things. It made for some interesting conversations when we tried to sort out differences in simulation results. What's become clear that there are two equally valid ways to develop a model with both AMI_Init and AMI_Getwave outputs, and that the model maker needs to be able to declare how the model should be used. That's exactly why we introduced the new Reserved_Parameter Use_Init_Output, and expanded the terminology for TX and RX equalization to differentiate between filtering applied by the AMI_Init and AMI_Getwave calls (last Tuesday's presentation, page 7). I now believe the reference flow Channel Response -> Tx_Init -> RX_Init -> x Stimulus -> Tx_Getwave -> Rx_Getwave Is the one we need to speak to. There are probably other ways to run the models and get equivalent results, and that's fine ... we just document that the results of any other flow should match the results from the reference flow. Make sense? Todd. Todd Westerhoff VP, Software Products SiSoft 6 Clock Tower Place, Suite 250 Maynard, MA 01754 (978) 461-0449 x24 twesterh@sisoft.com www.sisoft.com -----Original Message----- From: ibis-macro-bounce@freelists.org [mailto:ibis-macro-bounce@freelists.org] On Behalf Of Muranyi, Arpad Sent: Sunday, April 06, 2008 5:24 PM To: ibis@eda.org; IBIS-ATM Subject: [ibis-macro] Re: BIRD107: Update to Algorithmic Modeling API (AMI) Support in IBIS Todd, Thanks for the explanation. I think the flow you outlined below eliminates the double courting problem. However, I don't think any of us had this understanding of the flow before. I think previous to this discussion we all thought that the output of Tx GetWave was the "waveform at the Rx pad", as shown on pg. 5 in the 3rd bullet of your last Tuesday's presentation: http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20080401/toddwesterh off/IBIS-AMI%20Correlation%20and%20BIRD%20Update/IBIS_ATM_BIRD_Update_04 0108.pdf and on pg. 3 in your DesignCon presentation: http://www.vhdl.org/pub/ibis/summits/feb08/westerhoff.pdf With the flow you outlined below the output of Tx GetWave includes the Rx equalization, which changes the meaning of the waveform at the output of Tx GetWave from "Rx pad" to something like "Rx on the die after the EQ". I understand that this can be changed back to its original meaning IF we use the appropriate value for "Use_Init_Ouput" to suppress the Rx equalization in the Tx GetWave input, but is this not going to have any other side effects? I think having a flow of Tx Init -> Tx GetWave -> Rx Init -> Rx GetWave may be more appropriate, but I haven't given it enough thinking time yet to see all the details and consequences of this flow, especially considering the double counting problem and the newly proposed Boolean variable's effects... I am concerned that the flow you outlined below is not what we had in mind when we wrote the original BIRD, and I think this must be handled cautiously, but most importantly even if we agree to this, we MUST spell it out in the spec very clearly. Arpad ================================================================= -----Original Message----- From: ibis-macro-bounce@freelists.org [mailto:ibis-macro-bounce@freelists.org] On Behalf Of Todd Westerhoff Sent: Sunday, April 06, 2008 10:09 AM To: ibis@eda.org; 'IBIS-ATM' Subject: [ibis-macro] Re: BIRD107: Update to Algorithmic Modeling API (AMI) Support in IBIS Arpad, This is a really good question. Let me start by outlining the "Use_Init_Output" reference flow as I understand it. In this flow Use_Init_Output is True for both the TX and RX devices: 1. Simulation platform prepares hcr(t) 2. hcr(t) -> tx_init -> hcr(t) x htei(t) 3. hcr(t) x htei(t) -> rx_init -> hcr(t) x htei(t) x hrei(t) 4. hcr(t) x htei(t) x hrei(t) -> simulation platform -> hcr(t) x htei(t) x hrei(t) x b(t) x p(t) 5. hcr(t) x htei(t) x hrei(t) x b(t) x p(t) -> tx_getwave -> hcr(t) x htei(t) x hrei(t) x b(t) x p(t) x hteg(t) 6. hcr(t) x htei(t) x hrei(t) x b(t) x p(t) hteg(x) -> rx_getwave -> hcr(t) x htei(t) x hrei(t) x b(t) x p(t) x hteg(t) x hreg(t) The steps in this flow are chained, and the input of steps 2-6 is the output of the step that preceded it. When "Use_Init_Output" is False, the corresponding init step in the chain still gets run, but any filtered data produced by that step isn't passed on - the input to that step is passed on instead. For example, if Use_Input_Output was False for the TX, the output for step 2 would be discarded, and hcr(t) would be passed to step 3 instead (this is the language I changed in BIRD 107 last Thursday because I didn't have a clear understanding of the reference flow). While it's true that the order of convolution of LTI elements doesn't matter, are side issues that can crop up here. For example, consider the case of a model with RX_Init and RX_Getwave that uses RX_Init to "preset" DFE tap parameters for the start of RX_Getwave (something I refer to as "warm-starting" the DFE taps). Thus, the impulse response you pass to RX_Init should have the effects of TX_Init included (i.e. you don't want to change the order of steps 2 and 3, even though you'd theoretically get the same output). There's a flaw in the above argument when the TX doesn't return an equalized impulse response from Init. Even if you use the reference flow, RX_init will try to preset based on the wrong impulse response. While I don't expect this scenario will be common (TX_Getwave but no output from TX_Init), the solution is this case is - either the user tells the RX model to "cold start" the tap parameters from zero, or just lives with the fact that the starting point isn't as well optimized as it could be. My conclusion is that the evaluation order of AMI models needs to be deterministic for the user to be able to manage the situation settings, and ensure consistent results across tools. Thus, we should spell out the reference flow above if everyone doesn't already understand it. I'm guessing everyone doesn't, and therefore we should include language to this effect in BIRD 107.1. I hope it goes without saying that the evaluation order of 5 and 6 can't be changed, because neither of these behaviors can be considered LTI. They might be, but it's not guaranteed. Is my explanation clear here, and do you agree with this? Thanks, Todd. Todd Westerhoff VP, Software Products SiSoft 6 Clock Tower Place, Suite 250 Maynard, MA 01754 (978) 461-0449 x24 twesterh@sisoft.com www.sisoft.com --------------------------------------------------------------------- IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/ IBIS Macro reflector: http://www.freelists.org/list/ibis-macro To unsubscribe send an email: To: ibis-macro-request@freelists.org Subject: unsubscribe --------------------------------------------------------------------- IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/ IBIS Macro reflector: http://www.freelists.org/list/ibis-macro To unsubscribe send an email: To: ibis-macro-request@freelists.org Subject: unsubscribe -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -------------------------------------------------------------------- |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org |with the appropriate command message(s) in the body: | | help | subscribe ibis <optional e-mail address, if different> | subscribe ibis-users <optional e-mail address, if different> | unsubscribe ibis <optional e-mail address, if different> | unsubscribe ibis-users <optional e-mail address, if different> | |or e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993Received on Sun Apr 6 15:52:08 2008
This archive was generated by hypermail 2.1.8 : Sun Apr 06 2008 - 15:52:23 PDT