[ibis-macro] Re: IBIS-AMI RX model
- From: "Todd Westerhoff" <twesterh@xxxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Thu, 28 Apr 2011 09:05:01 -0400 (EDT)
Scott,
Thanks for your response.
If you're saying that we should be sure customers know these parameters
are proposed in BIRDs and not part of the published IBIS 5.0
specification, consider that a given. That's what the comment in the .ami
header
| Data management, simulation control, jitter & analog model parameters
using BIRD 121-124 Parameters
was meant to convey. Each section of the .ami file has a header that
indicates its purpose, i.e.
| analog model using S-parameter data
. that associates with the comment in the header. We can make the callout
more explicit on a parameter by parameter basis, for example, changing
| 3 corner receiver latch noise
(Rx_Noise (Usage Info)(Range 0.0020 0.0015 0.0030)(Type Float)
(Description "RX amplitude noise expressed in V.")
)
| 4 corner receiver latch noise
(Rx_Noise_Table
(Dependency
(Parameter (List "Rx_Corner In" "Rx_Noise Sel" ) (Usage Info)
(Type String))
(Row (List "NC" "0.0020" ) (Usage Info)
(Type String))
(Row (List "WC" "0.0025" ) (Usage Info)
(Type String))
(Row (List "BC" "0.0015" ) (Usage Info)
(Type String))
(Row (List "EC" "0.0030" ) (Usage Info)
(Type String))
)
)
to
| 3 corner receiver latch noise using BIRD 123
(Rx_Noise (Usage Info)(Range 0.0020 0.0015 0.0030)(Type Float)
(Description "RX amplitude noise expressed in V.")
)
| 4 corner receiver latch noise using BIRD 124
(Rx_Noise_Table
(Dependency
(Parameter (List "Rx_Corner In" "Rx_Noise Sel" ) (Usage Info)
(Type String))
(Row (List "NC" "0.0020" ) (Usage Info)
(Type String))
(Row (List "WC" "0.0025" ) (Usage Info)
(Type String))
(Row (List "BC" "0.0015" ) (Usage Info)
(Type String))
(Row (List "EC" "0.0030" ) (Usage Info)
(Type String))
)
)
Anyone have a better idea?
Thanks,
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
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Scott McMorrow
Sent: Thursday, April 28, 2011 12:30 AM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: IBIS-AMI RX model
Todd
What I think Arpad means is that this standards has a long way to go. I
can do production work with a K&E Slide Rule (at least if I could remember
how to use one again), but it's not pretty. Right now AMI is in the "it's
getting there" stage, where we need to start making sure that all needs
are met, and not just specific customers, or silicon vendors. Trust me,
the methodology that some of them have is not that great, and can be
greatly improved upon.
As for your model problem, I suggest that you tell your customers that you
will provide this functionality for them in your tool, and that the IBIS
committee is definitely considering your approaches, but that they may
very well require model changes by the time that a specification is
available. If they were my customer, I would have told them up front that
anything that we do that is outside the specification may very be SiSoft
specific and may need to be changed in the future, but to support you, and
early introduction of these methodologies, we would help them to release
modified models in the future at the least possible expense.
Regards,
Scott
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
On 4/27/2011 10:43 PM, Todd Westerhoff wrote:
Arpad,
I'm not looking to argue - I'm asking for guidance. I have a real
problem to solve and I'm trying to do it in a way that creates the least
controversy.
When you say that AMI "is in its infancy and barely able to walk on
crutches", are you suggesting that AMI models and simulators aren't ready
for production work? I hope not, for everyone's sake.
"Innovation" is admittedly an abstract term, and the Tuesday group didn't
seem to like it. I thought about it, and decided that it would be helpful
to make the problem to be solved more tangible.
So I did. The problem is - we have a model to ship in the next few days
that needs functionality described in BIRDs 121-124 to meet the customer's
demand for functionality and the vendor's demand for a single set of model
files.
The question remains - what do you suggest we do?
Thanks,
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
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, April 27, 2011 8:09 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: IBIS-AMI RX model
Todd,
The more we argue over this topic, the more I am starting to get
the impression that you want to use a specification that is in its
infancy, barely able to walk on crutches, as if it was a healthy
and mature race runner. Certain things just can't be done.
Whether the parser flags things or not is irrelevant. You can go
to the doctor for a checkup and he can let you go telling you that
you are healthy and at the same time you can have an undetected
serious disease. It all depends on what they are testing for
whether they will find it or not.
I would like to suggest that instead of discussing whether we are
for or against innovation or unfair competition, we should admit
that we have fundamental issues with the specification. We should
focus on finding solutions to fixing those problems so we can eliminate
the issues of slow progress etc. in the future.
Unfortunately this will take a little more work up front. We can't
just throw together a few keywords and expect that band aid solution
to fix big, fundamental problems. I hear you that customers are
banging on the doors for solutions. We may have to provide
temporary solutions for them while we are working on the real
solution, but we shouldn't pretend that a quick fix band aid solved
our real problems and expect the whole world to follow it.
Arpad
======================================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff
Sent: Wednesday, April 27, 2011 4:45 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] IBIS-AMI RX model
All,
I have a practical question for this group, that demonstrates (hopefully)
the point we've been trying to make about innovation.
Let's say I have a RX model that I need to release this week, which has
the following characteristics:
5 Tap DFE that supports both Linear Approximation (Init/Statistical) and
Adaptive (Getwave/Time-Domain) analysis modes
DFE mode control - allows user to shut DFE off, fix DFE taps at a defined
value, or let model auto-adjust
DFE tap settings output during Time-Domain simulation (Getwave) to enable
plotting and analysis of tap settling time / pattern-based tap drift
4 corner support - model data provided for Nominal (NC), Worst (WC), Best
(BC) and Extreme (EC) conditions
Budget data for random jitter on the RX recovered clock due to
non-correlated on-die switching noise
Budget data for Gaussian noise on the RX sampling latch due to
non-correlated on-die switching noise
Broadband model for the RX termination (analog) network, provided in
S-parameter format
The .s4p files associated with item 6 are to be copied into the user's
project automatically along with the IBIS-AMI model
Items 1 and 2 are supported by IBIS 5.0. No issue there.
Item 3 is debatable, I think. It's supported by the IBIS 5.0 spec as it
currently stands, although some in the Tuesday meeting didn't understand
that until recently. I hear Fangyi saying this should be OK, but I don't
hear general agreement. SiSoft considers this OK, if that wasn't evident.
Item 4 is not supported by IBIS 5.0 and leverages Dependency Tables as
defined in BIRD 124.
Items 5 and 6 are not supported by IBIS 5.0 and leverage jitter/noise
parameters as defined in BIRD 123.
Item 7 is not supported by IBIS 5.0 and leverages analog model parameters
as defined in BIRD 122.
Item 8 is not supported by IBIS 5.0 and leverages data management
parameters as defined in BIRD 121.
The end-user and the semiconductor manufacturer have their own
requirements for this model:
The end-user requires that the model support 4 corner operation, and that
any data that affects the simulation result (jitter budgets, analog
models, etc.) be supplied as part of the model. To be specific, they
don't want to have to fill-in dialogs in the simulator for jitter and
noise budgets based on the model being used, and they don't want to have
to edit the model in any way to use it.
The semiconductor vendor wants a single model that can be supplied to
anyone using any EDA tool, with portability between different EDA tools to
the maximum extent possible. In practice, that means the model should
make best use of IBIS 5.0 syntax, and where the model needs to specify
advanced functionality not part of IBIS 5.0, that data should not
interfere with the operation of the model in another EDA tool. Both the
end-user and the semiconductor vendor understand that another tool may not
make use of the advanced data, or that data may need to be coded in some
other simulator-specific way for use in another tool. But, the reasoning
goes, having the data published in a public way is better than having
strictly proprietary data or no data at all.
As I type this, we have every reason the believe the .dll associated with
this model is known to run in multiple commercial EDA tools. I maintain
that because:
The specific .dll to be released has been demonstrated to run in both the
SiSoft and Cadence public AMI test benches
Multiple .dll's built from the same modeling toolset have been
demonstrated to run in multiple commercial EDA tools
So ... the question is, how should we code items 2-7 in the model's .ibs
and .ami files? For all of the discussion this week on the potential
hazards of publicly defined model-specific parameters, I've heard no
proposals on how to approach this issue. I heard lots of discussion on
what we shouldn't do, but nothing on what we should do, that the IBIS-ATM
Tuesday group would find acceptable.
Once upon a time, we probably would have put this data in the .ibs or .ami
file as a comment, using the |SiSoft syntax. That clearly delineated
functionality as non-IBIS 5.0, but was denounced as being unfair and
proprietary. So, we devised a method of defining these things as
parameters in the .ami file, consistent with the IBIS 5 parser, wrote
everything down, called it Opal. We created a public use license to
guarantee that we couldn't pull the rug out from everyone by changing our
minds and declaring all this stuff was restricted. That was 10 months
ago. Opal AMI parameters were denounced as being proprietary (I still
don't quite get that one) and unfair because the document wasn't open to
uncontrolled edits (and therefore, was protected from unintentional or
deliberate corruption). So, we took the parameter definitions from Opal,
split the parameter definitions up into groups of related items, and
submitted BIRDS 121-124 to the IBIS Open Forum for deliberation. Those
BIRDs are 6 months old now.
The attached .ami file contains everything from items 1-8 using the
parameters defined in BIRDS 121-124 and checks clean with the latest IBIS
parser. I'll add that all of these parameters were publicly defined at
least 10 months ago. Not exactly ancient, but not blindsiding people,
either.
For anyone who wants to follow the values through the attached example,
the values being specified in the model are:
NC
WC
BC
EC
Rx_Receiver_Sensitivity (V)
0.0030
0.0040
0.0020
0.0050
Analog .s4p model file
NC.s4p
WC.s4p
BC.s4p
EC.s4p
Rx clock random jitter (1 sigma, S)
0.5e-12
0.6e-12
0.4e-12
0.7e-12
Rx Gaussian latch noise (1 sigma, V)
0.0020
0.0025
0.0015
0.0030
To the Tuesday group: if you don't like BIRDs 121-124, how would you like
to see this functionality coded and released? That's not a loaded
question - the core model is utterly and completely IBIS 5.0 compliant and
portable, and there's advanced functionality that we're willing to
publicly define in any mutually agreed, reasonable manner. Limiting the
functionality of the model is not an option, and waiting until the
committee achieves consensus is, unfortunately not an option either.
What would you like us to do? The clock is ticking, and we can't afford
to jitter around.
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
Other related posts:
