--- Quote Start ---
Possibly stall/rerun the PCI transfer for long enough to setup the race condition?
PCIe will never be low latency. A PCIe request is an hdlc frame containing the address, length (etc) and any data, this has to be decoded and verified (etc) before being actioned and then the response hdlc frame generated. All this takes time.
To efficiently use PCIe the whole logical interface has to be arranged to use DMA wherever possible and to minimise the number of PIO reads.
--- Quote End ---
Thanks , DSL,
I'm not really interested in throughput on the PCIe link. I am interested in exercising a bridge inside a SOC which has PCIe data passing through
it. The Producer / Consumer test is used to stress PCI ordering rules in the bridge and in the case I am looking at .. that Posted writes to
my FPGA endpoint memory stay ahead of Read completions , where the Read was initiated by the FPGA and if the read returns a '1', indicates the
data at the FPGA memory is valid. Since I see a ~900 nS Read -> Read completion delay, the only way my test will mean anything is if the Posted
Writes get backed up in the bridge when the Read for the Read completion arrives at the bridge.
So ... I assume I can't do much about the ~900 nS read latency and I will look at the PCIe complier to minimize the tokens for the write buffer .
I hope this will put back-pressure on the bridge I am testing and cover the ~900 nS of Read latency.
Thanks For your input.
( BTW: I was at Hemel Hempstead for 18 months at Marconi /GE and really liked it ).
Honored Contributor
