IFC GPCM normal mode gap between successive transactions

[BillKnight]

Hi

We have T1024 processor communicating with an FPGA using the IFC in GPCM (normal) mode.  Each individual transaction works as expected, but when we attempt to perform transactions back-to-back, we see the Chip Select signal go inactive between each transaction for 4 external IFC clocks for a write or 10 external IFC clocks for a read - and such long gaps significantly reduce the data transfer rate that we can achieve across that interface.

We are using a clock divide value of 3 (IFC_CCR[CLKDIV]="0010"), a port size of 16-bits (IFC_CSPRn[PS]="10"), and are using timed transactions rather than acknowledgement mode (IFC_CSORn[RGETA]=IFC_CSORn[WGETA]='0' with IFCTA_B tied inactive).

To perform back-to-back transactions we use DMA, but we see exactly the same issue if we simply perform a 32-byte read or write (with burst mode disabled) - the hardware converting this into two 16-bit operations for us, but with the same gap in-between.

We also get the same gaps between transactions if we use burst mode (although there are no gaps within each individual burst transaction of course!)

FWIW we did not see the same issue with the "enhanced local bus controller" in GPCM mode on a P1025 processor (which has less configurable timing than the IFC in the T1024).

My question is: is there any way we reduce the inactive time on the Chip Select outputs between transactions (ideally to just a single IFC output clock)?

I guess it might help if anyone could explain why we get these gaps between transactions - or at least if anyone else can confirm if they see the same behaviour or not?

Any help/insight would be greatly appreciated!

Thanks, Bill.

[BillKnight]

Thank you for your reply yipingwang, even if all you really said was "read the manual"!

Incidentally, we don't have a problem with IFCTA_B in GPCM mode - we have used the IFC both configured in acknowledgement mode and configured in abort mode (although in abort mode we never trigger an abort so we tie IFCTA_B inactive), and both work as expected.

We understand the fields such as TRAD and TACO, and these affect the transaction as expected - but they only affect the timing within a transaction rather than between transactions.

But prompted by your response, we looked in the reference manual again for any registers that might affect the gap between transactions - and we did indeed find two, both related to "bus turn-around" and therefore only affecting the gap after a read.

These are: IFC_CSORn [TRHZ] and IFC_GCR [TBCTL_TRN_TIME], and some experimentation has indeed shown that these do make a difference to the CS inactive time between consecutive read transactions.

We did not look at these settings closely before as the description of their effect (described in section 23.4.5 "Data buffer control (BCTL)") seems to assume that the BCTL signal is enabled and describe it in relation to Flash modes, whereas we disable the BCTL signal by setting IFC_CSORn [BCTLD] to '1' and we are of course using GPCM mode not a Flash mode.

But we are disappointed that the reference manual indicates that the minimum delay configurable by IFC_CSORn [THRZ] is "20 IP Clocks" (for the TRHZ field set to "000"). As we use a divide ratio of 3, that is 6.66 IFC output clocks, which does indeed match the increase in CS inactive time between consecutive reads compared to between consecutive writes. We tried TRHZ field values of "001" and "010" for 40 & 60 IP Clocks respectively, and the gap between consecutive read transactions did indeed increase by about 7 & 14 IFC output clocks respectively, so we do know that this field is having an effect.

IFC_GCR [TBCTL_TRN_TIME] also affected the gap between consecutive read transactions, but this is not a problem for us as we can set it to zero anyway.

I am prepared to believe that the gap between write transactions is probably fixed and we have no control over it from any registers (but please let me know if I am wrong here).

So, my question becomes simply:

Is the CS inactive time after a read transaction really a minimum of 20 IFC IP Clocks as selected by an IFC_CSORn [TRHZ] field value of "000", or is there any way we can select a shorter time?

I look forward to a reply, although I rather expect that the answer is "no, you are stuck with a minimum of 20 IFC IP clocks", and we will just have to put up with a greatly reduced throughput when reading over this interface.  We can mitigate this a little using burst mode, but we regard this as a significant degradation in performance over the interface on the older P-series processors.

Thank you for the support in any case!

Cheers, Bill.

[yipingwang · Accepted solution]

In the case of a read transaction,yes, the minimum CS (chip select) inactive time after a read transaction is fixed at 20 IP clocks when TRHZ = 000. For further optimization , we recommend utilizing the IFCTA_B signal.
For write transactions in burst mode, is the Chip Select (CS) signal is being deasserted during the burst? Also ask the customer to share the waveforms and dump of the registers that are being programmed during the write operation.

[BillKnight]

Thank you for confirming the minimum CS inactive time after a read transaction.

We use burst mode to improve performance, which has worked out OK.  Fixed timing is convenient for us, so we have not had to use IFCTA_B.

[yipingwang]

Firstly, customer is required to enable IFCTA_B in GPCM mode.
To reduce the inactive time on the Chip Select outputs between the transactions,kindly ask the customer to tune the timing parameters by tuning the timing registers of the GPCM and FPGA.For example, they can try and set ,TRAD and TACO fields of the IFC_FTIM1_CSn_GPCM register .Similarly, other timing registers can be tuned to optimize performance.

Also ask the customer to refer to the section 23.7.1.1,"Normal GPCM program operation".For example in the Figure 23-49,"Normal GPCM program operation - acknowledgment mode" illustrates a multiple data transaction scenario where the Chip Select remains active. While using this mode please ensure that all relevant registers are configured accordingly to achieve the desired performance.