From: Bo ([email protected])
Date: Fri Nov 24 2000 - 10:30:02 PST
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
****
This archive was generated by hypermail 2b29 : Tue May 08 2001 - 14:30:14 PDT