From: George Borkowicz (email@example.com)
Date: Tue Nov 21 2000 - 07:16:05 PST
First I second Scott's comments. Make sure you use the IBIS
models correctly in HSPICE.
Second if you want to I can send you "ibised" PCI spec. I find
it much easier and more reliable to design PCI structures using
such a generic approach than relying on vendors models. By
the end of the day all they have to do is be compliant (ouch!).
> -----Original Message-----
> From: Bo [SMTP:firstname.lastname@example.org]
> Sent: Tuesday, November 21, 2000 9:30 AM
> To: Michael Nudelman
> Cc: email@example.com
> Subject: Re: [SI-LIST] : PCI Bus problem (an interesting one)
> Hi Micheal,
> Thanks for the reply.
> What I am using is a PCI "compliant" devices. At least according to the
> specs say. I am using PCI I/O buffers provided with each device(and that
> what I am using in the simulations). I asked someone to look at the specs
> the devices, and guess which one was the only one that meet PCI specs
> 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
> rise/fall times and I do not expect to see either to be faster than 1ns.
> respect to the slew rates, I can limit slew rate on Altera's Apex 20k but
> 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
> each output buffer is reduced to minimize power bus transients when
> non-critical signals. The SLEW= property has one of the two following
> If I can slew rate limit PCI output buffers on Virtexe please tell me. I
> be misunderstanding specs I am reading. I hope I am.
> --- Michael Nudelman <firstname.lastname@example.org> wrote:
> > Bo,
> > As I understand, your problem stems from using non-PCI devices on the
> > bus.
> > However, it may not be a problem, since both Xilinx and Altera do
> > PCI-core
> > designs for their devices (or at least that's what they told me 3 years
> > when I
> > was making a PCI bus) and thus should (at least in theory) guarantee,
> > their
> > drivers will be compatible with the PCI driver specs.
> > As I also remember, the fastest edges of these devices never exceeded
> > (at
> > least in practice). The slow slew-rate option (both Altera CPLDs and
> > FPGAs
> > have that) shoul possibly take care of this. As I understand, it is
> > 3-4ns,
> > the so called "slow slew rate adder" for XILINX FPGA being about 2ns
> > 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
> > 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
> > 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:
> > 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
> > 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
> > option. A short PCI bus (and yours is not that long - I had it 4 times
> > at the
> > same rate) exhibits wonders of willpower to survive the most insulting
> > 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
> > > before.
> > > The bottom line to the problem is what to do when simulations show you
> > > 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
> > 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
> > 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
> > did:
> > > "O this is easy, it is only 33 MHz (PCI is supposed to work at 66 MHz)
> > it
> > > is only 32 bit wide". To make life even easier there were test cards
> > not
> > > so long ago that had a similar setup (same devices but little
> > 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
> > I
> > > thought that way...
> > > What happened next was that in early stages of design someone did
> > simulations
> > > that showed relatively nice waveforms. Few months later I was asked
> > redo
> > > simulations since the topology changed from the last time simulations
> > > done.
> > > Someone also pointed out that one of the drivers didn't look good in
> > > simulations he performed earlier on another bus and that my bus should
> > > looked at more carefully.
> > > I took the old simulations and modified them to represent current
> > (the
> > > simulations were done in Hspice). I noticed that previous simulations
> > > using an old U-model for transmission lines so I changed transmission
> > to
> > > use W-element. Also previous simulations modeled PPMC750 as a cap and
> > resistor
> > > in parallel so I replaced this model with an IBIS model of the PCI
> > used
> > > on this card. So I redid simulations and all of sudden I got severe
> > undershoot
> > > of 2V(this happens when both Xilinx and Altera drive the bus and
> > > undershoot is seen on the PPMC750). My first guess was that I made
> > in
> > > modeling the bus so I asked someone else to check the simulation deck.
> > > mistakes (the other person is VERY experienced in HSPICE simulations
> > tow of
> > > us went through the deck line by line). Next step was to go to the
> lab and
> > > look at the similar PCI bus. I went to the lab with another person
> and we
> > > looked at the bus. What we saw was something that you can only see in
> > > university undergraduate digital courses. Signal had the cleanest
> edges I
> > have
> > > ever seen. Nice perfect lines. There was though overshoot of around
> 400 mV
> > and
> > > undershoot of around 600 mV. At the time what I had was 600mV of the
> > > undershoot in the lab and 2V in the simulations. Something didn't
> > sense.
> > > I looked at my spice deck and started thinking what may be different.
> > looked
> > > at devices to see if they may be using different I/O buffers than what
> I am
> > > simulating. I found that Altera FPGA allows slew rate limited I/O
> > to
> > > be put instead of normal ones. So I tried these. As I expected the
> > time
> > > and rise times increased and signal become much cleaner. The
> > was
> > > gone. So I went to look in the lab to see if this may be the case.
> > > Unfortunately the fall/rise times in the simulations labs were not the
> > as
> > > the ones in the lab. What I have seen in lab is 4 ns Fall time and 6
> > Rise
> > > time. The simulations have 1.6 ns rise time and 1.3 ns. If I use
> > rate
> > > limited Fall time is 8 ns and rise time is 2 ns (all numbers are
> > > This is were my problem lies: I can't guarantee that next set of
> > will
> > > have the same rise times. The device manufacturers do not want to
> > guarantee
> > > that their devices will work under conditions I see in the
> simulations. I
> > am
> > > not sure that device models are correct. Someone suggested putting a
> > resistor
> > > in series with the bus (on the board 1 in front of the connector 1).
> > this
> > > right thing to do? What is right thing to do? For a final note, to
> get a
> > > approximately lab's rise/fall times from simulations I put a
> > load of
> > > 180 pf to ground in front of a driver. This produced a clean edges
> > > comparable undershoot values (not exactly the same waveform as in the
> > but
> > > with similar quality). This leads me to think that the models or I
> are not
> > > taking something in to account. But I can't imagine anything that
> would be
> > 180
> > > pf big.
> > >
> > > Well, I would like to thank anybody who read this email. I hope some
> > you
> > > will be able help me in resolving my problem. Comments are greatly
> > appreciated
> > > (even the smallest ones).
> === message truncated ===
> Do You Yahoo!?
> Yahoo! Shopping - Thousands of Stores. Millions of Products.
> **** To unsubscribe from si-list or si-list-digest: send e-mail to
> email@example.com. 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
firstname.lastname@example.org. 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:13 PDT