[ibis-macro] Re: The EMD like syntax of package and on-die interconnect models
- From: Scott McMorrow <scott@xxxxxxxxxxxxx>
- To: Walter Katz <wkatz@xxxxxxxxxx>
- Date: Wed, 18 Sep 2013 17:15:35 -0400
Walter
A generic model can specify Drivers, receivers, and proximity to the
target receiver. If you want I can go through each one of your examples
and show that it can be done in this way. Or ... do you already have
models that you are forcing the specification around?
On Wed, Sep 18, 2013 at 5:05 PM, Walter Katz <wkatz@xxxxxxxxxx> wrote:
> Scott,****
>
> ** **
>
> Scott, with all due respect, your approach is most accurate, and I expect
> you will try to convince IC Vendors to supply the models in your format;
> our packaging solution must support such models. You should not be
> surprised that many IC Vendors (and particularly those that have very few
> letters in their names) will not supply such model in your format, but that
> they supply models that are either generic to a bus with generic worst case
> aggressors, or are specific to a pin for the victim through path with
> generic worst case aggressors; our package solution must support this as
> well. ****
>
> ** **
>
> There is a not to subtle difference between supplying models that
> accurately represent the part, and supplying models that represent a
> conservative model. Supplying a model with a part is an inferred warrantee
> that could affect the production yield of a part, so IC Vendors (especially
> high volume ones) will be conservative on their models, often specifying
> the models using typ/min/max models from a standard as opposed to actual
> accurate models.****
>
> ** **
>
> Do you object that our package solution support both detailed aggressor
> information as you support and bounded aggressor information?****
>
> ** **
>
> Walter****
>
> ** **
>
> *From:* Scott McMorrow [mailto:scott@xxxxxxxxxxxxx]
> *Sent:* Wednesday, September 18, 2013 4:22 PM
>
> *To:* Walter Katz
> *Cc:* IBIS-ATM; Randy Wolff
> *Subject:* Re: [ibis-macro] The EMD like syntax of package and on-die
> interconnect models****
>
> ** **
>
> Walter, with all due respect, all one needs to know are three pieces of
> information:****
>
> ** **
>
> 1) where are all receivers and drivers****
>
> 2) what receiver are we currently measuring****
>
> 3) what drivers in near end proximity to the receiver.****
>
> ** **
>
> with those three pieces of information, all crosstalk methodologies can be
> implemented. One does not need special cases to describe each potential
> methodology.****
>
> ** **
>
> Scott****
>
> ** **
>
> ** **
>
> ** **
>
> On Wed, Sep 18, 2013 at 4:02 PM, Walter Katz <wkatz@xxxxxxxxxx> wrote:****
>
> Scott,****
>
> ****
>
> There is more than one way to skin a cat. There are crosstalk
> methodologies that do not care about victim and aggressors. There are
> crosstalk methodologies that do care which terminals are victims and
> aggressors. An IC vendor can and will choose the way they are going to
> construct and distribute these models. We need to be able to support both
> methodologies.****
>
> ****
>
> Walter****
>
> ****
>
> *From:* Scott McMorrow [mailto:scott@xxxxxxxxxxxxx]
> *Sent:* Wednesday, September 18, 2013 2:38 PM
> *To:* Walter Katz
> *Cc:* IBIS-ATM; Randy Wolff
> *Subject:* Re: [ibis-macro] The EMD like syntax of package and on-die
> interconnect models****
>
> ****
>
> i disagree with victim aggressor constructs. All that needs to be known
> is the location of the drivers and receivers, and grouping of such for a
> general solution.****
>
> ****
>
> On Wed, Sep 18, 2013 at 2:35 PM, Walter Katz <wkatz@xxxxxxxxxx> wrote:****
>
> All,****
>
> ****
>
> I am enclosing a presentation which demonstrates the simple language used
> to describe both the package and on-die interconnect models using the EMD
> like methodology applied to all of the types of models that IC Vendors are
> requesting to deliver.****
>
> ****
>
> Walter****
>
> ****
>
> Walter Katz****
>
> wkatz@xxxxxxxxxx****
>
> Phone 303.449-2308****
>
> Mobile 303.335-6156****
>
> ****
>
>
>
> ****
>
> ****
>
> --
>
> Scott McMorrow
> Teraspeed Consulting Group LLC
> 16 Stormy Brook Rd
> Falmouth, ME 04105
>
> (401) 284-1827 Business
>
> http://www.teraspeed.com
>
> Teraspeed® is the registered service mark of
> Teraspeed Consulting Group LLC****
>
>
>
> ****
>
> ** **
>
> --
>
> Scott McMorrow
> Teraspeed Consulting Group LLC
> 16 Stormy Brook Rd
> Falmouth, ME 04105
>
> (401) 284-1827 Business
>
> http://www.teraspeed.com
>
> Teraspeed® is the registered service mark of
> Teraspeed Consulting Group LLC
>
> ****
>
--
Scott McMorrow
Teraspeed Consulting Group LLC
16 Stormy Brook Rd
Falmouth, ME 04105
(401) 284-1827 Business
http://www.teraspeed.com
Teraspeed® is the registered service mark of
Teraspeed Consulting Group LLC
Other related posts:
