From: Ted Mido ([email protected])
Date: Mon Nov 20 2000 - 12:57:52 PST
Dear,
If you don't set "delmax" option, setting .option delmax
to limit the time step to 0.5-1 of the excitation transient
may help you to get better simulation result.
regards,
: Ted Mido
: Avant! Corporation (Oregon R&D)
: 9205 SW Gemini Drive
From: Bo <[email protected]>
Subject: [SI-LIST] : PCI Bus problem (an interesting one)
Date: Mon, 20 Nov 2000 11:35:27 -0800 (PST)
> 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