Does READY_P1 affect P1011 behaviour with L2 RAM via coherency module?

[andyjones]

The first published Electrical Characteristics document for the P1011, P1011EC Rev 0 08/2011, did not reference READY_P1.  Instead, that pin was listed as NC109, and seemingly had no role in POR configuration.

Among the changes that P1011EC Rev. 1, 03/2012 introduced, it states

In Table 1, replaced the signals NC107, NC108, and NC109 (along with their details, such as Package Pin Number, Pin Type, and Power Supply) with the signals CKSTP_IN1_B, CKSTP_OUT1_B, and READY_P1 respectively.

where it is listed as a Debug Output, but a table footnote states

Functionally, this pin is an output, but structurally it is an I/O because it either samples configuration input during reset or because it has other manufacturing test functions. This pin is described as an I/O for boundary scan.

In the P1020RM, READY_P1 also serves as a POR configuration pin cfg_core1_pll2, for Core1 PLL, (unused and unpowered on the P1011), and the Core 1 PLL setting should not have any bearing on Core 0, but appears to affect behaviour of Core 0 access to L2 RAM for certain Core 0 and 1 PLL combinations.  The effect is observed as greater timing jitter on timed code function execution.  The observation leads to speculation that the Core 1 PLL is factored into the Coherency module configuration in some way that isn't obvious from the datasheet.  Has anyone else observed and better characterised this?

[andyjones]

Hi Alexander,

Clarification from or SW team, is that the timing differences are witnessed during SW-triggered DDR ECC activities, and so may relate to DDR and/or Interrupt Controller timing changes across the System Bus and/or Coherency Module.

I can confirm that the Core 1 power supply VDD  pins and the AVDD_CORE1 are not powered, and are actually pulled to GND, per AN4259 section 26.

We have Personality Selection P1011, per section 3.2

We have CCB Clock PLL Ratio 4:1, to give 400MHz from 100MHz clock, per 6.1.3

We have cfg_plat_speed indicating >= 300MHz

We have DDR Clock of 66MHz x 10 = 666MHz

We have e500 Core 0 to CCB Clock Ratio 2:1, to give 800MHz core 0, per 6.1.4

We have cfg_core0_speed indicating > =500MHz

According to AN4259 section 6.1.4, "The ratios for Core 1 are not valid for single core devices.", but our observations are that behaviour differs when we leave Ready_P1 NC or if we pull it high.

Considering Ready_P1 low, would give is a Core 1 to CCB Clock ratio of 1:1 (400MHz), while High would give 3:2 (600MHz).

We have cfg_core1_speed indicating > =500MHz.  This is presumed to be irrelevant for P1011, in line with AN4259 statement that the ratios for Core1 are not relevant, but is there any consequence for Core0/coherency/system bus activity if this is mismatched with Core 1 PLL speed?.  We note that in the P1020RM, section 4.5.3.20 Core 1 speed states "The core 1 speed configuration input, shown in the table below, configures internal logic
for proper operation with the core 1 clock frequencies in use.
The default setting is appropriate for core 1 operating at or above 500 MHz. For low
speed operation (core 1 below 500 MHz) this POR configuration input should be low
during HRESET. If this configuration is not set properly, behavior of the system may be
unreliable.  Note that the value latched on this signal during POR is accessible through the
memory-mapped PORDEVSR2, described in POR device status register 2
(GUTS_PORDEVSR2)." so some Core 1 info is visible to the core 0.

Can any of this internal logic have a material effect on the Core0/coherency/system bus/DDR/PIC timing?

[alexander_yakov]

I went through your observations and I couldn't locate anything that might have caused the problem that you mentioned. READY_P1 cannot have any kind of impact on the working of core 0 in P1011.

However I suspect that DMA1_DACK_B00 lies low during PORESET de-assertion. I request you to share scopeshot of DMA1_DACK_B00 and PORESET when PORESET de-asserts (rising edge) in problematic session. Also I request you share register dump of all the registers of GUTS (Global Utilities) section in good and problematics sessions.

[andyjones]

I cannot offer you a scope trace right now, but DMA1_DACK_B00 is pulled high (via 1k), as it is one of the three pins that define the P1011 Personality Selection.

I'll try to get the GUTS dump too, but from memory, we saw nothing at odds with what we believe has been selected via cfg pins.  The exception being when we change the status of the Ready_P1 bit.

[alexander_yakov]

Could you please confirm core1 power supply VDD and core1 PLL power AVDD_CORE1 are not powered in your design?

Please refer to P1020 EC for pin numbers.

Have a great day,
Alexander
TIC

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