|
Message
From: Andreas Ehliar<ehliar@i...>
Date: Fri Mar 3 16:38:33 CET 2006
Subject: [pci] Issues with the PCI core
Hi,
we are having some issues with the PCI core (configured as GUEST):
First, a performance problem:
If we (via burst writes from the WB side to the PCI side) fill up the
asynchronuous fifos in the core the performance will go from high to
very low and never recover. The reason is that the asynchronuous
fifos do not deal with anything less than a complete burst
transaction. If the complete burst fits into the FIFO all is
well. However, if the burst does not fit into the fifo, the logic
around the fifo will end the burst transaction and start a new burst
transaction as soon as there is new space in the fifo. This new burst
will not be very long since there is very little space in the fifo at
this point.
This means that as soon as the fifo is full we will not be able to
write a long burst into the fifo until it is relatively empty. Since
we will continue writing short bursts into the fifo, the PCI side will
only issue short bursts and therefore taking a very long time to drain
the fifo.
An illustration of what this problem looks like is located at
http://www.da.isy.liu.se/~ehliar/opencores/pciburststuff.png
Source code for the testbench is at:
http://www.da.isy.liu.se/~ehliar/opencores/pciburststuff.tar.gz
Perhaps this is the reason why some people claim that the core has
poor performance? How much work would it be to modify the core to be
able to merge burst transactions?
Another problem I have is that I get very low performance if I use the
WB Rev B3 compliant burst signals cti and bte. Has anyone besides me
tried this and gotten good performance? My understanding is that there
is some interface logic that is supposed to convert cti and bte to
cab-compatible signalling. Unfortunately, it seems as if this convert
only outputs a new valid word every three cycle.
Finally, we are trying to track down a bug in our system and I'm a bit
nervous about the asynchronuous fifos in the PCI core. Mainly because
I'm always nervous about clock domain crossings.
A first glance at the code shows that grey counters are in use for
every signal crossing the clock domain. But reading through the code I
noticed that there are two grey counters:
* A transaction counter
* A word counter
This means that even though a single grey counter is safe for clock
domain crossing it does not mean that two grey counters will be
coherent with each other after passing a clock domain. So what I'm
wondering is if the author of this code has thought of this case and
is certain that it will never be a problem if these two counters are
out of sync.
/Andreas
|
 |
Browse
