Arpad- I agree that the spec should spell out all the points you mention. Mike S. Muranyi, Arpad wrote:
Mike, Kumar, Thanks for your replies. Even if we don't change how the AMI interface works regarding the clock_times vector memory allocation, I think we should explain it better in the next version of the spec (in the AMI BIRD Walter is writing). The problem I see with the current wording is that the spec doesn't spell out the rules and actions clearly, and because of that we can run into situations where things can fail or crash... 1) The spec should say that the EDA tool must initialize the vector with -1 (at least in the first location or the whole vector). 2) Depending on how this was done, he spec should say something about what the DLL is expected to do. If the EDA tool initialized the whole vector to -1, the DLL doesn't have to do anything. But if the EDA tool puts a -1 in the first location only, than the DLL will have to write a -1 at the end. 3) The spec should spell out that the DLL is not required to fill the vector if it doesn't have clock recovery. 4) If we don't say that the EDA tool must initialize the vector than the DLL should be required to write a -1 in the first location (at least) of this vector to tell the EDA tool that the vector is empty, even if it is a Tx DLL or an Rx DLL without a clock recovery. If we don't spell these rules out, we can end up with an uninitialized vector with no -1 retuned by a DLL. What is the EDA tool going to do with that? Can't decide whether the content is garbage, or good data... Arpad ====================================================================== -----Original Message-----From: Mike Steinberger [mailto:msteinb@xxxxxxxxxx] Sent: Thursday, January 28, 2010 10:06 AMTo: Muranyi, Arpad Cc: IBIS-ATM Subject: Re: [ibis-macro] Re: Question about clock_times Arpad- I think Kumar's done a perfectly adequate job of covering the subject. I don't see any improvement in going beyond what he's already said. As far as memory consumption goes, consider: 1. How much memory are we talking about anyway? block_size*8 bytes.2. How big is a typical block? 1k? 10k? So maybe we're talking about 100kB of memory.3. How long does this memory have to stay allocated? The duration of theGetWave call plus a little bit of post processing in the function that called it. I don't see the clock_ticks array as a very good candidate for optimization. Again, Kumar's solution is good enough.Mike S. Muranyi, Arpad wrote:The point I was trying to make is that if the EDA tool initializes the entire vector with -1, then the DLL doesn't have to put a -1 at the end, because it is there already by default. The DLL can just write data and stop, and the next value will be -1 anyway. Of course if we don't require for the EDA tool to initialize the entire vector with -1, then the DLL should put the -1 at the end. Either way, the spec should say something about the EDA tool having to initialize this vector one way or another, since it appears that there may be situations when the DLL doesn't write anything to it, not even a -1... Regarding #2, I can see your point about simplifying the rules for the API, but I think this can waste a lot of memory, especially if clock_times length = wave length. If we were able to make other arguments optional, like AMI_parameters_out, why can't we figure out a way to make this one optional, or at least say something about the fact that for Tx, for example, it is not necessary to allocate a huge amount of memory, only enough for a single number containing a -1... Arpad ==================================================================== -----Original Message-----From: ckumar@xxxxxxxxxxx [mailto:ckumar@xxxxxxxxxxx] Sent: Thursday, January 28, 2010 8:58 AMTo: Muranyi, Arpad Subject: Re: [ibis-macro] Re: Question about clock_times 1."putting the value at the end" is required only if he dll sendsclockback. If it is not c=doing anything with the clock it does not even need to look at it. 2. This is mainly done to simplify the API. Rule of thumb is youshoudlkeep th API to minimum for documentation and programming simplicity. If it is optional then we have to create another API without clock. Quoting "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>:Kumar, Thanks for the answers. If everyone agrees to what you said, then I would suggest to write this into the specification. #1) The spec doesn't say anywhere that this is supposed to be done by the EDA tool, it only says: "The last clock is indicated by putting avalue| of -1 at the end of clocks for the current wave sample. Theclock_time| vector is allocated by the EDA platform and is guaranteed to be greater | than the number of clocks expected during the AMI_GetWave call." If the EDA tool initializes the vector with a -1, the DLL wouldn'thaveto do anything about that, so we wouldn't need to say: "by putting a value of -1 at the end" because it would be therealready.On the other hand, we should add "The clock_time vector is allocatedbythe EDA platform AND INITIALIZED WITH -1 at least in the first location..." or something like that... #2 If this vector is not needed for the Tx, shouldn't clock_times be optional (like AMI_parameters_out, for example)? Currently it is required... I find it a little confusing to have something required when it is not used in half the cases. It makes me wonder what am I missing that it is required for... Thanks, Arpad============================================================================== -----Original Message----- From: ckumar@xxxxxxxxxxx [mailto:ckumar@xxxxxxxxxxx] Sent: Thursday, January 28, 2010 5:47 AM To: Muranyi, Arpad Subject: Re: [ibis-macro] Re: Question about clock_times Arpad: 1. The EDA tool allocates the clock memory and initializes that witha-1. If the Rx does not have a CDR, it will not modify this vector 2. For the Tx , whether the clock vector exists or not is irrelevant.Itshould not be doing anything to that vector. (like logical don't care state) 3. clock length = wave length is a robust way of memory allocation.Itis much more important to be robust than worry about 'efficiency' of memory allocation Quoting "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>:A related question: Is an Rx DLL required to fill the clock_times memory with good numbers, i.e. does it have to have a clock recovery, or is even an Rx allowed to basically not return anything useful? Related to this, are the Tx and Rx DLL-s required to put a -1 in the first location of the clock_times memory space if they do not have anything to return, or is the EDA tool supposed to initialize the allocated memory so that at least the first location would have a -1? Thanks, Arpad ======================================================= ________________________________ From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Wednesday, January 27, 2010 11:44 PM To: IBIS-ATM Subject: [ibis-macro] Question about clock_times Hello AMI experts, I just noticed something in the AMI portion of the official IBIS v5 specification. Section 3.2.2.3 clock_times is not labeled as optional, yet the text implies that this is only applicable to Rx models. Note the words "clock recovery loop" towards the end: | 3.2.2.3 clock_times | | Vector to return clock times. The clock times are referenced tothestart | of the simulation (the first AMI_GetWave call). The time is always | greater or equal to zero. The last clock is indicated by putting a value | of -1 at the end of clocks for the current wave sample. Theclock_time| vector is allocated by the EDA platform and is guaranteed to be greater | than the number of clocks expected during the AMI_GetWave call.Theclock | times are the times at which clock signal at the output of theclock| recovery loop crosses the logic threshold. It is to be assumedthatthe | input data signal is sampled at exactly one half clock periodaftera| clock time. A Tx model would not have a clock recovery loop, so I would thinkthata Tx GetWave function would not return anything in clock_times. IstheEDA tool still required to allocate memory for clock_times even forTx?Also note that the spec doesn't spell out exactly how much memorytheEDA tool needs to allocate, only that it should be "greater than thenumberof clocks expected". Since we have seen crashes due to a DLLwantingtowrite more clock_times than what we "expected" from it, and thesafestthing to do would be to allocate as much memory as the number of simulated bits, this seems to be quite a waste if we had to allocate the same amount of memory to a Tx model's clock_times also... Isn't there a better way of doing this? Thanks, Arpad=============================================================================--------------------------------------------------------------------- IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/ IBIS Macro reflector: //www.freelists.org/list/ibis-macro To unsubscribe send an email: To: ibis-macro-request@xxxxxxxxxxxxx Subject: unsubscribe--------------------------------------------------------------------- IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/ IBIS Macro reflector: //www.freelists.org/list/ibis-macro To unsubscribe send an email: To: ibis-macro-request@xxxxxxxxxxxxx Subject: unsubscribe--------------------------------------------------------------------- IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/ IBIS Macro reflector: //www.freelists.org/list/ibis-macro To unsubscribe send an email: To: ibis-macro-request@xxxxxxxxxxxxx Subject: unsubscribe
--------------------------------------------------------------------- IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/ IBIS Macro reflector: //www.freelists.org/list/ibis-macro To unsubscribe send an email: To: ibis-macro-request@xxxxxxxxxxxxx Subject: unsubscribe