From: Michael Nudelman ([email protected])
Date: Mon Nov 20 2000 - 15:18:34 PST
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).
>
> Regards,
> Bo
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Calendar - Get organized for the holidays!
> http://calendar.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
> ****
**** 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