[ibis-macro] Re: "Final Draft" of the Jitter BIRD 123.2 that I would like reviewed in preparation for submitting to the Open Forum
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 13 Apr 2011 13:29:03 -0700
Hello everyone,
Sorry, but I am still stuck on the issue of (Usage In).
Scott's explanation in the last ATM meeting for why the
Rx model needed a parameter like this made a lot of
sense, but I think there are still some unresolved
questions:
Aside from the Rx DLL needing to know this, the EDA tool
has to be informed about this as well. How would it know
otherwise that it has to generate clock_times for the DLL?
Given that, are we (again) trying to say heck with (Usage In),
we will require the tool to look for this information and
act on it EVEN THOUGH IT IS NOT (Usage Info)? So much
for a consistent specification... It seems to be becoming a
pattern that we have these (Usage ...) and (Type ...) keywords
which we are rendering meaningless because of some exceptions.
Why have them at all then?
How can we solve this? Should we require two parameters,
one for the DLL (Usage In), and another for the tool
(Usage Info)?
The other question is related to the flow regarding the
input/output clock parameter. Currently, we know that clock
times are produced by Rx GetWave. There are many scenarios
possible: clock times originally created by EDA tool, then
given to Tx GetWave, the output from Tx GetWave (different?)
can be used by EDA tool again, possibly modified, then provided
as an input to Rx GetWave, modified, used for post processing
etc... I don't think we can correctly support this without
understanding the flow.
Any comments?
Thanks,
Arpad
==================================================================
Other related posts:
