Xilinx claims:

We recommend the use of IBIS models whenever possible. IBIS models for
many devices are often available as free downloads. Using IBIS
provides the following:

    * Faster simulation speed.
    * Elimination of non-convergence.
    * Strong support from virtually all EDA vendors.

Well, when I use ltspice for the simple things I check, simulation
speed and non-convergence are non-issues.  And the claimed "Strong
support from virtually all EDA vendors" isn't really a reason to
*prefer* IBIS (as is implied) but is really more of a rationalization
about why IBIS really isn't that much worse than spice.

Now, I know that the statement is probably quite factual, especially
since ltspice doesn't actually come from an EDA vendor.  But, ltspice
is my preferred analog simulation tool, and I would love to have a
Xilinx Spartan 3A pin model that works with it.

Alas, I see IBIS models for all the FPGAs, but spice models for only a
few.  If there weren't any IBIS models for the Spartan 3A, I might
think that one of the Virtex spice models would suffice, but the
disparity between the IBIS model list and the spice model list at
http://www.xilinx.com/support/download/index.htm gives me pause.

Any thoughts?

Thanks,
Pat

Pat,

We have encrypted hspice models as shown, mostly only for Virtex
family parts, for "heavy lifting" customers who require them.

Since the devices models belong to Toshiba, IBM, UMC (etc.), these
must be protected (they do not belong to us), so the hspice encrypted
models are what we support.  Period.

IBIS models exist for all families, and parts.  These are per the IBIS
standard, so any tool that works with the IBIS standard should support
these models.  If it doesn't then we need to know (file a webcase so
we can see why it didn't work).

The latest IBIS extension is for the high speed serial IO on newer
parts, also supported per the standard.

xSpice (n, p, x, etc. take your pick) are not supported.  Period.

Austin

On Feb 5, 1:13=A0pm, austin
<aus...@xilinx.com> wrote:
> Pat,
>
> We have encrypted hspice models as shown, mostly only for Virtex
> family parts, for "heavy lifting" customers who require them.
>
> Since the devices models belong to Toshiba, IBM, UMC (etc.), these
> must be protected (they do not belong to us), so the hspice encrypted
> models are what we support. =A0Period.
>
> IBIS models exist for all families, and parts. =A0These are per the IBIS
> standard, so any tool that works with the IBIS standard should support
> these models. =A0If it doesn't then we need to know (file a webcase so
> we can see why it didn't work).
>
> The latest IBIS extension is for the high speed serial IO on newer
> parts, also supported per the standard.
>
> xSpice (n, p, x, etc. take your pick) are not supported. =A0Period.
>
> Austin

A quick Google of "convert IBIS models to spice" brings up quite
a few conversion tools.  Perhaps you could try to run the Spartan
3A IBIS model through a converter?

On Feb 5, 12:49=A0pm, Gabor
<ga...@alacron.com> wrote:
> On Feb 5, 1:13=A0pm, austin <aus...@xilinx.com> wrote:
>
>
>
> > Pat,
>
> > We have encrypted hspice models as shown, mostly only for Virtex
> > family parts, for "heavy lifting" customers who require them.
>
> > Since the devices models belong to Toshiba, IBM, UMC (etc.), these
> > must be protected (they do not belong to us), so the hspice encrypted
> > models are what we support. =A0Period.
>
> > IBIS models exist for all families, and parts. =A0These are per the IBI=
S
> > standard, so any tool that works with the IBIS standard should support
> > these models. =A0If it doesn't then we need to know (file a webcase so
> > we can see why it didn't work).
>
> > The latest IBIS extension is for the high speed serial IO on newer
> > parts, also supported per the standard.
>
> > xSpice (n, p, x, etc. take your pick) are not supported. =A0Period.
>
> > Austin
>
> A quick Google of "convert IBIS models to spice" brings up quite
> a few conversion tools. =A0Perhaps you could try to run the Spartan
> 3A IBIS model through a converter?

On my computer, googling "convert IBIS models to spice" brought up a
lot of pointers to a SINGLE tool from 1998, and a lot of tools which
go from spice to IBIS.  But, you might be more adept at googling than
me, so if you find more than the tool at intusoft, please share.

Thanks,
Pat

On Feb 5, 12:13=A0pm, austin
<aus...@xilinx.com> wrote:

> xSpice (n, p, x, etc. take your pick) are not supported. =A0Period.

Thanks for the clarification.  A simple perusal of the web page when I
was tired didn't make that fact clear.

And I understand that you can't share third-party IP.  But, it seems
like you're in a perfect position to build a simplified model, check
it against the third party IP models, and distribute it with no
warranties and the caveat that it is simplified, and matches
reasonably well, but not perfectly.

I don't know if you tally these things or not, but if you do, please
put me down in the category of "would like to see pin spice models
available."

Thanks,
Pat

On Feb 5, 7:03=A0pm, Patrick Maupin
<pmau...@gmail.com> wrote:

> And I understand that you can't share third-party IP. =A0But, it seems
> like you're in a perfect position to build a simplified model, check
> it against the third party IP models, and distribute it with no
> warranties and the caveat that it is simplified, and matches
> reasonably well, but not perfectly.

To add to this, intusoft apparently has a more up-to-date ibis->spice
converter for paying customers (and other EDA vendors may as well).
If the fabs don't object to Xilinx shipping the data in an IBIS file,
they certainly shouldn't be able to object to you converting that data
back to a spice model using such a third-party tool.

Again, Xilinx is in the best position to do this, because (1) then the
conversion is only done one place and hopefully only has to be paid
for once; and (2) somebody who can legally use the original spice
model can eyeball the results of a few sims to make sure the converter
didn't go completely wacky.

I may not represent most of your customers, in that I'm completely
paranoid about how things work, but the more I think about it, the
more I think that, personally, even if I wanted to use your IBIS
models, I can't trust them, because it sounds like you haven't round-
tripped them back to spice and checked that they match the original
models reasonably well.

Best regards,
Pat

On 2/5/2010 2:44 AM, Patrick Maupin wrote:

> Xilinx Spartan 3A pin
>

>
> Any thoughts?
>
> Thanks,
> Pat

Pat, the pins are a 10pf capacitor.

HTH, Syms.

p.s. More or less!

On Feb 5, 8:05=A0pm, Symon
<symon_bre...@hotmail.com> wrote:
> On 2/5/2010 2:44 AM, Patrick Maupin wrote:
>
> > Xilinx Spartan 3A pin
>
> > Any thoughts?
>
> > Thanks,
> > Pat
>
> Pat, the pins are a 10pf capacitor.
>
> HTH, Syms.
>
> p.s. More or less!

Thanks, Symon, that is indeed very useful.

My current needs are in regard to the differential receiver (probably
in LVDS mode).  I have a (slow, around 1 MHz) Manchester-encoded
differential signal that might be at a really low level (or a really
high level!), and that requires level shifting as well.  I want to
bring it in to the LVDS pins, probably through a small external
preamplifier with some AC coupling.  Naturally, I want to simplify the
preamp as much as possible, so it would be great to be able to
simulate it in conjunction with the receiver.

Obviously, simulating the receiver as a couple of caps to ground and
looking at the voltages at the pins to make sure they are within LVDS
spec is a good start, but it would be really excellent to be able to
see the recovered signal out the back of the receiver in the
simulation.

Basically, I'm just trying to save an external comparator.  Slow
comparators are available in smallish quantities for under 30 cents,
but the prices for faster ones just seem unreasonable, and since I'm
doing all the clock and data recovery digitally, I prefer to have a
fair degree of accuracy on the location of the signal edges.

Thanks,
Pat

> Basically, I'm just trying to save an
external comparator. =A0Slow
> comparators are available in smallish quantities for under 30 cents,
> but the prices for faster ones just seem unreasonable, and since I'm
> doing all the clock and data recovery digitally, I prefer to have a
> fair degree of accuracy on the location of the signal edges.

Forgot to mention.  In this design, I have a lot of pins available.
The smallest FPGA is a sunk cost, with a lot of resources which I am
trying to use cleverly (but not so cleverly I get burned in
production).  Since the signal is so slow, I  am considering providing
hysteresis to the comparator by outputting the decoded signal back out
an LVDS transmit pair.  At 1 MHz, even a 15 ns prop delay in providing
a tiny hysteresis should not be a problem, I don't think, but I'd love
to have a reasonably accurate model to test this against.

Thanks,
Pat

Patrick wrote:
>
> But, you might be more adept at googling than me, so if you
>find more than the tool at intusoft, please share.
>
 I poked a stick at the free Intusoft tool some years
back, it didn't help me much as the IBIS models I needed
to translate were a later version than it supported.

 I have manually extracted info from the IBIS tables
and package models to set up LTspice runs; this works
well when verified against lab measurements.

-----------

 FWIW, I posted an simple, unverified LVDS LTSPICE sim
here a few years ago showing problems that arise when
driving a typical FPGA input from a fast LVDS A/D with
sub-ns high impedance current source outputs :
  http://groups.google.com/group/comp.arch.fpga/msg/ab999f47d42e50f8
  http://fpgastuff.googlepages.com/lvds_current.pdf
  http://fpgastuff.googlepages.com/lvds_current.zip

-----------
Free tools that might help:

Edality's IBIS tool has a free viewer-only mode that I find useful:
  http://www.edality.com/ibisds/v1/

Eispice looks interesting ( haven't used this one yet ),
includes some sort of IBIS model support:
  http://www.thedigitalmachine.net/eispice.html

Brian