[ibis-macro] Re: yesterday's IBIS-ATM presentation
- From: Todd Westerhoff <twesterh@xxxxxxxxxx>
- To: kwillis@xxxxxxxxxxx
- Date: Wed, 14 Jul 2010 22:36:42 -0400 (EDT)
Ken,
Just to be clear, flow case 7 (slide 10,
http://www.eda.org/pub/ibis/macromodel_wip/archive/20100713/toddwesterhoff/IBIS-AMI%20Flows/Flows_July2010-v2.pdf)
does not require ANY functional changes to work. What it requires is the
ability to extract hREI(t) from the RX_Init call, which in turn requires
deconvolution to be performed by the simulator. While it's true that this can
be a tricky numerical operation, it's already been implemented in at least one
tool (and probably more).
The second and third options discussed in the presentation do require new
functionality of some sort, with the goal of allowing the simulators to avoid
deconvolution. But - case 7 is real and there are model combinations out there
that require it today ... we shouldn't drop it. If we can't agree on a
mechanism to avoid deconvolution, we can still support all the flows with the
note that case 7 requires deconvolution. If a given tool vendor decides not to
support that flow, that's their choice -- but we shouldn't limit the spec
itself.
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: "Ken Willis" <kwillis@xxxxxxxxxxx>
To: "Arpad Muranyi" <Arpad_Muranyi@xxxxxxxxxx>, "IBIS-ATM"
<ibis-macro@xxxxxxxxxxxxx>
Sent: Wednesday, July 14, 2010 11:58:09 AM
Subject: [ibis-macro] Re: yesterday's IBIS-ATM presentation
Hi Arpad,
The stated goal a while back was to get a clarification BIRD in place, without
significant functional changes. This “sticky” combination will take some kind
of significant functional change. And that is fine, but I would prefer to see
it in its own follow-on BIRD.
I think the 8 well-defined flows cover many Serdes applications, and it would
be useful to get those into the spec right away.
Thanks,
Ken Willis
Sigrity, Inc.
860-871-7070
kwillis@xxxxxxxxxxx
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Muranyi, Arpad
Sent: Wednesday, July 14, 2010 10:27 AM
To: IBIS-ATM
Subject: [ibis-macro] Re: yesterday's IBIS-ATM presentation
Ken,
Te problem I see with separating out the sticky combination into
its own BIRD is that the other BIRD that deals with the rest of
the combinations will have to make provisions for avoiding or
forbidding that sticky combination. I is usually hard to remove
something that was put into the spec, and I am afraid that this
division of BIRD-s would just further complicate matters.
Do you really think that addressing the sticky combination would
take that much discussion time after we have gone this far in our
understanding of it?
Thanks,
Arpad
==================================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Ken Willis
Sent: Wednesday, July 14, 2010 9:00 AM
To: 'IBIS-ATM'
Subject: [ibis-macro] yesterday's IBIS-ATM presentation
Hello IBIS-ATM members,
Todd gave a good presentation yesterday, and things have simplified
considerably. For the 9 flows that were presented yesterday, 8 of them are
well-defined and agreed upon. I propose that we:
- immediately push forward with a BIRD that covers those 8 flows, and get that
in place
- move the “sticky” 9 th combination (tx_GetWave > rx_modified_ImpulseResponse)
to its own separate BIRD
Sigrity is ready to vote along these lines at our next meeting. This let’s us
take advantage of the good work that has been done and quickly get this
“clarification BIRD” in place for the majority of AMI combinations.
For the remaining “sticky” combination, there are 3 different potential
solutions that have been identified so far. It will take some more discussion
to finalize, and I don’t see value in delaying the other 8 any longer. Focusing
on that one in its own BIRD should expedite its resolution as well.
Thanks,
Ken Willis
Sigrity, Inc.
860-871-7070
kwillis@xxxxxxxxxxx
Other related posts:
