[ibis-macro] Re: FW: Question on clock_times
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: <Arpad_Muranyi@xxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
- Date: Sun, 28 Mar 2010 11:04:18 -0400
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 <mailto:twesterh@xxxxxxxxxx>
www.sisoft.com <http://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
TeraspeedR 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> [
mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Dmitriev-Zdorov,
Vladimir
Sent: Friday, March 26, 2010 2:08 PM
To: ibis-macro@xxxxxxxxxxxxx <mailto: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> [
mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Friday, March 26, 2010 2:38 PM
To: ibis-macro@xxxxxxxxxxxxx <mailto: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 <mailto: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
<mailto: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
TeraspeedR is the registered service mark of
Teraspeed Consulting Group LLC
Other related posts:
