[ibis-macro] Re: FW: Question on clock_times
- From: "Dmitriev-Zdorov, Vladimir" <vladimir_dmitriev-zdorov@xxxxxxxxxx>
- To: "Mike Steinberger" <msteinb@xxxxxxxxxx>
- Date: Mon, 29 Mar 2010 14:19:14 -0600
Mike,
My point was not about '-1's; in the model I mentioned they did not use
'-1' but simply provided a different number of new times atop of what
was lest in memory from the last call. That was a first example of
non-monotonic clocks, in reply to Todd's question.
The second was repeating clock times. For example, after the first call
with *5* bits in package we have:
0p 100p 200p 300p 400p 500p -> 6 values!
after the second we had:
500p 600p 700p 800p 900p 1000p -> 6 values
so on.
Regardless on having '-1', what is the correct interpretation of this
data? Are those two 500p values repeated boundaries or they should be
considered two distinct samples? Etc.
A few related questions:
- GetWave call accepts wave length as a parameter that is # of samples,
not bits. Was it an original thinking that if the number of bits in the
call is 'fractional', then we need one more clock tick to define the
upper limit for the incomplete bit?
- Assume however that we always call with N * pnt_per_bit samples. Can
the clock times lag or surpass the bits in the waveform? Is this
necessary - is the complication in the flow + extra errors in the models
that try to follow this worth the "flexibility"? To what extent this
speed difference may go and discrepancy accumulate over time? If lag is
just a few bits on average then it is easy to consider programmatically.
But we at least must know the limits to allocate memory for that. What
if this number reaches many thousands?
> I'm not suggesting that you haven't run into other problems; however,
I
believe we need to start with an example in which the specification was
actually followed.
Agree. The best would be to explicitly consider several valid scenarios
and to show what is and what is not allowed. Repeating clock times,
different number of clock from call to call, not generating clocks in
first several calls but then generating them, what else?
In every questionable case we need to provide explanation of how to
correctly interpret the data.
Vladimir
-----Original Message-----
From: Mike Steinberger [mailto:msteinb@xxxxxxxxxx]
Sent: Monday, March 29, 2010 1:36 PM
To: Dmitriev-Zdorov, Vladimir
Cc: Todd Westerhoff; scott@xxxxxxxxxxxxx; wkatz@xxxxxxxxxx; Muranyi,
Arpad; ibis-macro@xxxxxxxxxxxxx
Subject: Re: [ibis-macro] Re: FW: Question on clock_times
Vladimir-
I'm not understanding you. The first thing you say is that there was no
terminating -1 to the clock ticks array, and then you conclude that we
need some mechanism for knowing the number of valid clock ticks. The
terminating -1 is the mechanism for knowing how many valid clock ticks
there are in the array. Are you suggesting that because this model was
non--compliant and did not use the mechanism provided in the
specification, we need to change the specification?
I'm not suggesting that you haven't run into other problems; however, I
believe we need to start with an example in which the specification was
actually followed.
Thanks.
Mike S.
Dmitriev-Zdorov, Vladimir wrote:
> Todd,
>
> We saw that after one call (with say 1,000 bits apiece) we've got 1000
> meaningful clock times, where the last value was approximately tx =
> 999*Tbit. Then, after the next call we had 999 increasingly larger
clock
> times, but the 999-th remained unmodified in memory, so that the
> expected should be about 1,000*T-bits larger. No terminating '-1'.
> Technically, it is easy to detect non-monotonic behavior and stop
> reading the clocks, but this is not expected. With such output, the
> available interpretations are: bug in the DLL or CDR failure, or both.
>
> My suggestion would be to always have the # or meaningful clock time
> equal to the number of bits simulated with GetWave() call (or not
having
> them at all), otherwise, the flow becomes ambiguous and quite
difficult
> to follow. In some earlier discussions it was also allowed to have the
> n+1-th clock time repeated as the first value in the output of the new
> GetWave call. This would lead to another non-strict monotonic
behavior.
> How the tool would recognize if the last clock time is to be repeated
or
> GetWave simply produces more clock times than bits simulated in this
> particular call?
>
> Syntax is not enough, as was mostly the case with previous IBIS
> standards. In the past, IBIS file containing the model description did
> not "algorithmically" interact with EDA tools, but AMI models do. This
> requires more detailed definition for the correct flow. Not only the
> model/software should not crash, but we all should know what is
expected
> content of input/output to produce meaningful results.
>
> Vladimir
>
> -----Original Message-----
> From: Todd Westerhoff [mailto:twesterh@xxxxxxxxxx]
> Sent: Monday, March 29, 2010 11:32 AM
> To: Dmitriev-Zdorov, Vladimir
> Cc: scott@xxxxxxxxxxxxx; Mike Steinberger; wkatz@xxxxxxxxxx; Muranyi,
> Arpad; ibis-macro@xxxxxxxxxxxxx
> Subject: Re: [ibis-macro] Re: FW: Question on clock_times
>
> Vladimir,
>
> What do you mean by monotonicity issues with clock ticks? Do you the
> values of time don't continue to increase?
>
> 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
>
>
> On Mar 29, 2010, at 10:07 AM, "Dmitriev-Zdorov, Vladimir"
> <vladimir_dmitriev-zdorov@xxxxxxxxxx
> > wrote:
>
>
>> As a matter of fact, more than half of all AMI models that we have
>> seen
>> so far had more or less serious issues with clock ticks - way of
>> generation, consistency, monotonocity, unnecessary granulation making
>> them multiples of sample interval, etc.
>> This is an indication that we need to better specify what is the
right
>> unambiguous behavior, not just syntaxically correct but the one that
>> allows model creator to reach their simulation goal provided that
they
>> (and EDA tool) comply with the standard
>>
>> -----Original Message-----
>> From: ibis-macro-bounce@xxxxxxxxxxxxx
>> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Scott McMorrow
>> Sent: Monday, March 29, 2010 10:44 AM
>> To: Mike Steinberger
>> Cc: wkatz@xxxxxxxxxx; Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx
>> Subject: [ibis-macro] Re: FW: Question on clock_times
>>
>> Mike,
>>
>> I submit that the AMI specification defines a functionally flawed
>> system, and an ambiguous specification. That AMI simulation can
>> occur
>>
>> in spite of this is interesting, but not sufficient for a EIA
>> specification.
>>
>> Scott
>>
>>
>>
>> Mike Steinberger wrote:
>>
>>> Scott-
>>>
>>> I submit that the existing AMI specification defines a syntax which
>>> has enabled a number of _EDA_ _vendors_ to develop AMI simulation
>>> as a
>>>
>>> system. That was our goal.
>>>
>>> Mike S.
>>>
>>> Scott McMorrow wrote:
>>>
>>>> Mike
>>>>
>>>> Great. Now we're on the right track. How do we get back to a
>>>> specification that functionally does what I want as a user? Quite
>>>> frankly, the original developers of the AMI specification failed to
>>>> develop a decent functional model for AMI simulation as a system.
>>>> This has lead to major issues that, in my opinion, need to be
>>>> resolved going forward.
>>>>
>>>> best regards,
>>>>
>>>> Scott
>>>>
>>>>
>>>>
>>>>
>>>> Mike Steinberger wrote:
>>>>
>>>>> Scott-
>>>>>
>>>>> Walter has asked me to answer 2., and I'm pleased to do that.
>>>>>
>>>>> The short answer to 2. is:
>>>>> The EDA platform does _not_ know whether a given model has a CDR
or
>>>>> not, and has no direct way to determine that one way or another
for
>>>>> certain.
>>>>>
>>>>> You may think that if the model returns clock ticks, then the
model
>>>>> has a CDR; but even that's not true. The first Tx model SiSoft
>>>>> published outputs clock ticks because we wanted to exercise that
>>>>> feature of the AMI interface; but you know by looking at the code
>>>>> that there's no CDR in there.
>>>>>
>>>>> Todd tried to assert a simple fact that people have somehow failed
>>>>> to embrace:
>>>>> As long as the model meets the stated software interface
>>>>> definition,
>>>>>
>>>>> it is the EDA platform's responsibility to respond appropriately.
>>>>>
>>>>> What the preceding discussion has quite correctly demonstrated is
>>>>> that it's possible for a model to do something nonsensical and yet
>>>>> be compliant with the software interface definition. This is an
>>>>> instance of the classic distinction between syntax and semantics.
>>>>>
>>>>> The fact of the matter is that all one can expect from any
software
>>>>> interface definition is that it unambiguously defines the _syntax_
>>>>> of the interface. While one may also make some attempt to focus
the
>>>>> _semantics_ of the information crossing the interface, the
>>>>> semantics
>>>>>
>>>>> should not be so tightly constrained as to unduly limit the
>>>>> possibilities. As a standards organization, we struggle with this
>>>>> challenge daily, and there are no simple or complete answers.
>>>>>
>>>>> What this means for the software developer, and especially the EDA
>>>>> platform developer, is the software must take the most sensible
>>>>> course of action when, not if, it gets syntactically correct but
>>>>> semantically nonsensical data.
>>>>>
>>>>> The rock is elated.
>>>>>
>>>>> Mike S.
>>>>>
>>>>>
>>>>>
>>>>> Scott McMorrow wrote:
>>>>>
>>>>>> I have several questions regarding clock ticks, Walter
>>>>>>
>>>>>> 1. 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.
>>>>>> 2. 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?
>>>>>> 3. 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>> --
>> 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
>>
>> ---------------------------------------------------------------------
>> 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
Other related posts:
