From: Michael Nudelman ([email protected])
Date: Tue Nov 21 2000 - 08:22:18 PST
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.
> 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.
> 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.
> --- 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.
**** 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