Hi Michael,
Although such things may not contradict to the currently used syntax rules,
overloading AMI function calls with different meanings doesn't look like a good
idea.
If we really need something non-conventional, it would be good to extend the
set of functions, or the list of arguments in the existing functions to allow
that. In the end, the users of AMI specs are developers who have many other
tasks other than reading the documents, and EDA vendors, not to mention their
users. Therefore, the errors/bad models become imminent or highly probable once
the meaning is not clear.
Vladimir
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] ;
On Behalf Of Mirmak, Michael
Sent: Friday, September 16, 2016 2:40 PM
To: IBIS-ATM (ibis-macro@xxxxxxxxxxxxx)
Subject: [ibis-macro] Clock ticks from a separate buffer or channel?
In AMI, are the clock ticks reported by a buffer (and which may be used to
present a sampled eye) required to be used to sample the data for the *same*
buffer?
The clear implication in the "clock ticks" description text is that clock and
data are taken from the same buffer and same channel or data stream (though the
clock ticks may be ignored), because the data stream is assumed to contain an
embedded clock from which an explicit clock will be recovered.
However, to eventually support other architectures, would not AMI need to
support clock ticks being combined with data from separate channels, in the
case of a forwarded rather than an embedded clock?
This may be entirely at the level of the EDA tool to control or permit.
However, would not some of the time domain flows in the AMI specification need
to explicitly mention this?
Thanks in advance...
- MM
