LS1021A performance questions -- GPMC, Module Clk, Platform Clk,IFC Port, buffers

cancel
Showing results for 
Search instead for 
Did you mean: 

LS1021A performance questions -- GPMC, Module Clk, Platform Clk,IFC Port, buffers

1,185 Views
RsBogdan
Contributor I

I am having problems figuring out some of the details from the latest LS1021A Data sheet... So I have some questions:

1) If I want to do a synchronous interface with the highest possible bandwidth, it seems like I need to use the GPMC mode.

2) Everything is based off of the "Module Clock", which appears to be the "Platform Clock" in the reference manual. I have not been able to find the specification for how this clock must be configured. I have seen references to it being a 300MHz Clock and others to it being a 400 MHz clock. How do I determine what the clock speed will be - I'm guessing 300MHz from the docs in the SDK, but I am not sure I understand the constraints.

3) The data sheet seems to indicate that the max IFC Clock is 100 MHz. Is this correct? The Reference Manual would seem to indicate that the IFC clock can be the module clock divided by 2 -- but that would be 150 MHz. So is this an issue where the actual chip implementation has more stringent requirements than the IP (maybe because of the speed of the pin drivers or something)?

4) I am trying to determine the maximum bandwidth that can be achieved through the IFC port.

So far I have come up with the following:

If CLKDIV=1 (÷2) then the IFC_CLK would be 150 MHz.

So I think you could set:

            TEADC = 2

            TEHAC = 2

            TACSE = 1

            TCS = 1

            TCH   = 1

            TWP   = 2

            TACO  = 1

            TRAD  = 1

            TAAD  = 2

            TRHZ  = 0 (20 Clocks)

            AM    = 0xffff (64kB bank)

            BURST_LEN = 7 (128 beats)

If I understand the waveforms correctly, this would mean that for a full write burst, it should take:

            TEADC + TACSE + TCS + 128 * TWP + TCH = 261 module clocks

to transfer 128 * 2 = 256 bytes. This would give an efficiency of 98%, and if the module clock is 300 MHz, this should give a write performance of about

294 MB/s ≈ 2.35 Gb/s

If the IFC_CLK is really limited to 100 MHz, then this should provide a throughput of about 2/3:

196 MB/s ≈ 1.569 Gb/s

On the read side, I think it should take:

           

            TEADC + TACSE + TACO + TRAD + 128 * TAAD

This works out to the same as above.

4a) Is this analysis correct (or even close)? - unfortunately, the documentation is pretty abstract

4b) Does the TRHZ apply when using the GPMC machine?

4c) If AM =0xffff (e.g. 64kB bank) does the IP forgo the MSW ALE address cycle on the port in GPMC mode?

4d) What is required to actually get a full burst transfer?

4e) Are there any hidden transaction times that I am missing?

(4d) is especially important; since the overhead is 15 or 16 cycles per burst, if I can't actually get full bursts, the efficiency will go way down. Does the IFC/GPMC buffer transactions and do a burst based on the buffered values. Do I need to have a DMA burst to the memory area to ensure that the GPMC does a full burst?

0 Kudos
7 Replies

568 Views
davidglover
Contributor I

** UPDATE **

I've finally figured it out.  I didn't realize the 'ioremap' call in the kernel defaulted to non-cached memory space.  I switched to 'ioremap_cache' and now it is bursting.

So, all that is needed for normal GPCM bursting is to set BURST_LEN to non-zero, and ensure your virtual address is mapped to cached memory space (i.e. use ioremap_cache).  You do not need anything else.

This should have been one of the first things I checked, but I just overlooked it.

Thanks for the help!

- David G.

0 Kudos

568 Views
davidglover
Contributor I

Hello Pavel,

Thanks again for your response.  I see a PGRD_EN bit defined in the IFC_CSORn_NOR register (bit 3), but this bit seems to be reserved in the IFC_CSORn_GPCM version of this register.

Just to clarify, I want to invoke a burst while the IFC is in normal GPCM mode (IFC_CSPRn[MSEL] = 10b and IFC_CSORn_GPCM[GPMODE] = 0).  Also, I want this to be a 'write' burst access, though eventually I'll want burst reads as well.

It appears the PGRD_EN is only available when IFC_CSPRn[MSEL] = 00b (Machine Select = NOR flash).  Perhaps the documentation is incorrect (?).  I have the reference manual revision 1, which is the latest I see online.

I can try to set the reserved bit in the IFC_CSORn_GPCM register, though I don't see how this will invoke a burst write.

Best regards,

- David G.

0 Kudos

568 Views
davidglover
Contributor I

Thanks for the reply Paul.

Any chance of getting answers for the original poster's question 4d (RsBogdan "(4d) is especially important"), and perhaps also to my burst question(s) on invoking the burst mode?  I'm worried that GPCM bursting is in fact not supported, or perhaps only supported via DMA.

Thanks again,

- David G.

0 Kudos

568 Views
Pavel
NXP TechSupport
NXP TechSupport

4d) The PGRD_EN and BURST_LEN field should be set and cache is should be enabled for this memory.


Have a great day,
Pavel Chubakov

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

566 Views
Pavel
NXP TechSupport
NXP TechSupport
  1. It looks like that IFC GPCM is needed for you.

 

  1. The RCW SYS_PLL_RAT selects the platform clock:SYSCLK ratio. For example, see the Figure 4-3 of the LS1021a Reference Manual rev 1. Platform clock is ipg_clk.

The integrated flash controller (IFC) clock speed on IFC_CLK[0:1] is determined by the IFC module input clock (platform clock/1) divided by the IFC ratio programmed in IFC_CCR[CLKDIV]. See the

AN4878, QorIQ LS1021A Design Checklist:

https://www.nxp.com/webapp/Download?colCode=AN4878&location=null&fasp=1&WT_TYPE=Application%20Notes&...

 

  1. IFC-GPCM and IFC-GASIC maximum clock is 100MHz. See the Table 77 of the LS1021a Datasheet rev 3.

This Table contains recommended parameters. The LS1021a was tested using this maximum IFC clock for IFC-GPCM and IFC-GASIC modes.

 

The TRHZ is applied to the IFC NOR. See the Section 23.3.6 of the LS1021a Reference Manual.

 

Page mode (burs) is enabled if the PGRD_EN bit is set.


Have a great day,
Pavel Chubakov

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

566 Views
davidglover
Contributor I

One thing I forgot to mention.  I noticed the term 'burst' thrown around in some of the DMA drivers.  Perhaps IFC burst is only available using DMA?

Please advise.

- David G.

0 Kudos

566 Views
davidglover
Contributor I

I am having similar issues, using the IFC in GPCM mode.  I notice that this is an old issue, with no response.  That is discouraging....

I am currently using the IFC with these timings:

TEADC = 1

TEHAC = 1

TACSE = 1

TCS = 1

TCH   = 1

TWP   = 6 (produces WE pulse width of two IFC_CLKs)

TACO  = 1

TRAD  = 6 (produces OE pulse width of two IFC_CLKs)

TAAD  = 6

TRHZ  = 0 (20 Clocks)

AM    = 0xFC00 (64MB bank)

BURST_LEN = 7 (128 beats)

I'm not 100% sure this is supposed to be legal, but it works, at least for single accesses.  I started with BURST_LEN=0 just to prove out the interface.

With reference to the IFC_CLK, there is effectively no ALE bus phase (I'm using just the non-muxed/fixed lower address bits).

Nothing I do produces a burst from my IFC module.  I have tried using iowrite16be() in a loop:

            for (i16 = 0; i16 < (params.size / sizeof(u16)); i16++)
                iowrite16be (buf[i16], p_addr);

This just produces single half-word (16-bit) writes back-to-back, no burst is invoked.  I've also tried:

            memcpy_toio (p_addr, &buf[0], bytes /* params.size */);

This has 3 bad aspects:
    1. This does not invoke a burst.
    2. The destination address increments (not desirable for my design).
    3. Only bytes are written, the lower byte is always 0x00.

And then I tried:

            iowrite16_rep (p_addr, &buf[0], (bytes/sizeof(u16)));

Again no bursts, but this is the fastest version so far (3 IFC_CLKs for the access, 3 IFC_CLKs between accesses, for a total of 6 IFC_CLKs per 16-bit write).  Of course, there are delays between each 'burst' of back-to-back writes, reducing my throughput to a little over 250Mbps (my IFC_CLK is 100MHz).  Also, this doesn't correct for the endian difference between the core (little endian) and my external FPGA (big endian).  This is easily corrected externally though.

Note that in all cases, p_addr is the virtual address of the programmed CSx address space (CS0 my case).  I noticed in my reading that there is an SRAM associated with the IFC, but all references have to do with NAND page accesses.  I have to wonder if I have to somehow access the SRAM for bursts (??).  Perhaps it's not automatic as I had hoped.

In any case, I'm obviously missing something in order to invoke a burst write on the IFC.  I too would appreciate answers to the original poster's questions, plus explanation or (even better) documentation on how to use the burst mode of the IFC in GPCM mode.

Thanks,

David G.

<davidg@adtecinc.com>

0 Kudos