Re: PCI design in Xilinx Spartan II is intermittently crashing

["Venkateshwaralu V" <venkateshwarluv@myw.ltindia.com>]

** Proprietary **

Hello Mr.Daniel,
I tried to analyse ur problem.Iam not finding any source for the crash.I developed PCI 32/33 Target on SPARTAN-II, and tested on Intel motherboard.I designed PCB also with spartan-II.I din't find any problem on reads or writes.Pls. provide me your schematic,I will try to analyze.


Thanks,
Venkat


>>> Daniel Weaver <dan.weaver@znyx.com> 03/15/02 11:16PM >>>
>>>> From: "Support@PixelSmart.com" <support@pixelsmart.com>

Hello,

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:

OUTPUTS:
TRDY#
DEVSEL#

INPUTS:
FRAME#
IRDY#
AD[31:00]
C/BE[3:0]#
CLK

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 DEVSEL# and TRDY#.

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.

Sincerely
Daniel DeConinck
www.PixelSmart.com 
TEL: 416-248-4473

-----------------------------
Dan Weaver, ZNYX Networks
dan.weaver@znyx.com