T4240 IFC timing too long

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

T4240 IFC timing too long

Jump to solution
2,055 Views
blancharddaniel
Contributor II

Hello, we are using a SRAM connected to a T4240 via the IFC Chip Select 1 in GPCM mode.
We computed that a write to this RAM should last about 65ns,
We measured that, in fact, the write access lasts 98ns.

Could you please give us hints to explain these additional 33ns (and, even better, how to get rid of them) ?

Thanks by advance.

Best Regards,

Daniel Blanchard

The processor is configured as follows :

T4240, SYSCLK = 66.66MHz,  1667MHz
DDR_CLK = 933MHz (1866.66MT/s)
IP_CLK = 366MHz
IFC_CLOCK = 92MHz

IFC configuration :

IFC:CCR = 0x03008000
- CLKDIV = 0x3 (Clock division ratio divide by 4)
- CLK_DLY = 0x0 (IFC clock NO delay)
- INV_CLK_EN = 0x1 (IFC clock is inverted)

IFC:AMASK_CS[1] = 0xFF800000 (8MBytes)

IFC:FTIM0_CS[1] = 0x00020001
- TACSE = 0x0 (reserved, @ end to CS enable, min : 0x1 : 1 IFC module input clock)
- TEADC = 0x2 (2 IFC module input clocks)
- TEAHC = 0x1 (1 IFC module input clock)

IFC:FTIM1_CS[1] = 0x04001900
- TACO = 0x4 (4 IFC module input clocks)
- TRAD = 0x19 (25 IFC module input clocks)

IFC:FTIM2_CS[1] = 0x0308000F
- TCS = 0x3 (3 IFC module input clocks)
- TCH = 0x2 (2 IFC module input clocks)
- TWP = 0xF (15 IFC module input clocks)

IFC:FTIM3_CS[1] = 0x0
- TAAD : 0 (reserved, GPCM address access delay in burst mode, min : 0x1 : 1 IFC module input clock)

IFC:CSPR_CS[1] : 0x----0185
- BA = __SRAM (Base address)
- PS = 0x3 (Port size : 32-bits)
- WP = 0x0 (R/W allowed
- MSEL = 0x2 (GPMC)
- V = 0x1 (Bank is valid)

Nota : With TACSE = TAAD = 0x1 (minimum values), the cycle time increases of 1 clock

Test program, bare metal code, interrupts masked :
    cmplw    r31, r30
    bf     0, 0x48F0
    stw    r29, 0(r31)
    addi    r31, r31, 4
    addi    r29, r29, 1
    b    0x48D8

Corresponding chronogram :

pastedImage_6.png

Yellow : CS

Green : ALE

Blue : One Data bus bit

0 Kudos
Reply
1 Solution
1,842 Views
Bulat
NXP Employee
NXP Employee

The gap between IFC cycles happens due to peculiarity of core load/store unit and its interaction with the IFC (like handshake, waiting for acknowledgement). So answering your question "What does the T4240 during these 33ns", it is waiting... As I wrote, using DMA instead of the core solves this "gap" issue.

Regards,

Bulat

View solution in original post

0 Kudos
Reply
4 Replies
1,842 Views
Bulat
NXP Employee
NXP Employee

Mentioned 33ns gap is not a part of GPCM write cycle, this time is not controlled by the IFC. If you need to accelerate the data transfer, you can prepare data in the memory, then use DMA to move the data to GPCM port. In this case burst can be enabled for IFC CS1, so a block of data will be written to the CS1 using a single bus transaction with the timing described in figure 12-42 of the T4240 Ref Manual.

Regards,

Bulat

0 Kudos
Reply
1,842 Views
blancharddaniel
Contributor II

Thanks, Bulat, for this quick answer.

I'm glad our 33ns are not due to the IFC itself !

But where do they come from ?

Our test loop is 6 assembly PowerPc assembly instructions : I do not see why it should not be in the L1 instruction cache (or, even better, in the Instruction Queue),

Values written in the SRAM are a counter in a register : no additional DDR access or Data cache access,

The TLB decoding the SRAM has only the attribute (WIMGE) : I = Cache Inhibited.

So my question is : What does the T4240 during these 33ns ?

BR

Daniel Blanchard

PS : Sorry to have put this post in a wrong category (PowerQUICC instead of QorIQ)

0 Kudos
Reply
1,843 Views
Bulat
NXP Employee
NXP Employee

The gap between IFC cycles happens due to peculiarity of core load/store unit and its interaction with the IFC (like handshake, waiting for acknowledgement). So answering your question "What does the T4240 during these 33ns", it is waiting... As I wrote, using DMA instead of the core solves this "gap" issue.

Regards,

Bulat

0 Kudos
Reply
1,842 Views
blancharddaniel
Contributor II

Hy Bulat,

Thanks for this answer.

I do now understand that accesses to our SRAM will be longer than theorical timings.

Thanks, too, for the hint about the DMA. But it does not fit our need.

Best regards,

Daniel

0 Kudos
Reply