elektroda.net NewsGroups Forum Index - FPGA - Frustration with Vendors!
rickman
Guest
Guest
Mon Mar 01, 2010 7:50 am
On Feb 28, 5:46 pm, Michael S <already5cho...@yahoo.com> wrote:
Quote:
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 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.
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
Kim Enkovaara
Guest
Guest
Mon Mar 01, 2010 8:03 am
-jg wrote:
Quote:
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.
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
-jg
Guest
Guest
Mon Mar 01, 2010 10:02 am
On Mar 1, 8:03 pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote:
Quote:
-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...
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.
Nial Stewart
Guest
Guest
Mon Mar 01, 2010 11:38 am
Quote:
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.
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.
Michael S
Guest
Guest
Mon Mar 01, 2010 12:39 pm
On Mar 1, 7:50 am, rickman <gnu...@gmail.com> wrote:
Quote:
On Feb 28, 5:46 pm, Michael S <already5cho...@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
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.
rickman
Guest
Guest
Tue Mar 02, 2010 1:36 am
On Mar 1, 5:38 am, "Nial Stewart"
<nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
Quote:
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.
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.
Even so, I have *never* had to respin a board because of SI issues. A
full blown simulation tool is not the only way to analyze this sort of
stuff, regardless of what you will hear. Heck how often do you even
have the full details of your loading to use with a high end tool?
You have to extract that data from the layout program and they don't
pull if from a universal Gerber file. You have to be using a
compatible layout program... more big bucks, otherwise needlessly
spent.
Rick
Nial Stewart
Guest
Guest
Tue Mar 02, 2010 10:54 am
Quote:
Even so, I have *never* had to respin a board because of SI issues.
Neither have I, but I haven't exactly been pushing the boundaries for
the last couple of years.
Quote:
A
full blown simulation tool is not the only way to analyze this sort of
stuff, regardless of what you will hear. Heck how often do you even
have the full details of your loading to use with a high end tool?
You have to extract that data from the layout program and they don't
pull if from a universal Gerber file.
full blown simulation tool is not the only way to analyze this sort of
stuff, regardless of what you will hear. Heck how often do you even
have the full details of your loading to use with a high end tool?
You have to extract that data from the layout program and they don't
pull if from a universal Gerber file.
I think Hyperlynx will pull in Gerbers OK.
At least it should for what it costs.
Nial
Kim Enkovaara
Guest
Guest
Tue Mar 02, 2010 11:21 am
rickman wrote:
Quote:
On Mar 1, 5:38 am, "Nial Stewart"
Even so, I have *never* had to respin a board because of SI issues. A
full blown simulation tool is not the only way to analyze this sort of
stuff, regardless of what you will hear. Heck how often do you even
have the full details of your loading to use with a high end tool?
Even so, I have *never* had to respin a board because of SI issues. A
full blown simulation tool is not the only way to analyze this sort of
stuff, regardless of what you will hear. Heck how often do you even
have the full details of your loading to use with a high end tool?
I haven't seen a complex board without need for respin and SI is one
of the reasons quite often. For me complex board is 15+ layers, high
speed busses (600+MHz DDR), differential gigabit traces, board full of
components and quite big boards. Even with simulation there are
suprises, but the more time is spent on simulation the better quality
the board usually is.
Especially crosstalk is a real problem in complex boards, and without
automatic batch simulation quite impossible to handle without very
conservative design rules. And with too conservative rules the designs
do not to fit to the boards.
It quite normal in complex boards to have ibis models for most of
the chips already in the component database, and some defaults for
others and layout is extracted from the design databases. In the
more expensive tools the flow has been automated in recent years.
Next stage is power integrity simulation of the boards. With hundreds
of amps of current the power distribution is a real problem and
hard to analyze.
--Kim
elektroda.net NewsGroups Forum Index - FPGA - Frustration with Vendors!
