[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: PCI design in Xilinx Spartan II is intermittently crashing

Hi Daniel,
I would like to help you.

1. You don't have to do the work you have done now to reduce logic. The
key point here is to latch waveform around the crasy point. It needs
some experiences. 

2. Please latch necessary graph using any logic analyzer or PCI bus
analyzer and send me the file.


-----Original Message-----
From: Daniel Weaver [mailto:dan.weaver@znyx.com] 
Sent: Friday, March 15, 2002 9:31 AM
To: pci-sig@znyx.com
Subject: PCI design in Xilinx Spartan II is intermittently crashing

>>>> From: "Support@PixelSmart.com" <support@pixelsmart.com>


I have designed my own PCI logic for a target board.(33/32) It works in
the majority of wintel PCs but crashes in a significant number of PCs.

I have implemented a design in a Xilinx PCI proto board made by Insight.
This way I can assume that the PCB fabrication is sound.

I feel the problem comes down to the way TRDY# and DEVSEL# are being
driven. This is the logic that must be improved.

The crashing occurs with reads. With my exisiting logic one motherboard
may crash while another is ok. On a motherboard that is ok, the addition
of a certain 3rd party PCI card will then result in  crashes. The logic
I have must be on the verge of being PCI compliant. I expect that one
little tweak should be enough to clear up all my problems.

In tracking down the problem I have removed more and more logic to
simplify the design and to narrow in on the cause. Almost all the logic
is now gone. All that remains is:



In this stripped down implementation there are no bursts, no parity, no
master logic, no configuration space ( which is not needed to effect
reads/writes if you know of a conflict free address, which I do for test
purposes ) The logic is very simple. When a read or write is decoded I
take DEVSEL# active low, followed by TRDY#. When IRDY# is seen low I
release TRDY# and DEVESEL# on the next clock.(wintels do not do burst
reads so I know FRAME# will indicate a single data phase cycle)  This
complete test is a trivial and small piece of logic. ( For anyone
designing their own PCI logic this is an excellent first step to try.
Once this works then you would go on to add other features.)  Note that
I am not even driving AD[31:00] on the reads. So the only PCI signals
that I drive in response to a decoded PCI read in my address space is

When a crash occurs it happens on a read but not every read so as you
can see this is erractic.
Note: all PCI input and output signals are clocked.

My schematics will be provided to anyone who requests them.

Is there anyone out there who has gone down this road designing their
own PCI logic for a FPGA ? Come on over. I have a plane ticket for you.
Name your price.

Daniel DeConinck
TEL: 416-248-4473

Dan Weaver, ZNYX Networks