[SI-LIST] Re: ??: Re: How to use Intel's model?

  • From: "ariazi" <ariazi@xxxxxxxxxxxxxxx>
  • To: si-list@xxxxxxxxxxxxx
  • Date: Mon, 1 Aug 2005 17:37:00 -0700

Dear Brian,

Thank you for your informative reply.

Both the fully pin mapped and signal group mapped models are (in my =
humble
opinion)
satisfactory, when they provide reliable information for simulation.

You have referred to several stages of validation including checking the
model's
[Pin] section, [Diff Pin] statement, timing test loads (for each output
buffer],
simulation and correlation.

It is also worth mentioning the need to run the IBIS Golden Parser =
during
the=20
verification process.  The Visual IBIS Editor is also a nice free tool =
which
can
prove useful when appraising quality of an IBIS model.

Best Regards,

Abe Riazi
serverWorks


-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] =
On
Behalf Of Moran, Brian P
Sent: Monday, August 01, 2005 1:26 PM
To: ariazi@xxxxxxxxxxxxxxx; si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: ??: Re: How to use Intel's model?


Abe,

As Arpad mentioned there are different procedures used in different =
groups.
The methodologies very between CPU, North Bridge and South Bridge teams. =
As
far as=3D20 whether models are fully pin mapped or mapped by signal or
functional group is something that is evolving within each team. I can =
only
speak for the models I create for the mobile segment MCH northbridges. =
All
the models are validated internally and as far as I know all =
differential
pairs should be identified within the model. As a model generator I try =
to
make sure all differential pairs are called out with [Diff Pin]
statements.=3D20

As far as validation goes, there are several stages of validation. We =
first
simulate the models into the test load in one or more simulation tools =
and
then overlay the output waveforms over the waveforms generated into the =
same
load with our internal process specific transistor level models. Once we
establish correlation with the test load we then use the models =
internally
for SI and timing verification. The next step involves simulating the =
models
in actual platform level topologies and correlating the waveforms to lab
measurments on the same platform configurations. We do this for both =
fast
and slow silicon using skewed test silicon in the lab. Lastly, some but =
not
all groups will capture V-I curve trace data on skewed silicon on the =
test
floor and correlate to IBIS model V-I curve data, but this approach is =
being
phased out in most cases.=3D20

Our internal teams prefer to use models which have the buffers mapped as
functional=3D20 buffer types, such as CLK, CTRL, DATA, etc.., rather =
than by
pin. In performing interface level worst case verification simulations =
one
is generally concerned with identifying models by function or signal =
group,
as opposed to by pin.=3D20 Throwing around a 400-500 pin pin mapped IBIS =
model
can be a little clunky when your trying to simulate for worst case CTRL =
to
CLK setup time of the DDR2 interface. So internally we use interface
specific signal group mapped models. In these cases you generally want =
to
instantiate a model by its function rather than its pin number.  Pin =
mapped
models would seem more appropriate for board level=3D20 simulations, =
geared
more for functional verification than worst case SI and timing.=3D20 At =
least
that's my personal bias.  I'm sure there are those who feel otherwise. =
We
generally offer fully pin mapped models by special request.  Since we =
use=3D20
the signal group mapped models internally, it just seems more =
appropriate to
offer these exact models to our customers. So we bundle them up along =
with
the pkg models and release them as a bundle, rather than releasing a =
single
large pin mapped IBIS with everything integrated inside. =3D20

The southbridge team is still using the legacy pin mapped approach, =
which
does make us a bit inconsistent. This is one reason we also provide pin
mapped northbridge models on request. I apologize for the resulting
confusion. Each group is trying to do what they see as the best approach =
to
meet their customer needs. Hope this helps a little. Thank you for your
patience while we work to develop a unified model format.=3D20

By the way I'm always curious to hear from model users in this area, as =
to
why=3D20 one approach or the other is preferred. Your feedback would be
welcome.



Brian P. Moran
Senior SIE Engineer =3D20
Intel Corporation=3D20
brian.p.moran@xxxxxxxxx=3D20

=20


------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field

or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list

For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field

List FAQ wiki page is located at:
                http://si-list.org/wiki/wiki.pl?Si-List_FAQ

List technical documents are available at:
                http://www.si-list.org

List archives are viewable at:     
                //www.freelists.org/archives/si-list
or at our remote archives:
                http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
                http://www.qsl.net/wb6tpu
  

Other related posts: