T4240 IFC timing too long

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

T4240 IFC timing too long

ソリューションへジャンプ
2,197件の閲覧回数
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 件の賞賛
返信
1 解決策
1,984件の閲覧回数
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 件の賞賛
返信
4 返答(返信)
1,984件の閲覧回数
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 件の賞賛
返信
1,984件の閲覧回数
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 件の賞賛
返信
1,985件の閲覧回数
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 件の賞賛
返信
1,984件の閲覧回数
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 件の賞賛
返信