[SI-LIST] Re: package SSN model accuracy requirements

  • From: "Tom Biggs" <tbiggs@xxxxxxxxxxxxxxxxxxxxx>
  • To: <si-list@xxxxxxxxxxxxx>
  • Date: Wed, 16 Mar 2005 16:02:00 -0800

I have a half-baked idea for implementing encryption of AMS.

HSPICE has their own encryption for their own proprietary version of
SPICE.

If the non-proprietary languages of Verilog-AMS and VHDL-AMS become
standard, that does not mean that the encryption has to be standard.

For example, Cadence could offer their proprietary encryption/decryption
solution.
Mentor could offer theirs, etc.

So if you tell some chip company that you are using Mentor, they would
encrypt their non-proprietary model with Mentor's proprietary encryption
tool (which they should be able to get for free from Mentor since it
encourages you to own a Mentor tool) and send it to you.

No matter what tool the customer is using, the unencrypted model never
changes. The chip company can decide to only support encryption for
software that they have tested their model against.

This doesn't solve Chris's "what can I use today?" question, but it
provides a solution companies can work toward (how long does it take to
come up with encryption/decryption software).

So which company is going to be first to implement this?

    -tom

-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]
On Behalf Of Chris Cheng
Sent: Wednesday, March 16, 2005 3:31 PM
Cc: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: package SSN model accuracy requirements


Gary,
Once again, that's an interesting paper to say the least.=20
But here are a few questions/comments about the paper,
=20
a) I am fascinated about Figure 1 because Altera is generous enough to
hand out the state diagram of their I/O design and call it whatever
behavioral you want, the device characteristic of their transistors. If
I am a poor competitor of Altera who doesn't know how to design these Gb
I/O, I will be jumping for joy. :-D In all seriousness, I have sat on
both side of the table. As a user who pretty much can request any models
I want and as a provider of those models. Whatever new models you
mentioned in your reference paper, I would bet a lot of lawyers and
managers in Si houses will consider them too proprietary to simply
handing it out unencrypted to the general public. I don't think you can
make a case of your model's abstraction can really protect IP anymore.
Which is what IBIS is supposed to do. But that has always been the
struggle I see in the Si community. I always feel it is an oxymoron
thing to "abstract" enough to hand out your design while "accurate"
enough to represent any tricks you did in your circuit. This topic of
SSO may be ONE of the reasons I feel the current IBIS behavioral model
is inadequate (as confirm by those who are in the committees). But there
are many other short comings needed to be addressed and when the time
comes, what kind of "behavioral" model can you say will be good enough
to protect IP while the other can not ? Any do you think every company's
lawyers/management will have the same conclusion (I hope they are all as
generous as Altera) ? It's like asking the question : Can you tell me
the secret of you company ? Ans : Well, no I can't tell you in English
(SPICE) but I can tell you in Russian (AMS)
=20
b) You will probably answer "ahh, it's easy, we can encrypt it just like
HSPICE." Is there any standard in encrypting *-AMS so that vendor a's
encrypted model can be read from vendor b ? Worst, as Todd pointed out,
did the market decide whether Verilog-AMS or VHDL-AMS is the way to go
yet ? Tom and I have a difference in opinion in supporting SPICE. I
wonder if he can say something about Verilog vs. VHDL ? To me, the SPICE
market is a pretty much settled one, if you notice the responses of all
the Si vendors in Si-list, they all settled for encrypted HSPICE. While
Tom may worry about how to get other SPICE to work, I say it's already a
sign of the de facto industrial standard. Can you say the same about
Verilog-AMS vs. VHDL-AMS ? How big a political fight it will be between
Verilog-AMS vs. VHDL-AMS as compare with HSPICE vs. the other spice ?
=20
c) Given your example is no more than using digital stimuli to generate
control and data pattern followed by a near transistor model of the main
stages, I wonder if a two pass simulation with a digital simulation of
the control and followed by using the captured logic outputs as inputs
to a pure transistor level description of the main and pre-driver will
be close enough to AMS's speed ?=20
In the latter, I presume existing CAD tools in the infrastructure
already has digital simulation and spice analyzers. No need to buy some
$100K AMS new tool again.
=20
d) Which brings back my fundamental problem with behavioral modelling. I
really don't know what the answers in c) should be but none of them
seems straight forward enough to me that the Joe app engineer can crank
out in the very near future. Anytime you have to attempt to deviate from
the original design flow of the Si houses (which I presume is dominated
by SPICE), you are putting faith in the app engineers who, up to now,
can not even abstract out a standard to help me predict a simple SSO
problem other than using encrypted HSPICE.
=20
What do you think ?
 -----Original Message-----
From: Pratt, Gary [mailto:gary_pratt@xxxxxxxxxxx]
Sent: Tuesday, March 15, 2005 11:14 AM
To: scott@xxxxxxxxxxxxx
Cc: twesterh@xxxxxxxxx; michael.mirmak@xxxxxxxxx; weirsi@xxxxxxxxxx;
Chris.Cheng@xxxxxxxxxxxx; si-list@xxxxxxxxxxxxx
Subject: RE: [SI-LIST] Re: package SSN model accuracy requirements



Scott,
=20
Please see:
=20
     Modeling and Simulation of Multi-Gigabit Serial PCB Interconnect
        by Mike Donnelly -- Mentor Graphics Corporation, and=20
        Panch Chandrasekaran -- Altera Corporation
=20
This should be in the si-list data repository at
<http://si-list.org/files/tech_files/Altera_Mentor_Modeling_Simulation_M
Gb_S
erial.pdf>
http://si-list.org/files/tech_files/Altera_Mentor_Modeling_Simulation_MG
b_Se
rial.pdf  (thank you Ray).  It was presented at an IEC function a while
back, but no longer seemed to be accessible.  Keep in mind the speed
comparisons were made against a transistor-level designs running in
Eldo. The AMS numbers would be even better if compared to a slower
SPICE.
=20
I know of other development efforts underway at silicon vendors, but I'm
not able to share any of that due to NDA constraints.  But, keep your
eyes open. I understand there are some papers on the horizon.
=20
Unfortunately, Mentor doesn't have a dedicated group to promote IBIS
4.1.  I can't speak for the SI management, but I suspect they felt one
working example was sufficient, and the standard should live from there
on its own merits.  I suspect its tough to justify much budget to
promote an open standard these days.
=20
If you would like to evaluate IBIS 4.1 with Mentor tools, you can obtain
the design kit from Altera, and I can put you in touch with the
applicable Mentor Product Manager for an eval copy of the tool.
=20
Regards,
=20
=20
Gary
=20
=20
=20
=20
=20


  _____ =20

From: Scott McMorrow [mailto:scott@xxxxxxxxxxxxx]=20
Sent: Monday, March 14, 2005 2:07 PM
To: Pratt, Gary
Cc: twesterh@xxxxxxxxx; michael.mirmak@xxxxxxxxx; weirsi@xxxxxxxxxx;
Chris.Cheng@xxxxxxxxxxxx; si-list@xxxxxxxxxxxxx
Subject: Re: [SI-LIST] Re: package SSN model accuracy requirements


Gary

I have a few questions about AMS solutions that I have not yet seen
discussed.=20

I understand that it is theoretically possible to model anything in an
AMS language.  However, at this point in time, I have not seen a
soup-to-nuts comparison of an HSPICE model of a complex differential
equalized driver or receiver and an AMS equivalent model, as either a
simulator correlation or ultimately a measurement correlation.  As a
user at many different levels I would like to see performance
benchmarks, model development time benchmarks, and relative and absolute
accuracy comparisions with both simulation and measurement.  All
apples-to-apples comparions.

I have heard many accolades regarding AMS languages over the last few
years, and do not doubt that it may be possible to eventually convince
silicon vendors to switch over to AMS as the preferred modeling
language, but there are many practical issues that I have not yet seen
dealt with, including:


*       Switchover costs associated with changing a silicon vendor's
in-house overall device modeling process to AMS from HSPICE or other
internal Spice.  =20

*       A workable general process for converting Hspice or other Spice
model into an AMS equivalent as a transition strategy from Spice to AMS.



*       This would require a method to encapsulate the entire I/O buffer
in
and AMS language,  from=20

*       core predrivers to final output stages, inclusive of
pre-emphasis,
de-emphasis,=20


*       driver PVT control circuitry,=20


*       differential balance circuitry,=20


*       FIR filtering at the driver and/or receiver,=20


*       driver/receiver out-of-band signaling and control circuitry, etc
....=20

*       Tradeoffs for speed vs. accuracy in the translation


*       Performance comparisons between the converted AMS model and the
original Spice model.=20


*       Performance comparisons should be on the same computational
platform.=20

*       Accuracy and speed comparions of translated AMS models vs. Spice
and
native AMS I/O buffer models.=20


*       Accuracy to simulated and measured data should be shown.



Gary, are there any documents from you, your company, or the industry in
general that discuss these issues at length?

I would agree that the Mentor IBIS/Eldo/AMS simulation platform has the
potential for some valuable contributions and performance advantages to
modeling and simulation methodology for board, package and chip-level
design.  However, to my knowledge, there is no substantive data that
shows that these advantages have been achieved and correlated to real
measured systems with the kind of accuracy which Chris Cheng, Steve
Weir, myself and others are accustomed to.  If you have real information
to the contrary, I would love to see it.

Ultimately, as both a user and a model developer, correlation to
measured results is king.  Show me the simulation and measurements side
by side on a real device in a real system, and I'll be a believer.
First show me the correlated results of one high-performance link.  Then
show me the correlated results for all links in the systems switching,
including all package effects including ground and power bounce (Which
implies that the simulation must be capable of fully floating power and
ground networks from device to device.)

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 <http://www.teraspeed.com>=20



Teraspeed(r) is the registered service mark of

Teraspeed Consulting Group LLC


Pratt, Gary wrote:=20

Great question Todd.  The answer is that the top three SI tool vendors

all have VHDL-AMS and Verilog-AMS simulators in-house.  All that is

required is sufficient industry pressure to encourage them to port the

simulators to their SI tools. And, I've heard there is another SI vendor

almost ready to burst onto the market with their AMS solution.



Also, I know of at least one inexpensive VHDL-AMS simulator on the

market which an SI vendor could possibly OEM (and I suspect there are

more).  I also know there is at least one vendor who has a VHDL-AMS

parser that outputs C code which can then be used to drive any simulator

which accepts C modules. =3D20



I suspect once a tool vendor were motivated to search, there would be

other solutions out there waiting to be found as well.



Somehow, it seems industry is always able to meet market demand.  I'm

sure AMS will be no exception. =3D20



Gary



 =3D20



-----Original Message-----

From: Todd Westerhoff (twesterh) [ mailto:twesterh@xxxxxxxxx
<mailto:twesterh@xxxxxxxxx> ]=3D20

Sent: Monday, March 14, 2005 8:27 AM

To:  michael.mirmak@xxxxxxxxx <mailto:michael.mirmak@xxxxxxxxx> ;
weirsi@xxxxxxxxxx <mailto:weirsi@xxxxxxxxxx> ; Pratt, Gary;

Chris.Cheng@xxxxxxxxxxxx <mailto:Chris.Cheng@xxxxxxxxxxxx> ;
si-list@xxxxxxxxxxxxx <mailto:si-list@xxxxxxxxxxxxx>=20

Subject: RE: [SI-LIST] Re: package SSN model accuracy requirements



Okay, I'll probably get flamed for asking this, but it's worth the risk

anyway:



When we talk about AMS, it seems to me we're really talking about two

things in practice - VHDL-AMS and Verilog-AMS.



If a vendor walked in today and plunked down a CD with VHDL-AMS model on

it, my guess is that they would have developed it with Mentor tools.

I'd also guess that they wouldn't have tested it with the Cadence

toolset, nor have plans to.



I think the converse is also true - a Verilog-AMS model was likely

developed with Cadence tools and not tested with their Mentor

counterparts.



I don't know which vendors support AMS beyond Cadence and Mentor.  There

certainly could be others, I'm just not aware of them.



So - my question (you knew it would come along eventually, right?)



In current practice, doesn't AMS end up essentially being a

vendor-specific solution?  I fully understand that this is a new

technology and that my question isn't "fair" from a long term point of

view.  But - as others have said - we get measured on what we do today

to deliver product in the near term.  Simulation technologies that hold

promise two years out are fine, but they have little immediate impact.



I'm just wondering if I'm right with my current impressions about

Verilog-AMS and VHDL-AMS being vendor-specific in practice.  If that

really is the case, then I'm also wondering how we propose to get from

where we are now to a point where we have models that are portable

across tools again.



Todd. =3D20





Todd Westerhoff

High Speed Design Group Manager

Cisco Systems

1414 Massachusetts Ave - Boxboro, MA - 01719  email:twesterh@xxxxxxxxx
<email:twesterh@xxxxxxxxx>=20

ph: 978-936-2149

=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D=
3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D
=3D3D=3D

=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D=
3D=3D3D=3D3D=3D3D=3D3D



"Always do right.

 This will gratify some people and astonish the rest."



- Mark Twain



 =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:    =20
                //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
 =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: