RE: [SI-LIST] : PCI Bus problem (an interesting one) Thanks! (sum mary)

About this list Date view Thread view Subject view Author view

From: [email protected]
Date: Mon Nov 27 2000 - 11:45:37 PST


All,

I was a "late bloomer" in coming to the world of simulation, routing and EDA in
general
after a long career in engineering before any of those tools were any real good.
I think such
tools are wonderful. They (mostly) don't make stupid math mistakes, handle
complexity well,
etc.

Back before today's programs and computer power we had some engineers with an
over reliance on paper and some with an over reliance on flying by the seat of
their
pants at the bench. That the same thing continues today under somewhat different
guises seems evident to me.

The only real problem with EDA today is that it can be so much fun and seemingly
so
infallible that it can easily lead to the same kind of errors as yesterday that
resulted
from not checking input and not checking to see if modeling assumptions are
still valid.

Likewise, when you tinker too much without clear guiding principles (constraints
guided by
understanding) it will lead to "bailing wire and spit" that will fall apart at
the first challenge
such as getting the network boxed up and in a product. That is, assuming you get
the thing
to work without understanding what you're doing in the first place.

Less I come across as infallible, I wish I had a nickel for every time I've been
unpleasantly surprised at the wrong assumptions I've had and didn't even know I
had
about something I was troubleshooting.

Best Regards,

Roy

"Willis, Ken" <[email protected]> on 11/27/2000 08:00:59 AM

Please respond to "Willis, Ken" <[email protected]>

Sent by: "Willis, Ken" <[email protected]>

To: "'Bo'" <[email protected]>
cc: [email protected] (Roy Leventhal/MW/US/3Com)
Subject: RE: [SI-LIST] : PCI Bus problem (an interesting one) Thanks! (sum
      mary)

Hi Bo,

Just my opinion, but I think autorouting gets a bad rap. I agree,
if you let a machine randomly route your signals, who knows what
you will get. I think a lot of people have had this experience in
the past, and it sours them on autorouting. But just like a
simulator, if you give it lousy input you will get garbage back.

But if you provide detailed (and realistic) topology/constraints
to the autorouter, it can be a great ally. I recently had a design
I inherited that had been hand-routed (also with no topology rules,
resulting in lousy SI results) over a period of several weeks. I
basically started it over, set up how each of the major classes of
signals should be routed, and our service bureau autorouted it from
scratch in less than an hour. I simulated the whole board and it came
out great. Soup to nuts we re-spun the board over about 2 days.

Autorouters certainly aren't perfect, require some cleanup, and are
NOT the answer for all classes of signals. But if you set 'em up
right they can speed up your process a lot on certain types of designs.
And setting up the constraints has the nice side benefit of letting you
DRC your design forever, including after future ECOs.

Ken

-----Original Message-----
From: Bo [mailto:[email protected]]
Sent: Friday, November 24, 2000 1:30 PM
To: Michael Nudelman
Cc: [email protected]
Subject: Re: [SI-LIST] : PCI Bus problem (an interesting one) Thanks!
(summary)

Hi Everybody,

I would like to thank Scott McMorrow, Tony Dunba r(thanks for the offer you
have made), Michael Nudelman, George Borkowicz, Andrew Ingraham, John Medina
and others for the replies that they have sent to my post. All the replies
have helped me to resolve my problem. Here is how it went:

Few of you have clearly pointed out that there should be a problem with the
models itself. I went and checked them once again after people indicated
that
could be a problem. So I looked and looked and looked. And found nothing.
I read all the emails I received regarding this problem and still couldn't
think what else should I do. It was getting to be very, very frustrating.
After running X number of simulations I still could not find the
discrepancy.
Well believe it or not I got a break. The break came in the view of
somebody
pointing out to me something that I didn't think of. But let me go back to
explain what I did that caused this mistake. What I simulated was the
current
topology that was to be implemented on new board. What I looked at in the
lab
was a board that implemented a PCI bus using same components and similar
placement (positioning of the components of the board relative to each
other)
and same board stickup. Somebody reading this will probably guess my
mistake
in advance before reading next few sentences. Well the break came when
someone
complained to me that reset line used in PCI bus for the card was 34 inches
long! My comment to that was: "Wait a second, the placement of components
would
make that bus no longer that 8-10 inches!" So I went to look at the layout
of
the PCI bus on the lab card and I found that bus was 18-25 inches long
rather
than 8-10 that I thought. What I had was a "o so popular" case of auto
router
doing routing when no constraint was put on the bus. I was comparing apples
(my simulations) with oranges (lab measurements). So I went and extracted
the
topology from the lab and made simulations on it. So I went in to great
detail
to model the lab topology. That paid off because I finally got simulations
to
look similar to the measurements in the lab. So I then went back to the
topology for the new board and made sure that all things are carefully
modeled.
And guess what? It gave good results. What is left now is to make sure that
someone to make sure that auto router doesn't do poor job on the topology.

In all I will summarize what I have found out while solving this problem:
- Do NOT trust Auto router. Just because a net is not critical one it
doesn't
mean that it you can let Auto router do with it whatever it likes. This was
my
mistake for believing that placements are the same for both topologies.
- This was purely my mistake: Assuming just because a bus is slower in
speed
(than the ones I typically analyze) I can model it with little less detail.
A
big mistake on my part. I had to go through whole lot of detail to get
correct
values.
- Whenever you compare anything watch what you are comparing. The "similar"
as
word should be used very carefully. Just because somebody claims that the
something is similar to something else that may not be true.
- It is very hard to beat statement "It works in the lab". Very hard. Some
people are very hard on convincing that what you see on one board may not be
the case on the next board.

Thanks once again for all the help. It is greatly appreciated (especially
when
someone is really frustrated).

Regards,
Bo

--- Michael Nudelman <[email protected]> wrote:
> Bo,
>
> I am not a Virtex specialist, but I inquired our own Virtex specialist,
and
> she
> told me, that there is the slew rate control for all FPGAs.
>
> I also looked at the XILINX APPLINX CDROM, and it did not specifically
> mentioned
> slew rate control just for LVTTL - it mentioned it referring to all
devices.
>
> I hope I'm not misleading you.
>
> Mike.
>
> Bo wrote:
>
> > Hi Micheal,
> >
> > Thanks for the reply.
> >
> > What I am using is a PCI "compliant" devices. At least according to the
> vendor
> > specs say. I am using PCI I/O buffers provided with each device(and
that
> is
> > what I am using in the simulations). I asked someone to look at the
specs
> for
> > the devices, and guess which one was the only one that meet PCI specs
> fully?
> > Intel of course since it was Intel who designed initial PCI spec.
> > I didn't see either simulations or lab measurments to be below 1 ns for
the
> > rise/fall times and I do not expect to see either to be faster than 1ns.

> With
> > respect to the slew rates, I can limit slew rate on Altera's Apex 20k
but
> can't
> > do the same on Xilinx Virtexe FPGA. Virtexe allows slew rate limiting
only
> for
> > LVTTL devices (here is quote from the data sheet for virtex-e devices:
> >
> > "...As mentioned above, a variety of symbol names provide the option of
> > choosing the desired slew rate for the output buff-ers. In the case of
the
> > LVTTL output buffers (OBUF, OBUFT, and IOBUF), slew rate control can be
> > alternatively programed with the SLEW= property. By default, the slew
rate
> for
> > each output buffer is reduced to minimize power bus transients when
> switching
> > non-critical signals. The SLEW= property has one of the two following
> values.
> > SLEW=SLOW
> > SLEW=FAST
> > ...."
> >
> > If I can slew rate limit PCI output buffers on Virtexe please tell me.
I
> might
> > be misunderstanding specs I am reading. I hope I am.
> >
> > Regards,
> > Bo
> >
> > --- Michael Nudelman <[email protected]> wrote:
> > > Bo,
> > >
> > > As I understand, your problem stems from using non-PCI devices on the
PCI
> > > bus.
> > > However, it may not be a problem, since both Xilinx and Altera do
provide
> > > PCI-core
> > > designs for their devices (or at least that's what they told me 3
years
> ago,
> > > when I
> > > was making a PCI bus) and thus should (at least in theory) guarantee,
> that
> > > their
> > > drivers will be compatible with the PCI driver specs.
> > >
> > > As I also remember, the fastest edges of these devices never exceeded
> 1ns.
> > > (at
> > > least in practice). The slow slew-rate option (both Altera CPLDs and
> XILINX
> > > FPGAs
> > > have that) shoul possibly take care of this. As I understand, it is
> around
> > > 3-4ns,
> > > the so called "slow slew rate adder" for XILINX FPGA being about 2ns
> itself,
> > > plus
> > > capacitive de-rating for over 50pF.
> > >
> > >
> > > But the problem is not just that. The slew rate is not necessary
> > > representative of
> > > the output resistance. Main characteristic of teh PCI driver not so
much
> a
> > > slow
> > > slew rate as it is high output Z. Which is ideally is equal to the
char.
> Z of
> > > the
> > > transmission line. So it will create half-step in the beginning.
> > > And you also can have your fast slew rate, so you will shave
nanosecond
> or
> > > two of
> > > your setup time budget.
> > >
> > > So, the thought of adding resistors is not that bizarre.
> > >
> > > So, if you have extra pins in your FPGA, this is what I would try to
do:
> use
> > > fast
> > > slew rate drivers with series term. resistors as outputs, and directly
> > > connected to
> > > a PCI line input (without the resistor). THis way you can have your
"fast
> > > whimpy"
> > > driver and the input, that is not slowed down by the RC of its own
> > > capacitance and
> > > the series resitor (the driver is tri-stated). Of course, your pin
count
> > > doubles.
> > >
> > > However, I think you may be safe the way you are now, if using slow
slew
> rate
> > > option. A short PCI bus (and yours is not that long - I had it 4 times
> that
> > > at the
> > > same rate) exhibits wonders of willpower to survive the most insulting
> ways
> > > to
> > > design it.
> > >
> > > Last:
> > >
> > > In this:"As I expected the fall time and rise times increased and
signal
> > > become
> > > much cleaner." - You did mean "decreased", right?
> > >
> > >
> > > Mike.
> > >
> > > Bo wrote:
> > >
> > > > Hi Everybody,
> > > >
> > > > I have an interesting problem that probably a lot of you have
> encountered
> > > > before.
> > > > The bottom line to the problem is what to do when simulations show
you
> much
> > > > worse results than measurements do. But lets start with facts...
> > > >
> > > > PCI bus in question has 4 devices on it:
> > > > - Xilinx Virtexe FPGA
> > > > - Altera Apex 20K FPGA
> > > > - Intel (made originally by DEC) Ethernet controller
> > > > - Motorola PPMC750 card
> > > >
> > > > The bus is running at 33 MHz and is 32 bits wide (Address/Data
portion
> of
> > > it).
> > > > Xilinx FPGA is on board 1 while other three devices are on the board
> > > 2(Motorola
> > > > PPMC750 is connected to board 2 through connectors). All the
devices
> can
> > > drive
> > > > the bus.
> > > >
> > > > The topology looks something like this:
> > > >
> > > > X------C1---C2----A----I
> > > > |
> > > > M
> > > >
> > > > X - Xilinx FPGA
> > > > C1 - Connector 1 that connects two boards (Mictor in this case)
> > > > C2 - Connector 2 connecting Motorola PMC750 card and Board 2
> > > > M - Motorola PPMC750
> > > > A - Altera FPGA
> > > > I - Intel
> > > >
> > > > Distances:
> > > > X->C1 = 3 inches
> > > > C1->C2 = 1 inch
> > > > C2->A = 3 inches
> > > > A->I = 2 inches
> > > > Note:
> > > > C2->M = 2.5 inches (where this distance represents distance between
> > > connector
> > > > and PCI bridge on the PPMC750 card).
> > > >
> > > > Well from all this information most of people would think the same
way
> I
> > > did:
> > > > "O this is easy, it is only 33 MHz (PCI is supposed to work at 66
MHz)
> and
> > > it
> > > > is only 32 bit wide". To make life even easier there were test
cards
> done
> > > not
> > > > so long ago that had a similar setup (same devices but little
different
> > > lengths
> > > > by a little I mean no more than 2 inches differences which may still
me
> a
> > > lot
> > > > in some cases). And it worked. It all sounds like solved case. At
> least
>
=== message truncated ===

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

**** To unsubscribe from si-list or si-list-digest: send e-mail to
[email protected]. In the BODY of message put: UNSUBSCRIBE
si-list or UNSUBSCRIBE si-list-digest, for more help, put HELP.
si-list archives are accessible at http://www.qsl.net/wb6tpu
****

**** To unsubscribe from si-list or si-list-digest: send e-mail to
[email protected]. In the BODY of message put: UNSUBSCRIBE
si-list or UNSUBSCRIBE si-list-digest, for more help, put HELP.
si-list archives are accessible at http://www.qsl.net/wb6tpu
****

**** To unsubscribe from si-list or si-list-digest: send e-mail to
[email protected]. In the BODY of message put: UNSUBSCRIBE
si-list or UNSUBSCRIBE si-list-digest, for more help, put HELP.
si-list archives are accessible at http://www.qsl.net/wb6tpu
****


About this list Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Tue May 08 2001 - 14:30:16 PDT