Frustration with Vendors!

Sun Feb 28, 2010 5:13 am   

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


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

Sun Feb 28, 2010 4:46 pm   

On Feb 27, 11:13 pm, Muzaffer Kal <k...@dspia.com> wrote:

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!)



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.



Yeah, so what's your point? Why can't they then provide that model in
a spice description?



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

Sun Feb 28, 2010 5:26 pm   

On 2/28/2010 4:09 PM, Michael S wrote:

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.

Sun Feb 28, 2010 5:31 pm   

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.

Sun Feb 28, 2010 6:09 pm   

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.

Sun Feb 28, 2010 7:59 pm   

On Feb 28, 11:09 am, Michael S <already5cho...@yahoo.com> wrote:


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

Sun Feb 28, 2010 8:09 pm   

On Feb 28, 11:31 am, "Nial Stewart"
<nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:


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

Sun Feb 28, 2010 8:18 pm   

On Feb 27, 9:59 pm, rickman <gnu...@gmail.com> wrote:


Wow...what a shocker, couldn't get it to work with only 90
clocks?...maybe an even 100 would've done the trick.


trouble with just one clock.

KJ

Sun Feb 28, 2010 8:24 pm   

On Feb 28, 1:18 pm, KJ <kkjenni...@sbcglobal.net> wrote:

I didn't ask for details, but I believe this is about a wide variety
of interfaces. This is an IP network interface with all types of
input/output. The trick is that clocks don't have to be treated as
clocks. They can often be sampled and treated like enables.




I'm curious why do you think that? If each clock domain crossing or
async sampling is done properly, it should work just fine.

Rick

Sun Feb 28, 2010 8:46 pm   

On Sun, 28 Feb 2010 10:24:20 -0800 (PST), rickman <gnuarm_at_gmail.com>
wrote:


different frequencies). If they are not you have to deal with
constantly shifting sampling phase which might force you to do full
phase recovery; which can be done but would be wasteful for so many
clocks.


That many clocks can be managed relatively easily in an ASIC as you
have full control over the clock tree and each intra-clock domain tree
can be synthesized properly. In an FPGA you only have a limited number
of clock tree domains which means you have to push the intra-domain
clocks to fabric routing which can be quite problematic. You also have
the problem of bringing in that many clock through IO which can't
connect to the clock tree (for similar reasons) if they're for
external clocks. Being able to do proper clock domain crossing or
async sampling suggests that you have good local clock management
which you can't have in an FPGA with that many clocks.
--
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

Sun Feb 28, 2010 10:12 pm   

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

Mon Mar 01, 2010 12:46 am   

On Feb 28, 7:59 pm, rickman <gnu...@gmail.com> wrote:

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.


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.

Mon Mar 01, 2010 2:02 am   

On Mar 1, 3:46 am, rickman <gnu...@gmail.com> wrote:

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 = 27
..end

Mon Mar 01, 2010 2:12 am   

Here is the output Spice circuit, edited to
make it easier to follow.


***** main circuit
V1 1 0 PWL ( 0 0
+ 50n 0
+ 52n 3.3
+ 100n 3.3
+ 102n 0)
R1 1 2 15
C1 2 0 5p
R2 2 3 15
C2 3 0 5p
L1 3 4 22n
C3 4 0 5p
IV2ns 4 0 0

V2 5 0 PWL ( 0 0
+ 50n 0
+ 51n 3.3
+ 100n 3.3
+ 101n 0)
R3 5 6 15
C4 6 0 5p
R4 6 7 15
C5 7 0 5p
L2 7 8 22n
C6 8 0 5p
IV1ns 8 0 0

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

..OPTIONS temp = 27
..end

Mon Mar 01, 2010 3:32 am   

On Feb 28, 1:24 pm, rickman <gnu...@gmail.com> wrote:

I think that because based on your comments it sounded to me like they
didn't quite knew what they were doing which is likely why they ended
up with 90 clock domains...either that or you're talking about an ASIC
design and not an FPGA. Low skew clock distribution resources and/or
clock pins are generally not *that* prevalent in FPGAs...ASICs on the
other hand can generate and control as many as the designer wants.

KJ