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
