Prev: Quartus II - Generating Verilog from MegaWizard plugins
Next: ISPLever, devlist command
From: Patrick Maupin on 5 Feb 2010 20:13
On Feb 5, 7:03 pm, Patrick Maupin <pmau...(a)gmail.com> wrote:

> 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
From: Symon on 5 Feb 2010 21:05
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!

From: Patrick Maupin on 5 Feb 2010 21:26
On Feb 5, 8:05 pm, Symon <symon_bre...(a)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
From: Patrick Maupin on 5 Feb 2010 21:35
> 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
From: Brian Davis on 7 Feb 2010 22:33
Patrick Maupin wrote:
>
> 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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Quartus II - Generating Verilog from MegaWizard plugins
Next: ISPLever, devlist command