Simulating Spartan 3A pins in ltspice

[Patrick Maupin]

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

[austin]

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

[Gabor]

Post by austin
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

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?

[Patrick Maupin]

Post by Gabor

Post by austin
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

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 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

[Brian Davis]

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

[Patrick Maupin]

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
 http://groups.google.com/group/comp.arch.fpga/msg/ab999f47d42e50f8
 http://fpgastuff.googlepages.com/lvds_current.pdf
 http://fpgastuff.googlepages.com/lvds_current.zip
-----------
 http://www.edality.com/ibisds/v1/
Eispice looks interesting ( haven't used this one yet ),
 http://www.thedigitalmachine.net/eispice.html
Brian

Very good links! Thanks!

I don't know how, but I missed them when I did some research before I
posted my question.

Pat

[Brian Davis]

Post by Patrick Maupin
Very good links! Thanks!

If you get anywhere with this, please post an update!

A couple further notes/links:

--------------
An old thread on using the Intusoft translator with LTSpice:

http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/c4feb68203854343

--------------
Xilinx IBIS Package Models

In the past few years, Xilinx has changed the package
models for their most recent FPGA families; the original
Tline-ahead-of-IBIS-parasitics method, that I had used in
that simple LTSpice example, has changed to a lumped model
with both coupled and uncoupled package data available.

See my posts on the following thread for additional
notes and links regarding the changes to package models:

http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/3ff729ef8f851707

( in the really big BGA packages, Lpkg for the single lump
approach gets a bit unwieldy for high speed signals; I'd
probably break that Lpkg/Cpkg into several smaller lumps )

Brian

[Patrick Maupin]

Post by Brian Davis
If you get anywhere with this, please post an update!

Well, I did a bit of work on how I could do a differential input amp,
and between the small signal I wanted to decode, the offset voltage I
was probably looking at with using discretes, and the fact I wanted to
have controlled hysteresis, I decided to go with an external
comparator. Microchip seems to have entered the market in a fairly
aggressive way; they hit the performance I need at a much better price
point than TI or Linear.

I could possibly use the internal receiver on the FPGA without an
external amplifier, but since Xilinx doesn't offer spice support and
the total market for this particular product probably isn't worth me
going in the lab and characterizing parts, I'm not going to do it.

On the one hand, I understand Xilinx's perspective, and at one level
it's a reasonable one -- they really only want to spend a lot on
supporting large customers doing fairly standard stuff. On the other
hand, when I go back and re-read a few of the threads here, they do
seem a bit gruff about it. For instance, when Steve Austin says that
the cost of HyperLynx is less than a single board spin, he's not
living in my world. On this project, I'm trying out various things on
a board I can plug into a S3A starter kit. Total cost of a spin is a
couple of hundred dollars, and lots of board rework can be tried
without actually doing a spin, and I don't anticipate any problems
that HyperLynx would actually solve for me in any case (especially
since I'm not a big customer that Xilinx would give an encrypted model
to).

Let me put it another way. You can't sell a single Spartan 3A for
$5.40 at DigiKey or Avnet Express and expect that everyone who buys a
single FPGA will have all the fancy tools, and that nobody who buys a
single FPGA will have silly questions. So, while I appreciate the
helpful information that Xilinx provides here, I also appreciate the
answers that I've seen you and Symon and rickman and countless others
give here over the years, and when I go back and read some of the
threads, it almost surprises me that some of you guys are still here
after some of the unwarranted flaming that you have received.

I've been using Xilinx parts for 13 years; been heavily involved in
projects which probably bought a total of over $2 million dollars of
parts from them, and a) I've never had to respin a board because of
any reason, much less SI (because I'm completely anal, and also
because I haven't done any really high-speed designs), and b) I've
never used anything remotely as complicated as HyperLynx. Steve acts
like it's plug and play, but I've looked at stuff like that, and
honestly, if you don't do it every day, the cost of ramping up to do
it is as bad as the non-trivial license cost.

So, although some of us would like to think that the whole purpose of
buying an FPGA is to remove as much other stuff from the board as
possible, I guess we have to add using any of the analog on the chip
in a non-standard way to the long list of things that Xilinx doesn't
want us to do. I just wish that we could convince them that it is
possible for them to document how things are implemented without them
having to support non-sanctioned use of the implementation. Sometimes
I think headway is being made (like with the USB cable drivers under
Linux), but sometimes it is very frustrating, especially when a
feature like the differential receiver looks like it might be able to
save me an external 60 cent part, but they don't think it's worthwhile
to give me the information that would allow me to make that
determination for myself.

Anyway, thanks for the information. I'm sure I will refer back to
this thread (and some of the previous threads) the next time I care
about detailed I/O pin characteristics.

Regards,
Pat

[Patrick Maupin]

Post by Brian Davis
If you get anywhere with this, please post an update!

Well, I did a bit of work on how I could do a differential input amp,
and between the small signal I wanted to decode, the offset voltage I
was probably looking at with using discretes, and the fact I wanted to
have controlled hysteresis, I decided to go with an external
comparator. Microchip seems to have entered the market in a fairly
aggressive way; they hit the performance I need at a much better price
point than TI or Linear.

I could possibly use the internal receiver on the FPGA without an
external amplifier, but since Xilinx doesn't offer spice support and
the total market for this particular product probably isn't worth me
going in the lab and characterizing parts, I'm not going to do it.

On the one hand, I understand Xilinx's perspective, and at one level
it's a reasonable one -- they really only want to spend a lot on
supporting large customers doing fairly standard stuff. On the other
hand, when I go back and re-read a few of the threads here, they do
seem a bit gruff about it. For instance, when Steve Austin says that
the cost of HyperLynx is less than a single board spin, he's not
living in my world. On this project, I'm trying out various things on
a board I can plug into a S3A starter kit. Total cost of a spin is a
couple of hundred dollars, and lots of board rework can be tried
without actually doing a spin, and I don't anticipate any problems
that HyperLynx would actually solve for me in any case (especially
since I'm not a big customer that Xilinx would give an encrypted model
to).

Let me put it another way. You can't sell a single Spartan 3A for
$5.40 at DigiKey or Avnet Express and expect that everyone who buys a
single FPGA will have all the fancy tools, and that nobody who buys a
single FPGA will have silly questions. So, while I appreciate the
helpful information that Xilinx provides here, I also appreciate the
answers that I've seen you and Symon and rickman and countless others
give here over the years, and when I go back and read some of the
threads, it almost surprises me that some of you guys are still here
after some of the unwarranted flaming that you have received.

I've been using Xilinx parts for 13 years; been heavily involved in
projects which probably bought a total of over $2 million dollars of
parts from them, and a) I've never had to respin a board because of
any reason, much less SI (because I'm completely anal, and also
because I haven't done any really high-speed designs), and b) I've
never used anything remotely as complicated as HyperLynx. Steve acts
like it's plug and play, but I've looked at stuff like that, and
honestly, if you don't do it every day, the cost of ramping up to do
it is as bad as the non-trivial license cost.

So, although some of us would like to think that the whole purpose of
buying an FPGA is to remove as much other stuff from the board as
possible, I guess we have to add using any of the analog on the chip
in a non-standard way to the long list of things that Xilinx doesn't
want us to do. I just wish that we could convince them that it is
possible for them to document how things are implemented without them
having to support non-sanctioned use of the implementation. Sometimes
I think headway is being made (like with the USB cable drivers under
Linux), but sometimes it is very frustrating, especially when a
feature like the differential receiver looks like it might be able to
save me an external 60 cent part, but they don't think it's worthwhile
to give me the information that would allow me to make that
determination for myself.

Anyway, thanks for the information. I'm sure I will refer back to
this thread (and some of the previous threads) the next time I care
about detailed I/O pin characteristics.

Regards,
Pat

[Patrick Maupin]

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

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

[Patrick Maupin]

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.

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

[Symon]

Post by Patrick Maupin
Xilinx Spartan 3A pin
Any thoughts?
Thanks,
Pat

Pat, the pins are a 10pf capacitor.

HTH, Syms.

p.s. More or less!

[Patrick Maupin]

Post by Symon

Post by Patrick Maupin
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

[Patrick Maupin]

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.

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