GPMC_CLK always active on DM8147

In the meantime, we found the AUTOIDLE bit in the GMPC_SYSCONFIG register.  We tried to fix it to '0', which forces the clock to be free-running, but it has no effect on the GPMC_CLK pin.  After reading further, it looks like this bit only gates the clock input to the GPMC peripheral to save power.  We have double-checked our findings on an OMAP4 evalboard, and the GPMC clock is always stopped during accesses.  As I asked to Alex, it there a way to provide a continuous clock on the GPMC_CLK pin ?

We are now thinking of a work-around.  There is CLOCKOUT [1..0] pins which can be driven by the PLL_L3 output.  Based on the system clock overview on page 183 of the datasheet, the PLL_L3 output seem to be the GPMC peripheral system clock (via the PRCM).  We are thinking to use this clock to provide a steady clock for the GPMC interface to the FPGA ?  What is the frequency relationship between this clock and the GPMC_CLK (x2, x4, ...) ?

Thanks.

Hi,

GPMC drives the GPMC_CLK only when there is a valid transfer. There is no configuration supported to make it free running.

Thanks,

Pradeep

Thanks Pradeep for the update.  In this case, what is the frequency and phase relationship between the PLL_L3 clock and the GPMC_CLK (x2, x4, ...) ?  We will send this clock to the CLKOUT pin of the processor.

Thanks.

Martin

Based on the DM8147 datasheet on pages 193-195, it looks like the GPMC_CLK is PLL_L3 clock divided by 2.

Is this correct ?

Then, what is the phase relationship between these clocks ?

Hello,

I have the same application with the same issues.  I am seeing GPMC_FCLK divided by 2 from the PLL_L3 clock.

I am using PLL_L3 as clkout0 at 64MHz.  I need this frequency for the ASIC to work correctly.

I am using GPMC3 with WAITPIN0.  Below is how I am configuring the GPMC registers.

This configuration results in 2 GPMC_FCLKS from when WAITPIN0 deasserts and CS deasserts or roughly 84 nano seconds which is way too long.

Any ideas on how to speed this up?  I don't  want to double the PLL_L3 to 128MHz since it is clocking at 3.3V.

Thanks,

Victor

  gpmc.CONFIG = 0x00000100;           // WAIT0PINPOLARITY active high

  gpmc.cs[3].CONFIG7 = 0;

  gpmc.cs[3].CONFIG1 = 0x00601000;  // Read Asynchronous, Write Asynchronous, WAITREADMONITORING, WAITWRITEMONITORING
                                    // WAIT input pin is WAIT0, 16 bit
  gpmc.cs[3].CONFIG2 = 0x00010100;  // CSWROFFTIME 1 FCLK, CSRDOFFTIME 1 FCLK, CSONTIME 0 FCLK
  gpmc.cs[3].CONFIG3 = 0x00000000;  // Not using AA output
  gpmc.cs[3].CONFIG4 = 0x01000000;  // WEOFFTIME 1 FCLK, WEONTIME 0 FCLK, OEOFFTIME 0 FCLK, OEONTIME 0 FCLK
  gpmc.cs[3].CONFIG5 = 0x00010101;  // RDACCESSTIME 1 FCLK, WRCYCLETIME 1 FCLK, RDCYCLETIME 1 FCLK
  gpmc.cs[3].CONFIG6 = 0x01000280;  // WRACCESSTIME 1 FCLK, CYCLE2CYCLEDELAY 2 FCLK,
                                    // CYCLE2CYCLESAMECSEN Add CYCLE2CYCLEDELAY
                                    // CYCLE2CYCLEDIFFCSEN No delay between the two accesses
                                    // BUSTURNAROUND 0
  gpmc.cs[3].CONFIG7 = 0x00000F50;  // MASKADDRESS - 16 MBytes, CSVALID, BASEADDRESS - 0x10000000

Victor,

I am little confused with the 64MHz you are talking about in here.  The PLL_L3 is running at 200MHz in DM8148.  If you set the GPMCFCLKDIVIDER to 1 then the GPMC will be running at 100 MHz.  What did you do to get it at 64 MHz?  Please note that the max GPMCCLK is spec at 100 MHz.  So if PLL_L3 is at 200MHz, the GPMCFCLKDIVIDER has to be set at 1 or greater.

Hello,

I reconfigured the PLL_L3 to run at 64MHz because I need at clkout0 at that frequency for my ASIC.

If the PLL_L3 is running at 64MHz, then the GPMC_FCLK is at 32MHz.  I believe there is no way to reconfigure that to divide by 1.

Setting the GPMCFCLKDIVIDER in the config1 register will only generate a GPMC_CLK which I cannot use since it only toggles during a synchronous transfer and not continuous.   I think this is a huge deficiency on this chip.   There should have be a configuration bit to allow the GPMC_CLK to run continuously or only during a transfer.

Running the GPMC_FCLK at 32MHz resulted in 2 32MHz clocks between the WAIT and CS deasserting.    I don't want to wait that long especially after a write access.

It appears that I will have to output a clkout0 at 128MHz and then divide by 2.  This is not the best solution since it draws power.  But this will reduce the time in half after the Wait0 and CS deasserting.

What is the max clkout0 frequency?   I hope it is not 100MHz like the GPMCCLK.

If you have a better way of implementing this, please let me know.  i am still in prototyping phase.

Thanks,

Victor

Victor,

You can make GPMC_FCLK to run at same as PLL_L3 by setting the GPMCFCLKDIVIDER to 0.

If you use asynchronous mode, I believe the GPMC_CLK will be alway running.

The clkout0 can run only as fast as PLL_L3 which is 200 MHz for DM8148 but the GPMC_CLK can run only up to 100 MHz.  So, if you running PLL_L3 at 200, you have to use GPMCFCLKDIVIDER to div by 2.

BR,

Viet

Hello,

Is the GPMCFCLKDIVIDER  the one in gpmc_configx_1 register?  Or a different one?  I am setting it to 0 if you look at my first email.

I am using asynchronous mode and I did try the GPMC_CLK first.  It will only toggle if I am in synchronous mode.  And this is consistent with the RM.

I am glad to hear that I can run the clkout0 at 128MHz.

Let's try to figure out my problem another way.   I am seeing four 64MHz clocks between WAIT and CS deasserting.  What can I do to decrease the number of  clocks in this region?

Thanks,

Victor

Hi Viet,

Could you please confirm that in async mode the GPMC_CLK will always be running?
According page 1444 Figure 11-7 of the DM8148 TRM - SPRUGZ8A the GPMC_CLK is not active for single async read

Thanks in advance,

Anthony

Anthony,

You are right, the async mode GPMC_CLK run only when data transfer.  The GPMC_CLK always run in sync mode only.  Sorry for a mislead earlier.

BR,

Viet

Hello,

I did not get any answers on how to improve the performance of the GPMC interface.

My ASIC uses a NOR type interface that requires a free running clock at 66MHz max.  This clock is used to synchronize the interface and the ASIC generates the WAIT signal off this clock.

I used clkout0 for this free running clock and the source is PLL_L3 since this is also the source clock for the GPMC.  Thus both the ASIC and the GPMC  will be synchronized to the same clock. 

I believe the GPMC controller is hard wired to divide the PLL_L3 clock down by 2.   So, the GPMC controller will be running at 33MHz.

On a scope, I am seeing four 66Mhz clocks after the WAIT deasserts and the CS deasserts.   I believe this is due to two 33MHz clocks required by the GPMC.  Is there any way to decrease this period?

I can double the clkout0 to 132Mhz and then divide by 2 using a F/F  which will increase the GPMC controller clock to 66Mhz.  This should lower the period between the WAIT and the CS but I prefer a software fix.

So any suggestions?

Thanks,

Victor

Victor,

The GPMC_FCLK is running at 1/2 PLL_L3 clock so to improve the GPMC interface, try to configure the PLL_L3 as close as 200MHz.

BR,

Viet

Hello,

If I do that, then the output on the clkout0 will be close to 200Mhz.  I will then need to put a clock divider so I can generate a 66Mhz for my ASIC.

This is essentially the same as setting the PLL_L3 clock to 132MHz and use a F/F to divide by 2 to generate the 66MHz.  I prefer not to do a hardware fix.

Thanks,

Victor

Victor,

I have a suggestion but don't know if it work for you. 

Let say you use the PLL_L3 at 132MHz then the GPMC_FCLK is at 66 MHz, if you run the sync GPMC mode, you will have GPMC_CLK output at 66 MHz when you set the GPMCFCLKDIVIDER to 0.  This way you will have the 66 MHz and GPMC is running at the faster clock. 

What do you think?

BR,

Viet

Hello,

This will not work since I need a free running clock.  In sync GPMC mode, the GPMC_CLK stops running.  Unless you can tell me there is a way to keep the GPMC_CLK free running.

Thanks,

Victor

Victor,

I consult the problem with our designer and he suggest that if you are not using MAIN_PLL, DPLL_DSP, VIDEO or AUDIO, you can pick one of those PLL and configure its register to output 66 MHz clock and use it for your NOR.  You have set CLKOUT_MUX to use PRCM SYSCLK instead of PLL_L3 for clkout0. 

Then you can have the GPMC to run at max when you have PLL_L3 at 200MHz.

BR,

Viet

Hello,

I chose PLL_L3 as the source for clkout3 since that clock sources the GPMC controller and the interface to the ASIC is a synchronous interface.

While the other clocks that you mentioned are also based off the 20MHz clock as the PLL_L3, will those clocks after being divided down and multiplied up still be in sync with the PLL_L3 at 132MHz?  I really doubt that.

Cheers,

Victor

There is equation on sect 2.6.1 in our TRM if you would like to try.

BR,

Viet

I'm new to the thread so bear with me.  One of the main things I'm trying to figure out is the clock requirements for the device(s) you have connected externally to the GPMC.  Specifically, I'm trying to figure out precisely what this 64 MHz clock will do.  How many 64 MHz inputs are there on your external device?  For example, is there a 64 MHz sys_clk pin that is the time base for all calculations as well as a 64 MHz mem_clk for the memory interface?

Victor Chan said:

I chose PLL_L3 as the source for clkout3 since that clock sources the GPMC controller and the interface to the ASIC is a synchronous interface.

Earlier in the thread you said you were using async interface.  Here you say sync.  Or is it both (i.e. 1 device async, 1 device sync)?  Related to this item I am trying to understand whether you require any phase relationship between clkout and gpmc_clk.  Hopefully you do not have any such requirement as there is no guaranteed relationship between those two clocks.  In other words, despite the fact the fact that they originate from the same clock, we do not specify a phase offset for them.

To be clear there does not exist any mode of operation for the GPMC in which the clock is running all the time.  For the async mode the clock is not used at all and in the sync mode the clock is on only during transfers.

One other comment I'll make is that slowing down the L3 clock for the purpose of clocking your external ASIC is going to have system wide ramifications, i.e. you will be throttling the system throughput of the entire device by slowing down the interconnect.

I am using the 64MHz on the ASIC for both as a time base for all calculations and as the mem_clk for the memory interface.   My design can have up to two ASIC and one FPGA that will require this GPMC interface.

I am using the GPMC interface in async mode with the clkout.   Basically, this is the same as the sync mode but the clock doesn't stop.

This configuration does work but very slow if I set the clkout to 64MHz.

I  went ahead and increased the clkout to 128MHz and use a F/F to divide by 2 and that speeds up the interface quite a bit.

It appears that this is the only way I can get better performance on this GPMC interface.

I feel better using PLL_L3 instead of another clock since the GMPC_FCLK is based on that clock.  My timing is not that tight since that my phase offset isn't that critical.  At least using this clock will have a more consistent relationship with the GPMC_FCLK over multiple reboots and units.

BTW, I didn't have this problem when I interfaced the same ASIC to the OMAP-L138.  That EMIFA interface does have a free running clock.

Thanks,

Victor

Hi Viet,

Please let me know where to check for the PLL_L3 and GPMCFCLKDIVIDER value.

Regards,

Sudeep

Sudeep,

For L3 DPLL you can check in:

1. DM814x TRM, section 2.6 DPLLLJ, section 2.10.1 PLLSS Registers, Figure 2-6. Clock Structure, section 2.3.2 Clock Structure, section 2.3.3 Main PLL Clock Structure.

2. DM814x datasheet, section 7.4 Clocking

3. {EZSDK}/board-support/u-boot-2010.06-psp04.04.00.01/arch/arm/include/asm/arch-ti81xx/clocks_ti814x.h file:

#define L3_N        19
#ifdef CONFIG_DM385
#define L3_M        (opp_val_dm385(800, 800))
#else
#define L3_M        (pg_val_ti814x(880, 800))
#endif
#define L3_M2        4
#define L3_CLKCTRL    0x801

For GPMCFCLKDIVIDER you can check in:

1. DM814x TRM, chapter 11 GPMC

2. DM814x datasheet, section 8.8 GPMC and ELM

Regards,
Pavel