[ibis-macro] Re: FW: Question on clock_times

  • From: Scott McMorrow <scott@xxxxxxxxxxxxx>
  • To: Walter Katz <wkatz@xxxxxxxxxx>
  • Date: Sun, 28 Mar 2010 18:52:38 -0400

See below

Walter Katz wrote:

Scott,

With regard to 1, it is clear the PLL startup time should have been included with the equalization as the purpose for Ignore_Bits. I suspect there are or will be other causes that might contribute to Ignore_Bits as well.

If that is the case, then why would a model return a singular -1 in the clock_times vector, if it contains CDR?

With respect to 3, a clock may be out of very good lock but remain inside the eye. In this case BER will increase, the question is how far out of phase it will be to cause appreciable errors.

I agree, however, I like to be clear and differentiate the term "eye opening" from any discussion of BER. They are totally separate concepts.

Walter

Walter Katz

303.449-2308

Mobile 720.333-1107

wkatz@xxxxxxxxxx

www.sisoft.com

-----Original Message-----
*From:* Scott McMorrow [mailto:scott@xxxxxxxxxxxxx]
*Sent:* Sunday, March 28, 2010 4:09 PM
*To:* Walter Katz
*Cc:* Arpad_Muranyi@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
*Subject:* Re: [ibis-macro] Re: FW: Question on clock_times

Walter

See below.

Walter Katz wrote:

Scott,

1. This is one of the reasons for Ignore_Bits, which really should have been called Ignore_Time. Ignore_Bits tells the EDA tool that it should ignore the first <n>UI time before considering either the waveform or the clock ticks valid.

It seems to me that you are asking Ignore_Bits serve two independent purposes.

· The purpose stated in the specification, which is to identify the adaptive equalization startup time.

o                            |               Ignore_Bits is of usage Info and 
type Integer.  It tells the
o                            |               EDA platform how long the time 
variant model takes to complete
o                            |               initialization.  This parameter is 
meant for AMI_GetWave
o                            |               functions that model how 
equalization adapts to the input
o                            |               stream.  The value in this field 
tells the EDA platform how
o                            |               many bits of the AMI_Getwave 
output should be ignored.

· The purpose you just stated which is to filter out bits that are not valid during PLL startup.


I can make an argument that original writers of the AMI spec assumed that the clock is always locked, and that Ignore_bits rightly includes this lock time. This is not spelled out explicitly in the specification, but is reasonable. However, if this is the case, and a reasonable interpretation, then there would be clock ticks output , (just as waveform processing still occurs) as indicated by your response to the CDR out of lock question. At no point would there be a GetWave call that does not include clock ticks, unless that receiver does not have a clocked output. Otherwise, there is no reason to have Ignore_Bits. A GetWave call that does not output a clock tick, is by definition one where EDA platform processing is not valid. The Ignore_Bits functionality is then implemented by suppressing clock ticks, until the waveform is valid.


1.      I will defer to Mike Steinberger to answer this one.

2. If the CDR goes out of lock I believe the only choice is to output the modeled clock ticks. If the CDR goes out of lock, I would expect a closed eye, or at least a very high BER for the amount of time the clock is out of lock.

It is quite possible to drive a poorly designed CDR out of lock, while at the same time maintaining an open eye at the receiver. We see this all the time in real systems running at fairly low data rates, with simple receiver equalization schemes.


1.
Walter

Walter Katz

303.449-2308

Mobile 720.333-1107

wkatz@xxxxxxxxxx <mailto:wkatz@xxxxxxxxxx>

www.sisoft.com <http://www.sisoft.com>

-----Original Message-----
*From:* Scott McMorrow [mailto:scott@xxxxxxxxxxxxx]
*Sent:* Sunday, March 28, 2010 2:13 PM
*To:* wkatz@xxxxxxxxxx <mailto:wkatz@xxxxxxxxxx>
*Cc:* Arpad_Muranyi@xxxxxxxxxx <mailto:Arpad_Muranyi@xxxxxxxxxx>; ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx>
*Subject:* Re: [ibis-macro] Re: FW: Question on clock_times

I have several questions regarding clock ticks, Walter

Why would you say that it is "highly unlikely" that a clock tick does not occur during a getWave call? I'd think that the startup behavior of a PLL would be such that one would want to filter out the initial invalid clock ticks until the PLL has locked. The alternative would be to output the actual stream of garbage clock ticks produced by the CDR before lock occurs.

Assuming that it is perfectly valid for getWave to return -1 in the 1st position for both a device with a CDR and without a CDR, how is a device with CDR and one without CDR distinguished by the EDA platform?

What is the desired clock_ticks behavior if the CDR goes out of lock during waveform processing, considering that this is quite possible for cases where S/N is extremely low and/or noise/jitter pushes the device beyond compliance limits.

Output the modeled clock ticks

Output -1 until lock occurs



Walter Katz wrote:

Arpad,

The whole intent of multiple calls to GetWave is to break very long simulations into manageable chunks. A simulation might be 100 million bits long and be broken up into 100000 1000 bit chunks. The EDA tool need only allocate somewhat more than 1000 double precision numbers. The EDA tool re-uses the same 1000 word buffer on each call to GetWave. The --1 is the way the DLL tells the EDA tool how many clock tics were generated in this particular GetWave call. The EDA tool then assembles the waveform and clock tics into a very long 100 million-bit waveform. The EDA tool really does not keep the 100-million bit waveform in memory at once, but can, for example, build a statistical eye on the fly. The EDA tool allocates the memory. There is no requirement for the EDA tool to initialize the value of this memory.

Walter

Walter Katz

303.449-2308

Mobile 720.333-1107

wkatz@xxxxxxxxxx <mailto:wkatz@xxxxxxxxxx>

www.sisoft.com <http://www.sisoft.com>

-----Original Message-----
*From:* ibis-macro-bounce@xxxxxxxxxxxxx <mailto:ibis-macro-bounce@xxxxxxxxxxxxx> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]*On Behalf Of *Muranyi, Arpad
*Sent:* Sunday, March 28, 2010 1:07 PM
*To:* ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx>
*Subject:* [ibis-macro] Re: FW: Question on clock_times

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 <mailto: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 <mailto:wkatz@xxxxxxxxxx>

www.sisoft.com <http://www.sisoft.com>

-----Original Message-----
*From:* ibis-macro-bounce@xxxxxxxxxxxxx <mailto: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 <mailto: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> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] *On Behalf Of *Todd Westerhoff
*Sent:* Friday, March 26, 2010 4:41 PM
*To:* ibis-macro@xxxxxxxxxxxxx <mailto: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> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] *On Behalf Of *Scott McMorrow
*Sent:* Friday, March 26, 2010 5:34 PM
*To:* Wenyi.Jin@xxxxxxx <mailto:Wenyi.Jin@xxxxxxx>
*Cc:* vladimir_dmitriev-zdorov@xxxxxxxxxx <mailto:vladimir_dmitriev-zdorov@xxxxxxxxxx>; ibis-macro@xxxxxxxxxxxxx <mailto: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® 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 2^nd 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 Teraspeed® is the registered service mark of
Teraspeed Consulting Group LLC



--
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® is the registered service mark of
Teraspeed Consulting Group LLC



--
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® is the registered service mark of
Teraspeed Consulting Group LLC

--
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® is the registered service mark of
Teraspeed Consulting Group LLC

Other related posts: