Frustration with Vendors!
in [FPGA]
|
From: Muzaffer Kal on 27 Feb 2010 23:13 On Sat, 27 Feb 2010 13:03:34 -0800 (PST), -jg <jim.granville(a)gmail.com> wrote: >On Feb 28, 2:59�am, Symon <symon_bre...(a)hotmail.com> wrote: >> On 2/26/2010 10:46 PM, -jg wrote: >> >> > � Why is there no simple Spice pathway to allow users do the 'sanity >> > check' stuff themselves ? >> >> Because Spice models reveal more about the actual structure of the >> device than the vendors are prepared to give. The IBIS table based >> method keeps this proprietary information hidden. > >hmm.. sounds more like spin/deflection than a real reason, to me. > >I did find a useful IBIS resource web page here > >http://www.mentor.com/products/pcb-system-design/modeling-resources > >includes links to many free resources... > >(something FPGA vendors could learn from.. ?) > >-jg Actually FPGA vendors do the same thing. From A to X, all FPGA vendors supply a free version of their tool. So I think you're being a little bit hard on them. With respect to IBIS, I think it is not reasonable to expect any vendor to give their actual circuit so that clients would be able to simulate with it. Even if they did, you'd still need a tool to extract your PCB to generate the netlist for the rest of the system (which interestingly is available for free too). If you say that they can simpify the netlist not to expose their circuits, then IBIS is the modelling language to generate that simplified circuit. Finally what you want (a basic tool which shows you rise/fall times for simple loads) is already available. You can get the Visual IBIS editor and use its waveform viewer to get what you want. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.com
From: rickman on 28 Feb 2010 09:46 On Feb 27, 11:13 pm, Muzaffer Kal <k...(a)dspia.com> wrote: > On Sat, 27 Feb 2010 13:03:34 -0800 (PST), -jg > > > > <jim.granvi...(a)gmail.com> wrote: > >On Feb 28, 2:59 am, Symon <symon_bre...(a)hotmail.com> wrote: > >> On 2/26/2010 10:46 PM, -jg wrote: > > >> > Why is there no simple Spice pathway to allow users do the 'sanity > >> > check' stuff themselves ? > > >> Because Spice models reveal more about the actual structure of the > >> device than the vendors are prepared to give. The IBIS table based > >> method keeps this proprietary information hidden. > > >hmm.. sounds more like spin/deflection than a real reason, to me. > > >I did find a useful IBIS resource web page here > > >http://www.mentor.com/products/pcb-system-design/modeling-resources > > >includes links to many free resources... > > >(something FPGA vendors could learn from.. ?) > > >-jg > > Actually FPGA vendors do the same thing. From A to X, all FPGA vendors > supply a free version of their tool. So I think you're being a little > bit hard on them. With respect to IBIS, I think it is not reasonable > to expect any vendor to give their actual circuit so that clients > would be able to simulate with it. You are missing the point. No one has to give their "actual circuit" in order to provide a spice model. If they have characterized the circuit to build the IBIS model, they can use that same data to produce a spice model that does not reveal the circuit. The more I discuss this, the more I am ticked off about it. The vendors all understand what I am saying. So why are they being so stubborn about not providing characterized spice models? Is there anyone who can explain why spice models that don't reveal circuit details are not provided by the vendors? Is it a mindset that they are providing IBIS models and that should be good enough? I get the impression that when spice models are provided, little or no effort is made to make them compatible with the free versions like LTspice (which btw is an excellent tool!) > Even if they did, you'd still need > a tool to extract your PCB to generate the netlist for the rest of the > system (which interestingly is available for free too). I don't agree that without PCB data an IO model is not useful. All I was looking for was info on the IO without the PCB details. I had no idea what to expect by changing the current setting vs. changing the speed setting. In fact, the more I think about this, the more I realize that even with simulation data, there is no way to guesstimate what to expect and you are left to perform trial and error tests! The only info they give as a function of the settings are the voltages and delays as a function of current. There is no info regarding the speed setting at all! I guess we are all used to designing FPGAs in the dark. > If you say > that they can simpify the netlist not to expose their circuits, then > IBIS is the modelling language to generate that simplified circuit. Yeah, so what's your point? Why can't they then provide that model in a spice description? > Finally what you want (a basic tool which shows you rise/fall times > for simple loads) is already available. You can get the Visual IBIS > editor and use its waveform viewer to get what you want. Now this is some useful info. I downloaded this program and took a look at the waveforms. What could be displayed was very limited and I'm not even sure what the data represents! I looked at a couple of drive strengths that I think are the most interesting and with the 8 mA drive I found the signal never goes above 2.25 volts. It has an intial hump to about 2.25 volts until about 4 ns and then comes back down to about 1.5 volts where it remains for the rest of the data (up to 20 ns). I believe this circuit is driving a 100 ohm pull down resistor which would imply the IO has a 100 ohm effective series resistance. I believe the waveforms are an accurate representation of the part even if I have no idea what it means. On the 12 mA drive level the same thing is seen, although not as pronounced and I see that on the board. Of course the voltage levels are different because I don't have a 100 ohm pulldown in the real circuit. My point is that even after running the simulation, I'm not sure what I am looking at. Is this hump because of something internal to the FPGA, such as extra drive that is turned on during the transition time, or is this a reflection that was captured when collecting the data to enter into the model file? From what I see here, I would say that the best simulation is the one I run on my board. I am starting to think I have been wasting my time pursuing any of this. What good is a model that is totally incapable of modeling my circuit even if I have the full blown multi-kilobuck version of the software? Rick
From: Michael S on 28 Feb 2010 11:09 Assuming you are talking about MAX-II: According to MAX-II device handbook (p.2.29) for any given I/O standard there are only two levels of of programmable drive strength control. So, 8mA and 12mA being the same is not surprising. W.r.t. slew rate control the handbook doesn't say how exactly it is implemented but gives you a hint on p.2.30 - "The lower the voltage standard (for example, 1.8-V LVTTL) the larger the output delay when slow slew is enabled." Being EE from that phrase you could probably figure out the topology of their slew control. Since I am not EE, nor a specialist in CMOS circuit design I wouldn't say what my guess is. My personal advice, not from EE but from experienced Altera designer nevertheless - unless you line has low-impedance parallel termination resistor use minimal drive strength and fast slew rate.
From: Symon on 28 Feb 2010 11:26 On 2/28/2010 4:09 PM, Michael S wrote: > > My personal advice, not from EE but from experienced Altera designer > nevertheless - unless you line has low-impedance parallel termination > resistor use minimal drive strength and fast slew rate. That's probably good advice. The lowest drive strength will probably have the greatest source impedance. This will likely get you closer to a proper source termination. OTOH, if you can get away with the slow rise time, then use it. With a longer rise time, you can have a longer trace without worrying about transmission line effects. Slower rise times have fewer ground bounce issues and associated crosstalk problems. Syms.
From: Nial Stewart on 28 Feb 2010 11:31
> Is there anyone who can explain why spice models that don't reveal > circuit details are not provided by the vendors? Is it a mindset that > they are providing IBIS models and that should be good enough? I get > the impression that when spice models are provided, little or no > effort is made to make them compatible with the free versions like > LTspice (which btw is an excellent tool!) Rick, If you were buying 10's of 1000's of devices a year and asked for spice models you'd get them. Although if you were buying 10's of 1000's of devices a year your company would probably have a hyperlynx license. It's catch 22 for those of us who are working for small companies (or ourselves). Unfortunately. Nial. |