From: rickman on
On Feb 26, 7:43 am, Symon <symon_bre...(a)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
From: rickman on
On Feb 26, 6:30 am, "Nial Stewart"
<nial*REMOVE_TH...(a)nialstewartdevelopments.co.uk> wrote:
> >  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.

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
From: Nial Stewart on
> 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.


From: -jg on
On Feb 27, 1:43 am, Symon <symon_bre...(a)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

From: -jg on
On Feb 27, 4:30 am, rickman <gnu...(a)gmail.com> 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.

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