AM355x GPMC_CLK (V12) Pin

The GPMC_CLK is derived from the Core PLL. Note that it is output on the GPMC_CLK pin only during synchronous GPMC transactions. This clock cannot be used as a continuous source clock for external circuits.

Thank you for the help

irwin weiss

Yes, it's possible to set the GPMC clock to 25MHz individually for each CS region via the GPMC_CONFIG1_x register bitfield GPMCFCLKDIVIDER. However you should be aware that this will not be synchronous to the master oscillator clock (phase, jitter, etc.).

Please reply on the original thread you started. I will merge this thread to it.

HI,

I understand that GPMC_CLK is not continuous. This is ok for us. But what we need is that GPMC_CLK is exactly same frequency as the external Reference clock we are using which is 25Mhz. I sthis possible.

thank you,

irwin weiss

Hi Biser,

thanks for the reply. Our software and FPGA designer here needs the GPMC_CLK exactly equal to the Master Input Clock, which in our case is 25Mhz. Not having same phase and jitter is ok. They just need to be exactly same frequency.

thanks again for the help,

irwin weiss

MRV communications

Hi Biser,

Are yo suggesting that the phase relation between GPMC_CLK (or in other word, the data sampling point of rd / wr access) & OSC0 is not fixed even we configure GPMC as sync mode?

Does this phase relation varies every time AM335x is powered on?

Or does it varies between every individual GPMC access?

It's quite crucial to us because a fixed relationship can be adjusted by a external PLL chip but a random relationship means we can do nothing about it.

Thank you!

This relationship has not been timing closed by design.

Thank you Biser.

But still I feel a little bit confused because the internal GPMC_FCLK is derived from CORE_CLKOUTM4 which is generated by the PLL module. (table 7-3,  page 518, TRM)

According to the common understanding,  once the configuration of the PLL module and the clock tree is fixed, CORE_CLKOUTM4 should has a fixed phase relationship compared to OSC0 which feeds the PLL.

And therefore, if GPMC_CLK is configured to be 1/1 of internal GPMC_FCLK, this GPMC_CLK output should be the same as GPMC_FCLK. (Table 7-7, Table 7-7, page 525, TRM)

I have to say sorry that I keep asking the same question but it really is not that straight forward. For an system architect (especially with FPGAs on board), a fully synchronized system with all the ICs sharing the same source of clock can improve the system bandwidth & latency by throwing away the clock-domain-crossover problem.

Many thanks for your response and patience.

Biser Gatchev-XID said:

This relationship has not been timing closed by design.

Yes, what you say about the PLL and GPMC clocks is true. However this phase relationships may and probably will be different when power cycling the board. Since you mention FPGAs please keep in mind that the GPMC_CLK is not continuous, it's output only during synchronous transactions over the GPMC.

The PLL is constantly adjusting the output frequency trying to stay locked to the reference clock.  The reference clock passes through a predivider in the PLL.  The output of the PLL is divided down to the same frequency as the predivider output and the phase of these two clocks are compared to determine if the PLL output frequency must be increased or decreased to stay locked.  Therefore, the PLL output frequency is constantly increasing or decreasing relative to the reference clock at a period equal to the predivider output frequency. This is the reason you cannot use the reference clock as a time reference for GPMC.

Regards,
Paul

Many many thanks to Biser

Yes GPMC_CLK non-continuous issue has been specially marked in our own design guide line and I think you must have been tired mentioning it again and again.

:p

And even if GPMC_CLK is continuous, the jitter performance may lead to PLL lock lost issue inside an FPGA or other uC if this GPMC_CLK is feeding them as a clock input.

So we planned to use external OSC and clock distribution (or PLL) as a work around. But according to what you have mentioned in your post, it seems again we cannot use this topology that straight  forward.

At least we should add some extra "training" procedure to compensate the variable phase issue (like what the level-shifting does) if we want to achieve premium communication bandwidth between ARM and many other co-processors, giving the phase lag will be stable as long as the processor stays in active state.

Again, thank you very much for your reply!

Biser Gatchev-XID said:

Yes, what you say about the PLL and GPMC clocks is true. However this phase relationships may and probably will be different when power cycling the board. Since you mention FPGAs please keep in mind that the GPMC_CLK is not continuous, it's output only during synchronous transactions over the GPMC.

Dear Paul,

I guess you are talking about the phase detector & VCO control principle. Yes it's true that the PD will always generate a changing output, which leads to frequency of the VCO changing all the time.

But according to my personal understanding, this changing of frequency is slight compared to the nominal output frequency. The close loop control algorithm, the large open loop gain and the output LPF altogether make the output clock is "phase aligned" to the input clock (more accurate, to the pre-divider feeding to the phase detector).

And this is exactly why we call it a Phase Lock Loop.

So actually, this is why we thought the GPMC_CLK phase should be locked to the PLL input ( which is OSC0).

I don't know if my inference is correct, but after all, it's really nice to hear your reply. 

Best regards!

peaves said:

The PLL is constantly adjusting the output frequency trying to stay locked to the reference clock.  The reference clock passes through a predivider in the PLL.  The output of the PLL is divided down to the same frequency as the predivider output and the phase of these two clocks are compared to determine if the PLL output frequency must be increased or decreased to stay locked.  Therefore, the PLL output frequency is constantly increasing or decreasing relative to the reference clock at a period equal to the predivider output frequency. This is the reason you cannot use the reference clock as a time reference for GPMC.

Regards,
Paul

The PLLs used in AM335x are digital PLLs.  They change much quicker than a analog PLL and have much larger PPM changes between updates.  I agree the cycle to cycle jitter of the PLL output is minimum, but it can produce many consecutive short or long cycles as it changes.  If this clock is divide by a large value to create a slower clock the accumulative jitter can add or subtract a significant about of time to each of these slower clock cycles and create a significant amount of jitter. I'll give you an example, we initially planned to source the 50 MHz RMII reference clock so customers would not be required to purchase an additional crystal for their RMII Ethernet PHY. This feature was de-scoped because we found the n-cycle jitter was about 4ns across 500 clock cycles and this caused problems for most RMII PHYs.

Regards,
Paul

Dear Paul.

Sorry that I didn't make a prompt reply caz it was already 01:30 a.m last day here.

Thank you very much for your thorough explanation. It's great. 

And I have to say sorry that I neglected the simple fact that 335x is using DPLL instead of APLL.

But now it seems our discussion has come to the most interesting part.

1. Will the phase relationship between OSC0 (PLL input) and the GPMC_FCLK (CORE_CLKOUTM4 / 2) be different every power up cycle?
2. If the jitter of GPMC_CLK is that large (counts to nS scale in your post), the headroom of setup / hold time of an attached ASIC / FPGA is quite small.

For question 1. it seems Biser gives an answer.

Biser Gatchev-XID said:

However this phase relationships may and probably will be different when power cycling the board. 

If this is true, the other ASICs that connected to AM335x through GPMC has to deal with the clock-domain-crossover problem. An extra synchronization requirement has to be met, just as the "wait monitoring during an asynchronous rd / wr access" (chapter 7.1.3.3.8.3.1 / 7.1.3.3.8.3.2 PRM)

For question 2. I would like to refer to "Silicon Errata, sprz360f". Advisory 1.0.16 is exactly the perfect example and actually you've showed it to me in our discussion.

peaves said:

I'll give you an example, we initially planned to source the 50 MHz RMII reference clock so customers would not be required to purchase an additional crystal for their RMII Ethernet PHY. This feature was de-scoped because we found the n-cycle jitter was about 4ns across 500 clock cycles and this caused problems for most RMII PHYs.

Good news for RMII is that the RMIIx_REFCLK can be configured to use an external OSC input feeding both the PHY and AM335x. The CDC (between RMII_REFCLK & internal CORE_CLKOUTM5) issue is handled inside AM335x.

Bad news for GPMC is that GPMC_CLK cannot be configured to use an external input. When GPMC is interfacing with off-chip ASICs (for saying, an FPGA), the assertion / de-assertion of output signals and the sampling of input signals are all referenced to GPMC_CLK inside AM335x.

So it's quite straight forward that all the setup / hold time constrains are analysed based on this GPMC_CLK. But for newbies just like me, it's very likely that the jitter of GPMC_CLK is NOT taken into consideration.

For instance, if the external ASIC (for saying, a PHY) requires a 20nS WEn control signal, a two-cycle GPMC_FCLK duration can satisfy this simple requirement at the first glance. But if we take the jitter into account and use the same number "4nS", the actual duration of this WEn signal can be reduced to merely to 20ns - 4ns = 16nS in the worst case. And this will surly cause a timing violation.

It's quite lucky for us to have dug to this deep in this discussion or otherwise we might be wondering what causes the unstable data transaction in the near future.

Regards!

I cannot say for sure if there is a constant phase relationship between the OSC0 reference clock input and GPMC clock. The AM335x device was not designed with a specific phase relationship requirement for these signals, so there is a good chance Biser is correct.

I agree setup/hold time can be small, but most peripheral interfaces are synchronous where hold is relative to the same clock edge and setup is relative to the next clock edge of a common clock signal. The issue we found in my example was not a setup/hold issue on the synchronous interface used to connect the RMII Phy. I was just using this example to describe how the DPLL output could drift relative to the reference clock.  The long term drift mentioned in the RMII reference clock example was causing an issue in the RMII PHY when sending/receiving large packets because the PPM difference between the transmitter and receiver was too large.

You are correct that GPMC setup/hold parameters are relative to GPMC_CLK and the timing requirements published in the data sheet have be validated for worst case conditions. You should not have any issue if you design your FPGA to be complaint to the published timing requirements and switching characteristics.

I’m not sure what you are doing in the FPGA, but if you are planning to move data in/out of the FPGA using GPMC in asynchronous mode it may be necessary to design the interface to operate like an asynchronous memory device with an internal synchronizer that moves data in/out of the FPGA clock domain.

Regards,
Paul