[ibis-macro] Re: FW: Question on clock_times
- From: "Todd Westerhoff" <twesterh@xxxxxxxxxx>
- To: <scott@xxxxxxxxxxxxx>, "'Mike Steinberger'" <msteinb@xxxxxxxxxx>
- Date: Mon, 29 Mar 2010 12:47:32 -0400 (EDT)
OK, can we stop now?
How about we focus on the language of the spec, pull paragraphs out for
discussion, and discuss how the writing can be improved?
Scott, it looks like you should be attending the Tuesday meetings.
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
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Scott McMorrow
Sent: Monday, March 29, 2010 9:44 AM
To: Mike Steinberger
Cc: wkatz@xxxxxxxxxx; Arpad_Muranyi@xxxxxxxxxx; 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
TeraspeedR 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
Other related posts:
