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

rickman <g...@gmail.com> wrote:
> 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.

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                b...@elektron.ikp.physik.tu-darmstadt.de

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

On Feb 26, 4:52=A0am, Uwe Bonnes
<b...@elektron.ikp.physik.tu-
darmstadt.de> wrote:
> rickman <gnu...@gmail.com> wrote:
> > Sometimes vendors act like they don't want you to use their parts. =A0I
> > 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. =A0I recall the rise/fall times to be
> > something that is very common in data sheets. =A0They just pick a set o=
f
> > conditions and give the data. =A0Even 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. =A0In 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.
>
> Go back to the basic, starting without transmission line effects.
> With 10 mA source current and 10 pf load, dU/dt =3D 10 mA/10pF =3D 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.

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

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

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


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. 

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.

On Feb 26, 7:43=A0am, Symon
<symon_bre...@hotmail.com> wrote:
> 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.

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

On Feb 26, 6:30=A0am, "Nial Stewart"
<nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> > =A0The
> > settings include current drive of 4, 8, 12, 16 and 20 mA along with
> > speed settings of FAST and SLOW. =A0Clearly you can't just do a
> > calculation based on the rated current since that would leave no room
> > for the FAST/SLOW setting.
>
> 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.
>
> > I am left only
> > with building 10 different bit files, loading up 10 different boards
> > and taking 10 measurements. =A0Not my idea of a fun afternoon.
>
> 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.

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

> I don't need to knock up a "Mickey
Mouse" design to test.

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.

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


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


Nial. 

On Feb 27, 1:43=A0am, Symon
<symon_bre...@hotmail.com> wrote:
> 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.

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

On Feb 27, 4:30=A0am, rickman
<gnu...@gmail.com> wrote:
> I don't need to knock up a "Mickey Mouse" design to test. =A0I can use
> my standard design. =A0But 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.

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