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

Hello,

I used to experience the performance problem reported below by Andreas
Ehliar in this mailing-list.
I have fixed this issue by following Ehliar's suggestion -see below. If
someone is interested drop me an e-mail.

Regards,
Robert Lluis

Here are the files, again.
The lines I added are signaled with the tag "burst issue".

Robert
-------------- next part -------------- A non-text attachment was scrubbed... Name: burst_issue_files.zip Type: application/x-zip-compressed Size: 25950 bytes Desc: not available Url : http://www.opencores.org/forums.cgi/pci/attachments/20060704/4cb67ddd/burst_issue_files-0001.bin

Thanks! Will try it out now /S-E On 7/4/06, Robert Lluís rlluis at promax.es> wrote: -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums.cgi/pci/attachments/20060704/385b8b40/attachment.html