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 -----Original Message----- From: ibis-macro-bounce@freelists.org [mailto:ibis-macro-bounce@freelists.org] On Behalf Of Muranyi, Arpad Sent: Friday, April 04, 2008 3:51 PM To: ibis@eda.org; IBIS-ATM Subject: [ibis-macro] Re: BIRD107: Update to Algorithmic Modeling API (AMI) Support in IBIS Mike, You raised a bunch of VERY GOOD and VALID questions, most of which I haven't thought about before! I think they are very important topics and we should discuss them (or even mention them in the spec). However, I would like to return to Todd's posting (to which you replied), which brings up the order of execution question. ------------------------------------------------------------------- All, If we go with what was proposed on pg. 18 of the presentation discussed in the last ATM meeting, the EDA tool will convolve either the output of Init, OR the unmodified channel response with the input waveform for GetWave's input. (I know, Kumar is warning us not to say "convolved" because there may be other ways to do this, but for the sake of this discussion I will just use the word convolve). Note that neither the presentation, nor BIRD107 distinguishes between Tx GetWave or Rx GetWave, so I assume that the above has to be done for both (unless we change the words). If the channel response (modified or not) is present in the input of both Tx GetWave and Rx GetWave, aren't we double counting the channel response? Todd seemed to indicate that his execution order rule would take care of that but I don't see yet how. TX AMI_Init -> RX AMI_Init -> TX AMI_Getwave -> RX AMI_Getwave The order in which convolution is done on various data blocks doesn't change the outcome. We can only eliminate the double counting by eliminating the duplicate input of the channel response (or modified channel response) somewhere in the chain. So, is the above order of execution rule supposed to mean that because of that, one of the channel responses are dropped somewhere in the chain, meaning that the rules on pg. 18 are different for Tx GetWave and Rx GetWave regarding the usage of channel response? If that is what this means, we need to write separate rules for Tx and Rx GetWave. If the order of execution does something I don't understand yet, we need to write a specific section on that into our BIRD to describe it to those of us to whom this is not obvious... Arpad ================================================================== -----Original Message----- From: Mike LaBonte (milabont) [mailto:milabont@cisco.com] Sent: Friday, April 04, 2008 9:47 AM To: twesterh@sisoft.com; Muranyi, Arpad; ibis@eda.org; IBIS-ATM Subject: RE: [ibis-macro] Re: BIRD107: Update to Algorithmic Modeling API (AMI) Support in IBIS I remember the problems caused by C++ destructors that relied on each other, and were called in different order on different platforms in the early days of C++. On the theory that there could be multiple TXs in a simulation as well as multiple RXs, I would suggest specifying only: 1) All Init()s are called before all GetWave()s, which are called before all Close()s 2) Within each group (Init, GetWave, Close), no function shall be written in such a way that it depends on the order in which instances of the same group are called. 3) There *might* be an additional stipulation about interleaving GetWave() calls so that one instance is not called multiple times between calls to another instance. For example, TX GetWave() can't be called 100 times before RX GetWave() is called once. On the other hand if that is to be allowed it should be explicit. My opinion is that each model instance preferably should only use memory associated with the instance, not global "static" memory that could be shared among multiple instances. But even if they do, no call order should be assumed. For example, I don't think we should assume that TX Init() is called before RX Init(). Knowing that the call order among instances is indeterminate will warn people to create models that are safe no matter how memory is shared. Mike -----Original Message----- From: ibis-macro-bounce@freelists.org [mailto:ibis-macro-bounce@freelists.org] On Behalf Of Todd Westerhoff Sent: Friday, April 04, 2008 9:28 AM To: Arpad_Muranyi@mentor.com; ibis@eda.org; 'IBIS-ATM' Subject: [ibis-macro] Re: BIRD107: Update to Algorithmic Modeling API (AMI) Support in IBIS Arpad, I have given this one a lot of thought, and realized my changing the BIRD text was another one of those perspective things. I'm pressed for time at the moment, but wanted to get this one the wire before I have to jump into a meeting ... If we agree models get called in the following sequence: TX AMI_Init -> RX AMI_Init -> TX AMI_Getwave -> RX AMI_Getwave Then the original text was okay and I shouldn't have changed it. I had a different perspective that let me to think the text needed to be changed. I realized the perspective I had was based on a particular context, one that didn't really reflect how these models would be executed in an operating EDA platform. I can go into detail how I got to that point, but I don't think it matters. If everyone else expected the calling sequence I listed above, then we should just go back to the original text. This will have been case of the editor trying to solve a problem that didn't exist. My apologies for the confusion. 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 10:10:31 2008
This archive was generated by hypermail 2.1.8 : Sun Apr 06 2008 - 10:11:27 PDT