[SI-LIST] Re: one question for HSPICE and IBIS_AMI
- From: Scott McMorrow <scott@xxxxxxxxxxxxx>
- To: si-list@xxxxxxxxxxxxx
- Date: Tue, 05 Apr 2011 12:16:52 -0400
Todd
Your analogy is interesting and telling.
* The driver of an automobile - the end customer - does not need to
know the details of the control systems used in the engine. He
has implicit trust in the integrity of the manufacturer and
regulatory agencies involved in the manufacture of automobiles.
o The ISP that consumes an internet router - the end consumer
- does not need to know the details of the design of the
router. He has implicit trust in the integrity of the
manufacturer and regulatory agencies involved in the
manufacture of electronic equipment.
* The designers of the automobile engine - the engineers - need to
know all that is necessary regarding their use of DA software
(FEM, CFD and other modeling software) to insure that the design
is reliable and meets all safety and regulatory compliance
specifications. To do this, the engineer must have explicit trust
in the physics involved and the ability of the software tools used
to model the physics of electronics, mechanics, and engine dynamics.
o The designers of the internet router - the engineers - need
to know all that is necessary regarding their use of EDA
software (modelers, solvers, simulators) to insure the
design is reliable and meets all regulatory compliance
specifications.To do this, the engineer must have explicit
trust in the physics involved and the ability of the
software tools used to model the physics of the electronic
circuit being developed.
* The designers of the DA/EDA software - the software developers -
need to be able to design and create software that meets the needs
of engineers to model and simulate the physics of real things. It
is the DA developer's responsibility to provide the proofs that
allow engineers to develop explicit trust that the software does
indeed correctly model the physics required for a particular
application.
You equated the designers of electronic systems with drivers of
automobiles. That is not correct. Designers of electronic systems are
equivalent to the designers of automotive systems. Do either need to
know the exact details of the algorithms being used? No. However, they
do need to know enough of the details, and be given the necessary
"proofs", to develop explicit trust in the software that they use to
accomplish the goal of developing implicit trust with the true end
users. In lieu of those proofs, engineers themselves must perform the
due diligence necessary to develop explicit trust in the tools they
choose, since they truly have the most liability in the development chain.
In the world of the automobile, as it is in electronic systems, and even
physics itself, the proof that the DA/EDA tools work correctly is the
domain of metrology - measurement correlation to modeling and
simulation. An interesting example of this is in modern day Formula 1
racing. Every Formula 1 Teams uses Computational Fluid Dynamics (CFD)
to develop the aerodynamics packages. Most teams utilize a combination
of CFD for design, and wind tunnel testing for verification and further
tuning. Adrian Newey, chief aerodynamicist for Red Bull racing,
utilizes a combination of Ansys CFD software, and wind tunnel testing to
validate and tune the results. On the other end of the spectrum, Neck
Wirth, the technical director for the Virgin Racing team, uses as
CFD-only approach to aerodynamics package design to limit the total
development costs.
In the end, at this years Australian Grand Prix, the leading Red Bull
Racing entry qualified at a lap time of 1m 23.5s, and finished First.
The fastest Virgin Racing entry qualifed at 1m 30.8s, and finished 14th
in a field of 24. There was about a 9% difference between the two cars
during qualifying that translated to about a 7.5% difference in the
final result.
The Virgin team trusts their CFD modeling tools.
The Red Bull trusts their CFD modeling tools, but verifies them with
extensive wind tunnel testing.
I have a policy that I've enforced for many many years. I do not trust
any EDA modeling and simulation software, until it is proven to have
been verified against measurements. Since most EDA vendors to not feel
it important to provide correlation data, I generally end up doing this
myself.
With respect to the subject at hand, HSPICE and IBIS-AMI co-simulation,
it's certainly possible to do, and suffers from the same issues as
IBIS-AMI with respect to non-linear driver behavior.
best 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
Teraspeed® is the registered service mark of
Teraspeed Consulting Group LLC
On 4/5/2011 10:05 AM, Todd Westerhoff wrote:
> Arpad,
>
> I guess it depends on how you look at it. Those of us close to AMI know
> that the analysis runs in two phases - network characterization and
> channel simulation, and that different parts of an IBIS-AMI model are used
> for each phase. The analog part of an IBIS-AMI model is used for network
> characterization and the algorithmic part of the model is used for channel
> simulation. If your point is that a HSPICE transistor model can't be used
> in a channel simulation, you're certainly correct.
>
> I think most users want to bring models into their projects and run
> simulations without getting too involved with what goes on "under the
> hood". They see that the EDA tool runs steps called network
> characterization and channel simulation, but they don't want to dig into
> those details if they don't have to ... those are the things that the IBIS
> committee, the EDA companies and the Semiconductor companies are supposed
> to worry about. From the user's perspective, if they can create a
> schematic with a mix of IBIS-AMI and HSPICE models, push the "run" button
> and get waveforms, the simulator supports the mix, regardless of what goes
> on under the hood. I don't know the details of how my car activates the
> turbo; I just know that I mash the pedal when I'm getting on the highway
> and the car goes fast.
>
> We find that mixing HSPICE and AMI models is useful when an IBIS-AMI model
> isn't available and the HSPICE model reasonably models the device's
> equalization. In practice, that usually amounts to TX's with FIR filters
> and RX's that have peaking filters with no DFE. From the user's
> perspective, the model behaves like an IBIS-AMI model, with the difference
> that network characterization just takes longer and requires an HSPICE
> license.
>
> 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: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]
> On Behalf Of Muranyi, Arpad
> Sent: Tuesday, April 05, 2011 12:20 AM
> To: si-list@xxxxxxxxxxxxx
> Subject: [SI-LIST] Re: one question for HSPIC and IBIS_AMI
>
> Todd,
>
> I gave a clear explanation with the reasons why AMI and SPICE models
> couldn't be simulated together in the same simulator.
> As far as I can tell, these explanations also answer the questions you
> raised. I was referring to simulating SPICE and AMI models directly in
> the same simulation engine without any modifications, translations, or
> conversions of the models.
> Let me know if you know how to do that, I would be happy to run to the
> patent office with it... :-)
>
> I apologize if my interpretation of the original question was too
> technically oriented. I admit I may have overlooked the practical aspects
> of that question. I am sure EDA vendors have a variety of ways of
> handling mixed model scenarios, just as my company's product(s) offer
> various ways of handling that.
>
> Regarding the article you mentioned, the methodology described there is
> the same that Ambrish mentioned earlier in this thread.
> However, I would like to point out that in order to be able to do this,
> the device not only has to be LTI (as mentioned in the article) but its
> SPICE model would have to include all of the filtering blocks, which is
> not always available in the SPICE models because that makes a very
> complicated and large netlist which results in very slow simulations.
> Even if your tool has features to convert SPICE models to impulse
> responses, your channel analysis results will be pretty much useless if
> the SPICE model doesn't include the filters...
>
> Thanks,
>
> Arpad
> ================================================================
>
>
>
> -----Original Message-----
> From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]
> On Behalf Of Todd Westerhoff
> Sent: Monday, April 04, 2011 1:25 PM
> To: si-list@xxxxxxxxxxxxx
> Subject: [SI-LIST] Re: one question for HSPIC and IBIS_AMI
>
> Arpad,
>
> When you say that IBIS-AMI and HSPICE models can't be mixed, are you
> making a general statement or a tool-specific one?
>
> I ask because we maintain that mixing HSPICE and IBIS-AMI models is
> possible if the simulator has the proper mechanisms to support it. We
> presented a paper titled " Multi-Gigabit Serial Link Analysis using HSPICE
> and AMI Models" at SNUG 2009/Boston and SNUG 2010/San Jose.
>
> 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: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]
> On Behalf Of Muranyi, Arpad
> Sent: Sunday, April 03, 2011 1:04 PM
> To: si-list@xxxxxxxxxxxxx
> Subject: [SI-LIST] Re: one question for HSPIC and IBIS_AMI
>
> Jimmy,
>
> First, like Steve Kaufer already stated, you need to get the latest
> version of HyperLynx which does have IBIS-AMI support.
>
> Second, IBIS-AMI simulations can't be done in "mixed mode".
> You have to have AMI models for both Tx and Rx to be able to use
> algorithmic (AMI) models. You can't have a SPICE or regular IBIS model on
> one end and an algorithmic model on the other end. These two types of
> models do not mix (like water and oil).
>
> The reason is because regular SPICE and IBIS models are simulated by an
> iterative circuit solver simulator which solves the voltages and currents
> in the circuit using Ohm's law, Kirchhoff's law etc... for each node
> voltage and branch current. AMI models, on the other hand start with an
> impulse response of the channel and process that with signal processing
> algorithms. This technique only processes the waveform seen at the
> receiver (usually).
>
> I hope this gives you a better understanding of the nature of these two
> types of models and simulations.
>
> Arpad
> =============================================================
>
>
> -----Original Message-----
> From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]
> On Behalf Of Jimmy Lee
> Sent: Saturday, April 02, 2011 12:05 PM
> To: si-list@xxxxxxxxxxxxx
> Subject: [SI-LIST] one question for HSPIC and IBIS_AMI
>
> Hi SI expert
> Something confused me several days
>
> I need to perform serdes channel simulations with mixed models(HSPICE and
> IBIS-AMI). Is it possible? EDA tools I have are HSPICE 2010.03-sp1, SIGXP
> 16.2, Hyperlynx 8.0. I found neither sigxp nor hyperlynx on there version
> support IBIS-AMI. HSPICE is said to support IBIS-AMI in Statistical Eye
> Analysis mode with .stateye command. Is there a tutorial about how to do a
> serdes channel simulation with mixed hspice and ibis-ami models in HSPICE?
> BTW, could I just do a transient simulation with the preemphasis or
> equalization options compiled in .ami or .dll file?
>
>
> Thanks
> Jimmy
>
>
> ------------------------------------------------------------------
> 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 technical documents are available at:
> http://www.si-list.net
>
> List archives are viewable at:
> //www.freelists.org/archives/si-list
>
> Old (prior to June 6, 2001) list archives are viewable at:
> http://www.qsl.net/wb6tpu
>
> ------------------------------------------------------------------
> 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 technical documents are available at:
> http://www.si-list.net
>
> List archives are viewable at:
> //www.freelists.org/archives/si-list
>
> Old (prior to June 6, 2001) list archives are viewable at:
> http://www.qsl.net/wb6tpu
>
>
> ------------------------------------------------------------------
> 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 technical documents are available at:
> http://www.si-list.net
>
> List archives are viewable at:
> //www.freelists.org/archives/si-list
>
> Old (prior to June 6, 2001) list archives are viewable at:
> http://www.qsl.net/wb6tpu
>
>
------------------------------------------------------------------
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 technical documents are available at:
http://www.si-list.net
List archives are viewable at:
//www.freelists.org/archives/si-list
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
Other related posts:
