Re: Frustration with Vendors!

On Sat, 27 Feb 2010 13:03:34 -0800 (PST), -jg
<jim.granville@gmail.com> wrote:

>On Feb 28, 2:59&#4294967295;am, Symon <symon_bre...@hotmail.com> wrote:
>> On 2/26/2010 10:46 PM, -jg wrote:
>>
>> > &#4294967295; 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

On Feb 27, 11:13=A0pm, Muzaffer Kal <k...@dspia.com> wrote:
> On Sat, 27 Feb 2010 13:03:34 -0800 (PST), -jg
>
>
>
> <jim.granvi...@gmail.com> wrote:
> >On Feb 28, 2:59 am, Symon <symon_bre...@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 =A0that clients
> would be able to =A0simulate 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

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.

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.

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

On Feb 28, 11:09=A0am, Michael S <already5cho...@yahoo.com> wrote:
> 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 =A0from 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.


I'm not sure why you are quoting the Altera device handbook.  I guess
that is the standard assumption if not using Xilinx.  The part I am
using has 4, 8, 12, 16 and 20 mA drive strength and FAST vs. SLOW
speeds.  It does not appear that they are just linear extrapolations
and in particular, in the IBIS "simulation" I see some very odd
behavior which I am pretty sure has nothing to do with transmission
line effects.  BTW, the IBIS simulation I can access is not really a
simulation at all, but just a curve that was provided for one set of
conditions (and rather odd ones at that).

Are you sure the advice you got wasn't for low current drive and
*slow* slew rate?  A slow slew rate works well with longer lines than
does a fast slew rate.

Rick

On Feb 28, 11:31=A0am, "Nial Stewart"
<nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> > Is there anyone who can explain why spice models that don't reveal
> > circuit details are not provided by the vendors? =A0Is it a mindset tha=
t
> > they are providing IBIS models and that should be good enough? =A0I 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 m=
odels
> 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 our=
selves).
>
> Unfortunately.
>
> Nial.


Why would I buy a piece of software that I will use once per year,
maybe, when its only purpose for me is to mitigate crappy support???
The original complaint was not about how I was stuck, not having a way
to deal with the SI problem.  It was about the fact that I asked a
vendor for a very simple piece of information and instead of a simply
answer I got a load of stuff that was not only not useful, it was very
counter productive as I tried to make use of it?

The end result was that I had to spend an afternoon programming up a
bunch of boards with different configurations and test them all at my
customer's facility.  Having a multi-kilobuck tool would have only
saved me the trouble of programming the 10 different combinations and
instead have let me just test the two or three most likely choices.
Clearly this is not worth the cost in time and money it would take to
buy and ramp up on a tool like Hyperlynx.

I appreciate everyone's input to this.  I have learned significantly
from this discussion, both about the models and tools as well as other
people's attitudes about IO modeling, especially the vendors.

BTW, we have already sold over 500 units and will likely be selling
several thousand over the next few years.  It has to do with IRIG time
codes and if I can find a way to get into the general market this may
lead to a standard product.  Marketing is not my forte, but I am
learning...

Rick

> From what I see here, I would say that the best simulation is the one
> I run on my board. =A0I am starting to think I have been wasting my time
> pursuing any of this. =A0What 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?

I often find that the simulation tools are designed for optimization
of ball park designs. Of course the ball park gets smaller when the
clock speed max of a device goes up! Are mega bucks worth the
investment? Not for me, I have not received the pennies yet, so why
would I use anything other than the free design lead tools. I would
have thought the later technology should have the adaptation (i.e.
digital LPF) avoiding the need for re-engineering. But then again
there may be some good work in it.

Cheers Jacko

hhtp://forum.nibzx.co.uk

On Feb 28, 7:59 pm, rickman <gnu...@gmail.com> wrote:
> On Feb 28, 11:09 am, Michael S <already5cho...@yahoo.com> wrote:
>
>
>
> > 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.
>
> I'm not sure why you are quoting the Altera device handbook.  I guess
> that is the standard assumption if not using Xilinx.

Exactly.
Sorry for misunderstanding on my part. After reading the whole thread
and realized that you are using Latice device.
So just ignore everything I wrote above.

> The part I am
> using has 4, 8, 12, 16 and 20 mA drive strength and FAST vs. SLOW
> speeds.  It does not appear that they are just linear extrapolations
> and in particular, in the IBIS "simulation" I see some very odd
> behavior which I am pretty sure has nothing to do with transmission
> line effects.  BTW, the IBIS simulation I can access is not really a
> simulation at all, but just a curve that was provided for one set of
> conditions (and rather odd ones at that).
>
> Are you sure the advice you got wasn't for low current drive and
> *slow* slew rate?  A slow slew rate works well with longer lines than
> does a fast slew rate.
>
> Rick

My advice was for Altera.
In Altera case, applying slow slew rate to signal used as a clock is
not such a bright idea. Reducing drive strength is safer and, for a
given overshoot, would normally get you faster voltage change rate in
the threshold region (=good).
I don't know whether the same is true for your Lattice device.

On Mar 1, 3:46=A0am, rickman <gnu...@gmail.com> wrote:
>
> You are missing the point. =A0No one has to give their "actual circuit"
> in order to provide a spice model. =A0If 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. =A0The more I
> discuss this, the more I am ticked off about it. =A0The vendors all
> understand what I am saying. =A0So why are they being so stubborn about
> not providing characterized spice models?

As a quick reality check, I grabbed a IBIS summary, and they store
quite basic info : Ramp-Up, Ramp-Down, Cap, and the V-I plot of the
pin drive.

That can fairly easily give drive impedances, and for the simplest
tests I ignored the Clamp pathways.

Next, I used the Ramp values to make a PWL source, and then I split
the typical impedances and use the N-fet ones, as they are lower, and
added in some real world L, and voila : a Spice Circuit, that can be
related to the key IBIS models.

Because I like comparisons, I then copied/pasted to get TWO copies,
and inserted two example Ramp times.

Output is two ringing waveforms, with MUCH worse ringing on the 1ns
ramp case than the 2ns ramp case.

This should work in ANY spice that supports PWL sources.
So, not sure WHY the vendors find that "too hard" ?

[Took longer to type the post, than get the first plot]

-jg



~~~~~~~~~~~~ Spice Netlist, IBIS napkin example ~~~~~~~~~~~~~

***** main circuit
L2 3  4 22n
C6 2  0 5p
C3 8  0 5p
C2 7  0 5p
C1 6  0 5p
L1 7  8 22n
R2 6  7 15
C5 3  0 5p
IV2ns 8  0 0
R1 5  6 15
V1 5  0 PWL ( 0 0
+ 50n 0
+ 52n 3.3
+ 100n 3.3
+ 102n 0)
C4 4  0 5p
R3 2  3 15
IV1ns 4  0 0
R4 1  2 15
V2 1  0 PWL ( 0 0
+ 50n 0
+ 51n 3.3
+ 100n 3.3
+ 101n 0)


.TRAN  1E-9 1.2E-7 3E-8 1E-9

.OPTIONS  temp =3D 27
.end