Frustration with Vendors!

Fri Feb 26, 2010 8:43 am   

Sometimes vendors act like they don't want you to use their parts. I
am looking for rise/fall time information on an FPGA output in one
voltage mode LVCMOS33 and the various drive and slew rate options.
This doesn't sound like a difficult thing to ask for, but it seems to
be a very difficult thing to get. I recall the rise/fall times to be
something that is very common in data sheets. They just pick a set of
conditions and give the data. Even if that does not match your
circuit design perfectly, it is a data point to start with.

In my case, I am seeing a ridiculously slow rise time with the current
setting which happens to be the lowest current and slowest slew rate.
I guess that is not unexpected. In fact, I'm a bit surprised we
didn't see a problem with it before now. If I go with the highest
drive and fast slew rate, I get very significant overshoot which is
also not surprising.

So obviously I need to find a happy medium. I could make up some
boards with different drive settings and see how they work, but there
are 10 combinations total and this is a bit of a PITA and has to
involve my customer to make the measurements.

Since they don't include rise time info in the data sheet, I thought,
maybe I'll contact support and get the info. That was last Friday
when I called thinking this was such a simple request that maybe they
could answer the question on the phone... silly me. I have not
received a reply from that contact yet!

Yesterday I got tired of waiting and in addition to pinging support by
email, I made a post in their forum. That seems to have gotten a
response but not an answer. I am repeatedly told that the info would
do me no good since it would not match my circuit; I can get this info
from an IBIS simulation and several other ideas of how to get the
info... meanwhile I'm not actually getting the info from support.

I don't have a way to simulate IBIS models. I tried to convert the
IBIS file to a spice model, but the resulting file was not compatible
with the spice I use. I was told to manually read the IBIS model, but
it is a huge thing that includes all of the IO modes with such cryptic
names that I have no way of knowing which section is for which IO
setting. They even have been giving me advice on how to properly
design a transmission line! The guy has all but written a book of
advice for me on all this, but none of the solutions work for me. It
just seems absurd that support is going to so much trouble to give me
advice I don't want in lieu of some very simple data I do want.

So I am going to have to build a bit file with each of the various
setting combinations and spend the afternoon measuring each one. It
just seems like such a waste of time, but it will be easier than
trying to pass the camel of support through the eye of the needle of
my question.

Rick

Fri Feb 26, 2010 11:52 am   

rickman <gnuarm_at_gmail.com> wrote:

Go back to the basic, starting without transmission line effects.
With 10 mA source current and 10 pf load, dU/dt = 10 mA/10pF = 1V/nS

10 pF is probably no bad guestimate for one output with one pin load and
some trace...

So probably series termination is another approach you should consider.

Bye
--
Uwe Bonnes bon_at_elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Fri Feb 26, 2010 12:30 pm   

I might be wrong, but I _think_ that in Quartus a FAST or SLOW assignment
overrides the current setting, so that's fewer variations to worry about.



Sure it wouldn't take too long to knock up a mickey mouse design that
just toggles a single pin then vary the assignments. You could have a new
test re-built and programmed in a minute or two.

Or are there other constraints?



Nial.

Fri Feb 26, 2010 12:39 pm   

On Feb 26, 4:52 am, Uwe Bonnes <b...@elektron.ikp.physik.tu-
darmstadt.de> wrote:

Where did you get any of the data you are talking about? How did you
come up with 10 mA?

I could have done all sorts of things if I want to make assumptions,
but they would be just that, assumptions and not information. The
settings include current drive of 4, 8, 12, 16 and 20 mA along with
speed settings of FAST and SLOW. Clearly you can't just do a
calculation based on the rated current since that would leave no room
for the FAST/SLOW setting. I believe I was told by one of the FPGA
vendors that their parts had current controlled internal nodes which
could set the slew rate. So it may be that the speed setting alone
controls the slew rate of a bare pin. Like I said, that would be a
good start, but until I can get an informative reply I am left only
with building 10 different bit files, loading up 10 different boards
and taking 10 measurements. Not my idea of a fun afternoon.

Rick

Fri Feb 26, 2010 1:43 pm   

If I was gonna guess how FPGA's outputs with programmable drive and slew
work, I'd say there are a bunch of FETs in parallel, turning on more of
them for more drive. So, for 2mA, just one FET gets turned on, for 24mA,
all of them do. The gate current to these FETs can be limited, which
gives slower skew, or not limited which means they go as fast as possible.

It would be impossible for a vendor to publish a 'rise time' for these
devices, because of the many different settings, which is why the IBIS
files are great.

Cheers, Syms.

Fri Feb 26, 2010 5:28 pm   

On Feb 26, 7:43 am, Symon <symon_bre...@hotmail.com> wrote:

Why would it be "impossible" to publish rise time data for parts?
They publish delay information for all the various parts with
modifiers for the IO standards. Heck, I bet the rise time data is
easier since it is likely the same across speed grades and parts. It
may vary with package, so it is a wash.

The IBIS files are only great if you have a way of simulating them.
Oh, the vendors could also provide the *SAME* data in a spice file,
not the high accuracy, design detail revealing spice models that they
consider proprietary, but models derived from the IBIS descriptions
which reveal nothing about your parts the IBIS files don't.

I think this is one of those areas where vendors just don't listen
well enough to their customers to meet their needs. They see spice
models as "bad" because they don't want their IO "secrets" revealed
and don't get that a spice model is so much better for the users than
IBIS models. Or better yet, go ahead and provide some basic data when
requested. Jeeze, these guys actually suggested for me to pull the
data from the 80 kB IBIS file with all its cryptic notation and put it
in a spread sheet!!!

Rick

Fri Feb 26, 2010 5:30 pm   

On Feb 26, 6:30 am, "Nial Stewart"
<nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:

I don't need to knock up a "Mickey Mouse" design to test. I can use
my standard design. But it is not so easy because I will have to
program 10 boards with 10 different configurations to do this and take
them to my customer's facility to test. I supply him with boards, he
doesn't supply me with his system.

Rick

Fri Feb 26, 2010 5:38 pm   

The point of 'mickey mouse' is that you can P&R in a matter of seconds.

Do a test, re-run P&R and do the next test in less than a couple of
minutes. Less than an hour for all the tests including the initial
mickey mouse and time for a cup of tea.



OK, so the other constraint is that you can't do the measurement then
quickly re-program the FPGA?


Nial.

Fri Feb 26, 2010 11:00 pm   

On Feb 27, 1:43 am, Symon <symon_bre...@hotmail.com> wrote:

IBIS files are only great, if you can use them ;)

Rick's issue illustrate a classic 'falling between two stools'
problem.

The info has got more complex, and so they defer to a IBIS model, but
now that info, is only conditionally visible. (and worse, general
experience has got lost to the software)

There are plenty of free/cheap spice tools around, so there really
should be a 'simplest common denominator' offering from the IC
vendors, that allows usable 'quick checks' of port behavior, on all
drive conditions.

That's only a small amount of work needed at the IC vendor end, to
fix a blind spot.

-jg

Fri Feb 26, 2010 11:13 pm   

On Feb 27, 4:30 am, rickman <gnu...@gmail.com> wrote:

You could use the info you have already :
You seem to have two corner cases, so some
interpolation could reduce the passes a lot ?

- How slow is 'ridiculously slow', what v/ns ?
- How FAST is the fastest slew, and what ringing ?

Drop those two into a vanilla I.LCR model in AnySpice,
and verify your observations.

Then, choose an intermediate drive level, and check if that does what
you need.

I also found this
http://www.fpgarelated.com/usenet/fpga/show/90362-2.php

so it is not a rare issue.

-jg

Fri Feb 26, 2010 11:31 pm   

Rick,

Must not be a Xilinx part, as our hotline engineers have copies of all
popular signal integrity tools, and any webcase (from a paying
customer: students and hobbyists might have to email me, or post
their queury on our forums) that provides the needed information (part
number, package, io type, drive strength, slew setting, pcb trace
length, load) can request a "what if" sanity check answer (slew rate,
overshoot, undershoot, SLOW/WEAK and FAST/STRONG IBIS process/voltage/
temperature corners)....

You know my email, too, so if you had emailed me, you would have your
answer by now.

I really have to say that paying for Hyperlynx once is a lot cheaper
than fixing board, after board, with bad SI. In fact one re-spin of
the pcb is about what the tool costs. Now, you know I don't gain
anything from the endorsement of this tool, unless it is one of our
parts that is being used (as the board gets done sooner, and we see
revenue earlier).

Seems some companies really have forgotten that they need customers.

Been a long time since I posted something like this... with Peter
Alfke retired from Xilinx, I wear a "white hat" all the time now, and
I am nothing but nice, and helpful (no negativity!). I think my
fearsome reputation in the halls of the 'other' FPGA company has
quietly faded from memory.

Austin

Sat Feb 27, 2010 12:46 am   

On Feb 27, 10:31 am, austin <aus...@xilinx.com> wrote:

Decoding all that tho, confirms Rick's issue that there is no easy
way for a customer to simply do this themselves ?

Why is there no simple Spice pathway to allow users do the 'sanity
check' stuff themselves ?

It seems IBIS to spice is doable, but with some caveats, so is the
sort of thing a vendor should do once, as opposed to hundreds of
customers ?

Many Spice offerings have node-limited freebies, and there are widely
used free items like LTSpice and SpiceOpus.

-jg

Sat Feb 27, 2010 3:32 am   

On Feb 26, 4:31 pm, austin <aus...@xilinx.com> wrote:

Thanks for the reply. No, it isn't a Xilinx part and no one is
respinning any boards over this. In fact, the point is that I have
the ability to deal with the SI issue by adjusting the IO parameters.
But it would be so much easier to get a handle on what settings to try
for testing if I had the simple, basic data of what the part does when
the settings are adjusted. I'm not planning to spend five large to
make up for a vendor's shortcomings. If Xilinx had an appropriate
part, I likely would have used it. But it is hard to find any FPGAs
in 100 TQFP packages, much less Flash based ones.

The problem started when we found the original setting produced a
rising edge so slow that it created multiple pulses on a clock line.
The board worked ok in the original chassis, but the new customer
design uses a faster FPGA to receive the clock and had failures. In
the end, I had to meet with my customer today with a bucket of boards
with different settings. I think we can use one of the mid range
values that gives a good trade off of edge rate and overshoot. I
couldn't test one value because I made a mistake and programmed two
boards with the same bit file. Unfortunately the missing one is
likely the one we will want to use. So I'll be back with my customer
Monday with another board.

Rick

Sat Feb 27, 2010 6:25 am   

On Feb 27, 3:30 pm, rickman <gnu...@gmail.com> wrote:

Which Flash FPGA in 100 pins did you select?
Actel seem to have good coverage there, and we are about
to trial a ProASIC nano.
Actel also look to be releasing an ARM variant next week.

-jg

Sat Feb 27, 2010 1:16 pm   

Austin,

You've posted this a few times.

I've had a look at the Mentor web site for costs before but as usual they
aren't mentioned.

I don't want to contact them for pricing as it'll probably lead to being
pestered by a rep.

Does anyone know how much you'd pay for a one off license (US $ will do,
although we probably pay the same in GBP as with most EDA tools)?


Nial

----------------------------------------------------------
Nial Stewart Developments Ltd Tel: +44 131 516 8883
32/12 Hardengreen Business Park Fax: +44 131 663 8771
Dalkeith, Midlothian
EH22 3NX
www.nialstewartdevelopments.co.uk