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

Yes, it can be important to get through the transition range quickly.
This is exactly the issue we found. With a 40 ns rise time, the clock
was multiple clocking and could even have been clocking on the falling
edge as someone suggested. It didn't do that with my module plugged
into the older board which used an older FPGA. With the newer part
the assumption is that the newer, faster part is able to trigger on
the clock noise. We haven't looked at this on the old chassis yet.
It may be that there is less noise on the old chassis as well.

I don't see how adjusting the drive strength would be better than
adjusting the slew rate. It is the edge rate that causes the problems
with the transmission line, no matter how it is generated. The drive
strength will slow the edge if it can't supply the current during the
transition the same as slowing the slew rate, no?

Rick
From: Kim Enkovaara on
-jg wrote:
> 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.

The biggest problem with spice models is the compatibility. They would
have to verify the models with multiple different spice implementations.

And usually the vendors have spice models only for the high speed serial
transceivers, not for regular IOs. For normal IOs IBIS is enough for
the simulation, and even for the high speed transceivers IBIS-AMI (IBIS
5.0) seems to gain traction due to the difficulties of spice models.

For professional settings SI tools are almost mandatory if the boards
are in any way complex. And SI tools can easily use IBIS models.

--Kim
From: -jg on
On Mar 1, 8:03 pm, Kim Enkovaara <kim.enkova...(a)iki.fi> wrote:
> -jg wrote:
> >  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.
>
> The biggest problem with spice models is the compatibility. They would
> have to verify the models with multiple different spice implementations.
>
> And usually the vendors have spice models only for the high speed serial
> transceivers, not for regular IOs. For normal IOs IBIS is enough for
> the simulation...

?? - you make a simple spice model, from the IBIS,
IBISis fairly vanilla, in the details it provides.

I'll start a new thread with an example.
From: Nial Stewart on
> I really have to say that paying for Hyperlynx once is a lot cheaper
> than fixing board, after board, with bad SI. In fact one re-spin of
> the pcb is about what the tool costs.



Austin,

Out of interest I've asked about Hyperlynx pricing.

There are many different pricing options, but the perpetual licences
for Hyperlynx are...

EXT (MHz version) line (schematic I presume) and board simulation ~ GPB �16K

GHz (GHz version) line and board sim ~ GBP �38K


This might be what it costs to re-spin a board if you're paying a large
CEM to kit and build 20 Virtex boards, but for most of us a re-spin
won't cost anything like that.


We don't all work for large corporations.


Nial.


From: Michael S on
On Mar 1, 7:50 am, rickman <gnu...(a)gmail.com> wrote:
> On Feb 28, 5:46 pm, Michael S <already5cho...(a)yahoo.com> wrote:
> I don't see how adjusting the drive strength would be better than
> adjusting the slew rate. It is the edge rate that causes the problems
> with the transmission line, no matter how it is generated. The drive
> strength will slow the edge if it can't supply the current during the
> transition the same as slowing the slew rate, no?
>
> Rick

The points is - we understand how drive strength control work. Or at
least we think we do ;) As explained above in the thread, there are
several drivers that are turned on or off statically at programming
time (or at load time for SRAM-based devices). Minimal drive strength
= only one driver active = the simplest possible topology = minimum of
surprises.
On the other hand, there are several way of implementing slow slew
rate, we don't know which one is used by your vendor. Or at least I
don't know. Most likely, slew rate control is implemented through some
sort of feedback loop that is described by higher-than-first-order
differential equations = unpleasant surprises are possible.