From: Bo ([email protected])
Date: Tue Nov 21 2000 - 06:29:36 PST
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
> 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 to
> redo
> > simulations since the topology changed from the last time simulations were
> > done.
> > Someone also pointed out that one of the drivers didn't look good in the
> > simulations he performed earlier on another bus and that my bus should be
> > looked at more carefully.
> > I took the old simulations and modified them to represent current topology
> (the
> > simulations were done in Hspice). I noticed that previous simulations were
> > using an old U-model for transmission lines so I changed transmission lines
> 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 Bridge
> 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 highest
> > undershoot is seen on the PPMC750). My first guess was that I made mistake
> in
> > modeling the bus so I asked someone else to check the simulation deck. No
> > mistakes (the other person is VERY experienced in HSPICE simulations and
> 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 make
> sense.
> > I looked at my spice deck and started thinking what may be different. I
> 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 buffers
> to
> > be put instead of normal ones. So I tried these. As I expected the fall
> time
> > and rise times increased and signal become much cleaner. The undershoot
> 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 same
> as
> > the ones in the lab. What I have seen in lab is 4 ns Fall time and 6 ns
> Rise
> > time. The simulations have 1.6 ns rise time and 1.3 ns. If I use slew
> rate
> > limited Fall time is 8 ns and rise time is 2 ns (all numbers are 0-100%).
> > This is were my problem lies: I can't guarantee that next set of devices
> 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). Is
> 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 capacitive
> load of
> > 180 pf to ground in front of a driver. This produced a clean edges and
> > comparable undershoot values (not exactly the same waveform as in the lab
> 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 of
> 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.
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:12 PDT