I'm using the OpenCores PCI core in a Spartan3 FPGA. It works very
well, and I haven't run into any compatibility issues with any of the
PC's I've tried it with, and I wrote drivers for it for Windows XP
(using KMDF) and Linux.

I'd be happy to contribute those to OpenCores if there is interest.

One issue I'd like some advice on is improving read latency. For
single 32-bit writes, they complete in about 300ns, which is fine.
For 32-bit reads, they complete in 2.5uS, which is a really long
time. I'm reading and writing to a FIFO, which occupies a single
address on the wishbone backplane.

Some things I've thought about are mapping the FIFO to a separate BAR,
ignoring the lower address bits, and enabling read prefetching, but
figured this might be dangerous since it's a FIFO.

Another thing I considered is doing bus mastering to empty the FIFO
into main memory, but this is a large change to my design.

Any other thoughts on how to proceed?

I tried the pci32tlite core, and it worked ok in some systems, but I
ran into compatibility issues on a Dell Optiplex 700mhz P3 system so I
switched over to the larger OC PCI core.

In my design, the wishbone and PCI are operating from the 33MHz PCI
clock.

Thanks,

-Howard

On 17/02/2008, Howard Harte opencores at dublintrees.com> wrote:

Hi Howard,

I'm interested in having a look at your drivers.

Regards,
Nathan

Howard Harte wrote:



It's been a while since I used the core, but we did some profiling and
analysis because we had similar issues.

By far the most significant factor in read performance is the fact that
all reads are posted, which means the core will immediately disconnect
after latching the address/command. It is up to the chipset on the
motherboard then to decide when to issue a retry to the core in order to
receive the result. We were seeing gaps of 8 more more PCI clocks, for
example, between retries.

IIRC the *absolute* best performance you'll hope to get on reads on an
Intel mobo is around 3MHz (300ns) - or 10 clocks per transfer, due to this
disconnect. For 32-bit reads, that of course equates to 12MBps. The best
we actually measured on our platform was around 9MBps for internal
register accesses, and ~4.4MBps when accessing external SRAM due to the
fact that it required 2 retries/access.

You're seeing the above-mentioned 300ns per write because that likely
corresponds to the gaps between successive commands on the PCI bus as
well. That's pretty much exactly what we saw too.



Mapping to a separate BAR and igfnoring the lower address bits likely
won't make any difference at all.

And you definitely *don't* want to enable pre-fetching, as your
performance will actually drop, as it fetches an entire cache-line from
wishbone space before allowing the retry to resume... we tried that! ;)
Besides, Intel mobo chipsets won't burst on memory reads, so the rest of
the cacheline will *always* be discarded! All that aside, you have a FIFO
so it wouldn't help you at all, unless you did something really dangerous
like alias the read port to multiple consecutive addresses... but then you
have issues on FIFO empty... don't go there...



We had DMA bus mastering for memory access and IDE and the throughput was
limited by the memory/IDE, so I can't recall what the bus utilisation was
during the actual block transfer, but we did see upwards of 16MB/s overall
performance.

Simulate your design and you'll see exactly where your latencies are. Use a PCI bus analyser to look at how often the mobo is attempting to connect to the core and issue retries etc. Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266

Hello Howard, I don't have any compatibility issue reported for the last revision of the pci32tlite IP core. In the first revisión, back-to-back and burst cycles were not supported. It produced hangs on systems using this kind of cycles. Anyway, I'll be grateful if you share you experiences about the pci32tlite IP core. Peio -----Mensaje original----- De: cores-bounces at opencores.org [mailto:cores-bounces at opencores.org]En nombre de Howard Harte Enviado el: domingo, 17 de febrero de 2008 2:00 Para: cores at opencores.org Asunto: [oc] PCI core question I'm using the OpenCores PCI core in a Spartan3 FPGA. It works very well, and I haven't run into any compatibility issues with any of the PC's I've tried it with, and I wrote drivers for it for Windows XP (using KMDF) and Linux. I'd be happy to contribute those to OpenCores if there is interest. One issue I'd like some advice on is improving read latency. For single 32-bit writes, they complete in about 300ns, which is fine. For 32-bit reads, they complete in 2.5uS, which is a really long time. I'm reading and writing to a FIFO, which occupies a single address on the wishbone backplane. Some things I've thought about are mapping the FIFO to a separate BAR, ignoring the lower address bits, and enabling read prefetching, but figured this might be dangerous since it's a FIFO. Another thing I considered is doing bus mastering to empty the FIFO into main memory, but this is a large change to my design. Any other thoughts on how to proceed? I tried the pci32tlite core, and it worked ok in some systems, but I ran into compatibility issues on a Dell Optiplex 700mhz P3 system so I switched over to the larger OC PCI core. In my design, the wishbone and PCI are operating from the 33MHz PCI clock. Thanks, -Howard _______________________________________________ http://www.opencores.org/mailman/listinfo/cores

On Sat, 16 Feb 2008 17:00:22 -0800 Howard Harte opencores at dublintrees.com> wrote:

You might want to give the PCI core from OGP a look.
It was written from scratch because the OC PCI core
was not fast enough. But there are two catches:

1) Although it has been tested, there has AFAIK no
trough out test in different setups and PCs, so
there migh be some compatibility issues lingering.

2) Because wishbone was deemed too slow for OGP,
they use their own internal bus. So you would
have to write some glue logic there.

Attila Kinali

--
The true CS students do not need to know how to program.
They learn how to abstract the process of programming to
the point of making programmers obsolete.
-- Jabber in #holo

>>>>> "Attila" == Attila Kinali attila at kinali.ch> writes: Attila> On Sat, 16 Feb 2008 17:00:22 -0800 Howard Harte Attila> You might want to give the PCI core from OGP a look. It was Attila> written from scratch because the OC PCI core was not fast Any pointers to the OGP core? Thanks -- Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

On Mon, 25 Feb 2008 12:03:14 +0100 Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de> wrote:

Attila> On Sat, 16 Feb 2008 17:00:22 -0800 Howard Harte
Attila> You might want to give the PCI core from OGP a look. It was
Attila> written from scratch because the OC PCI core was not fast

Any pointers to the OGP core?