Re: [SI-LIST] : PCI Bus problem (an interesting one) Thanks! (summary)

About this list Date view Thread view Subject view Author view

From: Scott McMorrow ([email protected])
Date: Fri Nov 24 2000 - 10:30:58 PST


Welcome to the world of autorouters!

Bo wrote:

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

--
Scott McMorrow
Principal Engineer
SiQual, Signal Quality Engineering
18735 SW Boones Ferry Road
Tualatin, OR  97062-3090
(503) 885-1231
http://www.siqual.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 ****


About this list Date view Thread view Subject view Author view

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