From: jacko on
> 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?

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


From: Michael S on
On Feb 28, 7:59 pm, rickman <gnu...(a)> wrote:
> On Feb 28, 11:09 am, Michael S <already5cho...(a)> 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.

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.

From: -jg on
On Mar 1, 3:46 am, rickman <gnu...(a)> 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?

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]


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

From: -jg on
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
From: KJ on
On Feb 28, 1:24 pm, rickman <gnu...(a)> wrote:
> > Whilst good advice you gave them, I somehow think they will still have
> > trouble with just one clock.
> I'm curious why do you think that?  If each clock domain crossing or
> async sampling is done properly, it should work just fine.

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.