PCI speed.

Hi.

I have a PCI board developed and I have little acess to the FPGA PCI core, since it was not developed in house. I can say it makes no burst accesses. My proble is that I used to have a reasonable speed with these boards with athlon/semprom boards, regardless of chipset. After the chipsets/processors changed to socket 754 and 939 (and got HyperTransport, but I don't know whether it's related) i got a 20% speed drop, a little too much. With the nForce4 chipset I may get to the same speed as before, but I can't achieve it with a stable bandwidth. I don't have any intel boxex around to test with it. Does anyone has any clue on what's going on (even better, a solution)?

Thanks, Ricardo

Reply to
Ricardo
Loading thread data ...

Do you have a PCI Analyzer? If you're a PCI target, I wonder if you're getting an abort and a retry on occasion for data that your design doesn't supply fast enough. I thought the abort period was somewhat programmable in some PCI bridges.

Reply to
John_H

John_H, I disagree your opinion.

PCI traffic and performance heavily depends on chipset system. We observed that board with same PCI designs may have dramatic speed changes on different chipsets. Chipsets from some manufactures have a better performance, some have bad performance. Usually the latest version of chipsets will have a better performance over older versions for the same manufacture.

It is first time to hear that in a new chipset system, there is a 20% speed decrease. It means to me that most likely the new chipset has a different schedules than before that may put PCI transactions 1 level of order of delay. For example, for older version of chipset, the schedule algorithm in the chipset selects next request to go based on their arrival time from a incoming queue; for newer version of chipset, the schedule algorithm in the chipset may change to response PCI request after 4 CPU requests are answered. If so, it would appear and report that CPU gets faster performance while sacrificing PCI environment that nobody pays attention to.

I don't know why 20% speed reduction really is. That must be confirmed by PCI bus analyzer. But the reason John_H indicated is the least likely real reason.

You can imagine with faster DDR/DDR II system, possible two channels of them and much higher working frequency, a 20% performance decrease cannot be blamed on the board side.

Weng

Reply to
Weng Tianxiang

Ricardo schrieb:

Is your board handling the transactions as initiator or target? If it is a target, the burst length is controlled by the CPU. AFAIK the best you can do with IA32 is a burst of length four by using SSE 128 bit moves.

If your board is the initiator, it controls the burst length, but the chipset could abort or retry transaction to enforce shorter burst. But I doubt that it will do that below a length of four.

Use chipscope to have a look at what happens on the bus.

Kolja Sulimma

Reply to
Kolja Sulimma

since it was not

used to have a

chipset. After the

I don't know

nForce4 chipset I may

bandwidth. I don't have any

Have you played about with the BIOSs of the two systems to see how the PCI inerfaces are configured? This might be worth looking at, from memory there are a few PCI parameters that you can play about with here and this might improve your performance somewhat.

Nial.

---------------------------------------------------------- Nial Stewart Developments Ltd Tel: +44 131 561 6291

42/2 Hardengreen Business Park Fax: +44 131 561 6327 Dalkeith, Midlothian EH22 3NU
formatting link
Reply to
Nial Stewart

The biggest issues I've had with this is board capability detection. I have some boards that are supposed to run PCI64 @ 66MHz. However, in some motherboards they are detected as 32bit wide at 66MHz or 64 bit wide at 33MHz. In both those cases I lose 20-30% of the speed. There should be a way to determine which mode your board is running in, or if all else fails scope the clock pin and REQ64/RST signals at boot.

Reply to
Brannon

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.