Frustration with Vendors!
in [FPGA]
|
From: rickman on 26 Feb 2010 10:28 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 26 Feb 2010 10:30 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 26 Feb 2010 11:38 > 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 26 Feb 2010 16:00 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 26 Feb 2010 16:13
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 |