All, Things are getting more and more interesting as the replies come in... First, let me press the reset button because the notations I see are getting a bit confusing. Walter uses "na" by which I suppose he means something like uninitialized memory or garbage. In my original question I used "#" to indicate a valid usable number, I just didn't want to specifically write improvised numbers there. It seems that others may have interpreted this differently in the discussion, so I just wanted to mention this to be sure we are in agreement. The other thing that was not mentioned in this discussion yet is the indexing of the retuned values from GetWave. So is the GetWave function supposed to put the numbers to the beginning of the vector FOR EACH CALL, or keep track of where the previous GetWave call finished in memory and continue from there on? The reason I am asking this is because Walter's last reply indicates the GetWave function supposed to return a -1 at the end of each call. In my mind this may imply that the EDA tool supposed to assemble the returned short vectors into a single long continuous vector which doesn't have a -1 between the chunks that it was assembled from, which doesn't seem to be mentioned in the spec and was not my understanding at all. In this illustration I am shortening the GetWave call length to 5 so I can fit the example on a line better (if it gets garbled with new lines by the mail system I will try again in a different way). memory index: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 call 1 value: 0 10p 20p 30p 40p -1 call 2 value: 50p 60p 70p 80p 90p -1 call 3 value: 100p 110p 120p 130p 140p -1 call 4 value: 150p 160p 170p 180p 190p -1 memory index: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 call 1 value: 0 10p 20p 30p 40p -1 call 2 value: 50p 60p 70p 80p -1 call 3 value: 90p 100p 110p 120p 130p 140p -1 call 4 value: 150p 160p 170p 180p 190p 200p -1 memory index: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 call 1 value: 0 10p 20p 30p 40p -1 call 2 value: 50p 60p 70p 80p 90p -1 call 3 value: 100p 110p 120p 130p 140p -1 call 4 value: 150p 160p 170p 180p 190p 200p -1 memory index: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 call 1 value: 0 10p 20p 30p 40p call 2 value: 50p 60p 70p 80p 90p call 3 value: 100p 110p 120p 130p 140p call 4 value: 150p 160p 170p 180p 190p 200p -1 My understanding was this last example. I even remember some discussions on how much memory the EDA tool was supposed to allocate fir this vector and the answers I received then was that the safest amount is the length of the entire waveform. If each GetWave call would return the values starting at index 0 we wouldn't need to allocate that much memory. Also, in this case I don't see why each GetWave call would need to return a -1 at its end except for the last one. Any comments? Thanks, Arpad ================================================================== ________________________________ From: Walter Katz [mailto:wkatz@xxxxxxxxxx] Sent: Sunday, March 28, 2010 10:04 AM To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx Subject: RE: [ibis-macro] Re: FW: Question on clock_times Arpad, The following two cases are valid: CASE 1: After the 1-st call: 0 1 2 3 4 5 6 7 8 9 -1 na na na ... After the 2-nd call: 10 11 12 13 14 15 16 17 18 19 -1 na na na ... After the 3-rd call: 20 21 22 23 24 25 26 27 28 29 -1 na na na ... etc. CASE 2: After the 1-st call: -1 # # # # # # # # # # // First call does not generate clocks After the 2-nd call: 0 1 2 3 4 5 6 7 8 9 -1 After the 3-rd call: 10 11 12 13 14 15 16 17 18 19 -1 // time increment continued from the last call Each call to GetWave returns an array of clock times terminated by a single -1. The data after the -1 is undefined, and can be anything (including -1's). Any individual call to GetWave can return a -1 in the first element of the array if either GetWave does not return clock ticks at all, or if there were no clock ticks during that call to GetWave. The later is possible but very highly unlikely. It is also required that the times of the clock ticks monotonically increase and always reference the time from 0, the beginning of the simulation. Walter Walter Katz 303.449-2308 Mobile 720.333-1107 wkatz@xxxxxxxxxx www.sisoft.com -----Original Message----- From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]On Behalf Of Muranyi, Arpad Sent: Sunday, March 28, 2010 10:46 AM To: ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Re: FW: Question on clock_times Todd, Now you really confused me. In your previous email you said: "Surprisingly - all three of Vladimir's cases are technically valid, according to the way the current spec is written. Clearly, cases 2 and 3 don't make sense (for different reasons), but there's nothing in the current spec that says they're wrong." Now you write: "We've always taken that to mean that clock times maintain a constant time zero reference across Getwave calls (i.e. not referenced to the start of the block)." The reason this confuses me is because all three cases from Vladimir include a "-1" at the end of each GetWave call's clock_time vector. If there is only a single time zero reference across all GetWave calls, shouldn't there be a single "-1" at the end of the very last GetWave call? So putting this all together, it seems that only the first case would be correct, but even that only if we took out the extra "-1"-s like this: CASE 1: After the 1-st call: 0 1 2 3 4 5 6 7 8 9 After the 2-nd call: 10 11 12 13 14 15 16 17 18 19 After the 3-rd call: 20 21 22 23 24 25 26 27 28 29 -1 etc. Thanks, Arpad ====================================================================== ________________________________ From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff Sent: Friday, March 26, 2010 4:41 PM To: ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Re: FW: Question on clock_times Scott, | 3.2.2.3 clock_times | =================== | | Vector to return clock times. The clock times are referenced to the start | 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. The clock_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. The clock | times are the times at which clock signal at the output of the clock | recovery loop crosses the logic threshold. It is to be assumed that the | input data signal is sampled at exactly one half clock period after a | clock time. We've always taken the phrase: | Vector to return clock times. The clock times are referenced to the start | of the simulation (the first AMI_GetWave call). We've always taken that to mean that clock times maintain a constant time zero reference across Getwave calls (i.e. not referenced to the start of the block). You can argue that isn't stated explicitly enough, but that's my understanding. Suggestions on wording to make things clearer are welcome and appreciated. Todd. ________________________ Todd Westerhoff VP, Software Products SiSoft 6 Clock Tower Place, Suite 250 Maynard, MA 01754 (978) 461-0449 x24 twesterh@xxxxxxxxxx www.sisoft.com ________________________________ From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Scott McMorrow Sent: Friday, March 26, 2010 5:34 PM To: Wenyi.Jin@xxxxxxx Cc: vladimir_dmitriev-zdorov@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Re: FW: Question on clock_times The specification is not clear concerning the meaning of the clock_times vector. I see two valid interpretations: * Clock_times are relative to the start of the current block * clock_times are relative to the start of the 1st block I do not see this defined in the specification. If it is, then please point me to the section. -- Scott McMorrow Teraspeed Consulting Group LLC 121 North River Drive Narragansett, RI 02882 (401) 284-1827 Business (401) 284-1840 Fax http://www.teraspeed.com Teraspeed(r) is the registered service mark of Teraspeed Consulting Group LLC Jin, Wenyi wrote: for CASE 2 and CASE 3, how can clock_time begin from 0? It is already 2nd block. If some call generate valid clock_time, some not, that means DLL has to track the information like block number to decide from which block begin return clock time. DLL can always return clock time even CDR is in lock-in stage, it is the EDA tool that Specified after how many UI or block, to make use of clock_time. From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Dmitriev-Zdorov, Vladimir Sent: Friday, March 26, 2010 2:08 PM To: ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Re: FW: Question on clock_times Please clarify if the following clock time patterns are legitimate when performing several GetWave calls (for simplicity/brevity, let's assume that we have only 10 bits per call and will use integers instead of small double values). Which of the following 3 cases are allowed? CASE 1: After the 1-st call: 0 1 2 3 4 5 6 7 8 9 -1 After the 2-nd call: 10 11 12 13 14 15 16 17 18 19 -1 After the 3-rd call: 20 21 22 23 24 25 26 27 28 29 -1 etc. CASE 2: After the 1-st call: -1 # # # # # # # # # # // First call does not generate clocks After the 2-nd call: 0 1 2 3 4 5 6 7 8 9 -1 After the 3-rd call: 10 11 12 13 14 15 16 17 18 19 -1 // time increment continued from the last call etc. CASE 3: After the 1-st call: -1 # # # # # # # # # # After the 2-nd call: 0 1 2 3 4 5 6 7 8 9 -1 After the 3-rd call: 0 1 2 3 4 5 6 7 8 9 -1 // i.e. always start from zero etc. -----Original Message----- From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Friday, March 26, 2010 2:38 PM To: ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] FW: Question on clock_times Kumar, So are you saying that the vector can begin with a bunch of -1 and then have valid number later in the vector? Lie this: -1 -1 -1 -1 # # # # # # # # -1 -1 -1 -1 If this is true, is it also true that you can have alternating -1 and good values in the vector? Like this? -1 -1 -1 -1 # # # # # # # # -1 -1 -1 -1 -1 -1 -1 -1 # # # # # # # # -1 -1 -1 -1 Arpad ============================================== ________________________________ From: C. Kumar [mailto:kumarchi@xxxxxxxxx] Sent: Friday, March 26, 2010 3:29 PM To: Muranyi, Arpad Subject: Re: [ibis-macro] Question on clock_times arpad: let me take shot at this 1. Yes -1 indicates end of clock vector 2. clock vector is the clocks associated with the particular wave vector in the particular getwave call. 3. some models can have delayed start for returning a clock vector. Once a legitimate clock vector is returned , the eda tool is expected to use that information to sample the wave returned by the getwave call. Other wise the eda tool may rely on its own devices to sample the wave, (usually this is an 'ideal' clock) 4. some models may modify the wave form but may never return a clock vector. (i.e -1 in the first position) ________________________________ From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx> <mailto:Arpad_Muranyi@xxxxxxxxxx> To: ibis-macro@xxxxxxxxxxxxx Sent: Fri, March 26, 2010 4:08:16 PM Subject: [ibis-macro] Question on clock_times Hello AMI experts, I would like to ask a question about the clock_times vector. The spec says that "The last clock in indicated by putting a value of -1 at the and of clocks for the current wave sample". We got a DLL from a vendor which seems to fill the vector for the first few GetWave calls with -1 and then it starts filling it with good numbers. What is the interpretation of the specification? First, does the above text refer to the entire vector, or each little section independently that a single GetWave call returns? If it is for the entire vector, then having -1 in the first few thousand locations would mean that everything else after that is garbage, correct? If it is per GetWave call, is the EDA tool expected to assemble something from bits and pieces that are returned by the various GetWave calls? 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 -- Scott McMorrow Teraspeed Consulting Group LLC 121 North River Drive Narragansett, RI 02882 (401) 284-1827 Business (401) 284-1840 Fax http://www.teraspeed.com Teraspeed(r) is the registered service mark of Teraspeed Consulting Group LLC