MPC8535 PCI controller can get clock from SYSCLK (synchronous) or from PCICLK (PCI asynchronous mode). If PCI is configured as PCI asynchronous mode, a valid clock must be provided on pin PCICLK, otherwise the processor will not boot up. Is this limit just due to PCI bus specs and if PCI is not used then MPC8535 PCI block can withstand 125MHz in synchronous mode? The PCI input clock frequency spec range is between 33 - 66MHz. IF the PCI interface is enabled, then this spec here will matter regardless whether you are running in synchronous or asynchronous mode. IF the PCI is disabled / un-used, it will not matter what input clock is being fed into this interface. Also, please refer to section 15.2 of the 8535 bring-up guide for termination details of the PCI pins including the PCI1_CLK pin when the interface is not being used. I am starting 8535 design making use of both SerDes serial interfaces: 1) SerDes1: PCI Express 1 (x4) (2.5 Gbps) → SerDes1 Lanes A-D; PCI Express 2 (x1) (2.5 Gbps) → SerDes1 Lanes E-F 2) SerDes2: SATA1 → SerDes2 Lane A. Each SerDes has its own reference clock. They will both run at 100MHz. Are there any phase requirements between these 2 clocks? There is no requirement on 8535 for any particular phase relationship between reference clock for Serdes 1 vs Serdes 2 because each serdes is completely independent.

MPC8536 Hardware spec states that either SDHC_CD, or SDHC_DAT3 can be used for card detection. Do you have to set the bit PROCTL[D3CD] specifically, if you want to use the DAT[3] method? This, plus adding the pull-down? PROCTL[D3CD] has to be set to 1 if DAT3 is used as card detection. A pull down is needed as well per spec. It should be an external pull down. MPC8536 HW spec mentions that if SDHC_DAT[3] is not used, SDHC_CD must be used, but it can be implemented by GPIO. What does that mean? Does it mean external (non CPU) GPIO could trigger the SDHC_CD transition? If DAT3 is not used as card detection pin, a separate pin has to be used. For 8536, SDHC_CD_B/GPIO[4] pin is used. PMUXCR[SDHC_CD] pin should set to 1. If PROCTL[D3CD] =0 & PMUXCR[SDHC_CD]=0, the PRSSTAT[CDPL] field is unaffected by the external card detect pin, and will permanently indicate that a card is present.

As MPC8306RM.pdf shows, one can multiplex some pins such as, LAD8/GE_PA0 multiplexing. My design uses LOCAL BUS (nor flash) and UTOPIA at the same time. Can I design my product like this in view of pin multiplexing? LAD8 must be used as local bus pin. For UTOPIA, this pin serves as PA0, which is UTOPIA TX address 4. Usually this UTOPIA signal can be not-used. MPC8306 Reference Manual chapter 12.5.1.2 states that LAD [0:15] can carry both A [0:15] and A [16:31] via ABSWAP setting switching. How can I use it to skip LAD8 to address local bus device? ABSWAP is not used dynamically. It should be set either 0 or 1 but not be switched from time to time. In this case only A [16:31] (from LAD) is available when ABSWAP is used (set to 1). In this case this can only be used if customer requires 16 bit or fewer address lines. In MPC8306, for UTOPIA pins UPC1_RxADDR [2:4]/UPC1_TxADDR [2:4], each signal has two pins described in MPC8306RM. Based on this, can I use any one of the pins LAD08 or MDVAL for UPC1_TxADDR [4]? For LAD08, I'll assign this pin for LOCAL BUS. Yes, you can use any one of the 2 pins for these signals using PMUXCR register. UPC1_TxADDR [4] can be either the one multiplexed with LAD08 or MDVAL. You can assign LAD08 pin for LOCAL BUS. Also remind you that, UPC1_TxADDR 4] is MSB, if only 4-bit UTOPIA address is needed, just use UPC1_TxADDR [0:3] and this LAD08/UPC1_TxADDR[4] pin can be configured as LAD08 by clearing PMUXCR[QE1] bit to 0. In MPC8306, I saw that LOE/ LGPL2/ LFRE in the same line, but in P1016EC.pdf, only LGPL2 is present in B14-pin description and I cannot find LOE/LFRE. Can LOE/LFRE (GPCM read enable) signal use B14-pin? LOE/LFRE (GPCM read enable) signal can use B14-pin. For LGPLx pins, we only put the LPGLx in our hardware spec. You can find all other multiplexed function from MPC8306 reference manual.

Can MPC8541 GPIO signals drive LEDs directly? What is the output current requirement (Iol / Ioh) for GPIO signals? Yes, MPC8541 GPIO signals can drive LEDs directly. When GPIO is driven HIGH, to maintain a voltage of 2.4V, no more than 2mA should be drawn from the IO and conversely to maintain a 0.4V when GPIO is driven LOW no more than 2mA should be sunk into the IO. Current limiting would have to be done through external resistors. Below are the current and voltage requirements: @3.3V Input high voltage VIH 2V Input low voltage VIL 0.8V Input current (OVIN = 0 V or OVIN = OVDD) IIN — ±40 μA2 Output high voltage (OVDD = min, IOH = –2 mA) VOH 2.4V Output low voltage (OVDD = min, IOL = 2 mA) VOL 0.4V @2.5V Input high voltage VIH 1.7V Input low voltage VIL 0.7V Input current (OVIN = 0 V or OVIN = OVDD) IIN — ±40 μA2 Output high voltage (OVDD = min, IOH = –2 mA) VOH 1.7V Output low voltage (OVDD = min, IOL = 2 mA) VOL 0.7V @1.8V Input high voltage VIH 1.2V Input low voltage VIL 0.6V Input current (OVIN = 0 V or OVIN = OVDD) IIN — ±40 μA2 Output high voltage (OVDD = min, IOH = –0.5 mA) VOH 1.35V Output low voltage (OVDD = min, IOL = 0.5 mA) VOL 0.4V MPC8541EC revision F defines output delay time for eSDHC interface in table 52. Is there any specification regarding "output hold" time? If not, how should I consider about it? The min value of Output delay time becomes the output hold. ( Half clock period - |min khov| ) becomes the input hold for the receiver chip. How is the selection between eLBC and DIU signals done in MPC8541? Is it done through SPI signals? Why are SPI signals "-" in data phase of 16-bit GPCM? Selection between eLBC and DIU signals is done via PMUXCR [eLBC_DIU], and INDEPENDENTLY selection between eSPI, eLBC or eSDHC signals is done via PMUXCR[SPI_eLBC]. Thus for SPI signals user only needs to use PMUXCR[SPI_eLBC]. And for 32-bit GPCM user has to set BOTH PMUXCR[eLBC_DIU] and PMUXCR[SPI_eLBC]. Using the TDM interface in shared mode (Tx clk and sync are used for Tx and Rx), are pullups / pulldowns required for TDM_RCK and TDM_RFS in MPC8541? Actually the multiplexing happens at the SoC level and the selection of shared mode happens at the IP level, hence pins would not automatically revert to GPIO. It is recommended to be pulled to OVdd by 2k-10k. Can you please describe the procedure for timer soft reset and reconfiguration for MPC8541? Software must do the following before asserting TMR_CTRL[TMSR]: 1) Place the controller in graceful transmit stop (DMACTL[GTS]=1, wait for IEVENTGn[GTSC]=1) 2) Disable receive (MACCFG1[RX_EN]=0) Note: After setting timer soft reset (TMR_CTRL[TMSR]), software must leave the bit high for at least three 1588 reference clocks or tx_clk cycles, whichever is slower, before clearing the bit. How should I handle 2 CKSTP_OUT signals for MPC8541? Note 11 on Table 1 in the MPC8541EC states that these need a weak pullup resistor. However, Table 4-13 in the MPC8541RM shows that these 2 signal default to 1 (as part of cfg_rom_loc). Do these pins need pullups? The internal pull up for por_cfg pins is only for the duration when HRESET is asserted. So after POR pull up will be required. For handling this kind of a situation a tri state buffer with Enable tied to HRESET can be used. Add pull down at buffer input and pull up at buffer output. While HRESET is asserted, the pull down is visible on the buffer output. After HRESET deassertion, buffer output is tri stated and pull up on the output of buffer pulls up the CKSTP_OUT signal. What is the default value of POWER_EN pin in EXTEST and on BYPASS/IDCODE mode in MPC8541? Default values in modes for EXTEST and BYPASS/IDCODE: 1) EXTEST Normally SAMPLE-PRELOAD is run prior to the EXTEST instruction whose purpose is to configure BIDI PADS either as input or output. In this state we shift the value in BSR chain so depending upon value shifted in BSR this pin would have that value. 2) IDCODE and BYPASS Pin is at the functional value. These instructions don’t have any effect on the pin value.

Does this output signal really need the pull up? Yes, IRQ_REQ output signal requires 2-10K ohm pull-up According to the section 20.10 of 8548EEC, SD_REF_CLK/SD_REF_CLK_B must be connected to GND if not used. Is this still required even when they have internal 50 ohm termination to GND? This note is per specfication. Yes, the SD_REF_CLK/_B are 50ohm terminated to ground. They are also AC coupled to the inputs of a differential amplifier. If they are not used and unconnected, we don't want them responding to any differential noise that might be present in the system, hence drawing unwanted current. Thus we recommend tying them to ground so that the inputs cannot respond to any differential noise. What is the pin compatibility difference between MPC8543 and MPC8548? MPC8543 and MPC8548 are built on same die and are pin compatible, only reduced functionality in MPC8543E.

Note 2 of table 13 in MPC8535 hardware spec mentions: "Peak-to-peak noise on MVREFn may not exceed +/- 1% of the DC value." What is "the DC value"? The DC value is the GVdd value. Do you have any typical estimated numbers for running at 3.0Gsb vs running at 1.5Gbs for MPC8535? Would there be any significant power savings? The 8535 SATA I/O power consumptions for 1.5Gb is 240 mW and for 3.0Gb is 270 mW.

Does MPC8306 come with SerDes clocks enabled? Will MPC8306 remain in reset if the SERDES is enabled and no SerDes reference clock is available? Yes, MPC8306 comes with SerDes clocks enabled. However, MPC8306 doesn't wait for SERDES PLL lock for it to come out of reset. For MPC8306, which jitter spec (tCLK_DJ, tCLK_TJ or tCLK_DJ+tCLK_TJ) should the buffer and oscillator require to meet? The input jitter at the SD_REF CLK input is specified, Buffer vendor will have to provide jitter at the output in pk-to-pk terms so that it can be compared with the Tj at SD_REF CLK input What is the relationship between RMS jitter and peak-to-peak jitter in MPC8306? How can I calculate the RMS jitter value from our peak-to-peak jitter value (42 ps and 86 ps)? RMS jitter is only valid for Random (Gaussian distribution) jitter. This rms value is then converted to pk-to-pk value and added to Deterministic jitter (pk-to-pk) for finding the total jitter (in pk-to-pk). For SD_REF CLK, the HW specs state the value for Total jitter (in peak to peak ps) and Deterministic jitter (in peak to peak ps). rms value for Rj can be referred from PCI Express™ Jitter and BER Revision 1.0. Converting the rms to pk-to-pk is not going to help here because the buffer datasheet states the additive phase jitter. This is measured by integrating the phase noise over the frequency band of interest. DDR. “In asynchronous mode, the memory bus clock speed must be less than or equal to the CCB clock rate which in turn must be less than the DDR PLL rate." Is this statement correct for MPC8306? No it is not correct. The correct statement is " In asynchronous mode, if the ratio of the DDR data rate to the CCB clock rate is greater than 3 :1 ( i.e. DDR=3:CCB=1 ), than the DDR performance monitor statistic accuracy cannot be guaranteed."

For MPC8308 package, which is the GTX clock pin for TSEC1 and TSEC2? According to the MPC8308 ballmap, V21 is the GTX clock pin of TSEC1 and T19 is the GTX clock pin of TSEC2. Can a spread spectrum clock be used for the 66.66 Mhz DDR clock of the MPC8308? If so what percentage spread is allowed and what modulation frequency? Yes, a spread spectrum clock can be used for 66.66 Mhz DDR clock. Please refer to below table for details: Spread Spectrum Clock Source Recommendations Parameter Min Max Unit Frequency modulation — 60 kHz Frequency spread — 1.0  %

MPC8360 H/W spec describes that Max SYSCLK frequency is 100MHz. Generically when user inputs 100MHz clock, actual clock speed become more faster. I think MPC8360 has enough margin for faster SYSCLK as long as I use up to 100MHz oscillator. Is my understanding correct? Yes, your understanding is correct. As long as you use 100MHz oscillator it should be fine.

The SD card spec requires SD clock to supply for at least 74 clock cycles. On the other hand, the eSDHC controller in MPC8541 supplies about 13 SD clock cycles (with 180 degrees phase shift) at power up. Will SD card have any reliability issue by this fewer clock cycles than what is required by spec? No, SD card should not have the reliability issue. 74 clocks can be supplied by setting SYSCTL [INITA]. The 180 degree phase shift will not affect card or eSDHC IP block's operation. The phase shift is due to the synchronizer.

For MPC8568, local bus has pin LAD [0:31] and LA [27:31]. LAD [0:31] is named as Muxed Data/ Address bus while LA [27:31] as address bus. Can LAD [27:31] be used as address bus in muxed mode using LALE signal? Yes, you can mux LAD [0:26] and LA [27:31] signals. For MPC8568, should LA [27:31] be always used as five least-significant address bits for addressing any device on local bus? LAD[0:31] works in most cases, but you need to be careful in the bursting case since LAD is latched once and fixed, while LA[27:31] increments during the burst. So we recommend LA [27:31] since it always works. I am using a single 20-A switching supply for both VDD_CA and VDD_CB, and we are considering the same power circuit for the MPC8568 CPU version. Since the MPC8568 is single core, what would be the effect of the 1.1V supply still connected to the VDD_CB pins of the MPC8568? TVDD_CB pins can be connected to MPC8568, but for minimum power consumption it is recommended to leave these pins not connected. Exact amount of additional power consumption if these pins are connected for MPC8568 is not defined, but it can be as much as maximum power consumption of an additional core. I would like to vary the core frequency up to the lowest possible value which is 800MHz for MPC8568 (according to the reference manual) via Software. What are the recommended values for lowest possible core frequency and lowest platform frequency? Recommended value for lowest possible core frequency is 667MHz and that for lowest platform frequency is 600MHz.

For MPC8360, is any way that the CPU can read and write the full 72-bit wide DDR memory bus, bypassing the ECC logic? I want to know if the memory controller can be configured for the 72-bit wide DDR memory bus to bypass the ECC logic. It is not possible to bypass the ECC and read/write using full 72-bit wide bus. The controller uses the last byte lane to generate ECC info and cannot be bypassed. For MPC8360 DDR SDRAM refresh, can you please advise how to "exactly" calculate the appropriate value of [REFINT] if such worst case scenario in which refresh command issue timing is postponed is taken into account? The refresh interval should be set as high as allowable by the DRAM specifications. This should be calculated by using tREFI in the DRAM specifications, which may depend upon the operating temperature of the DRAM. In addition, to allow a memory transaction in progress to be completed when the refresh interval is reached and not violating the device refresh period, set the REFINT value to a value less than that calculated by using tREFI. The value selected for REFINT could be larger than tREFI if the DDR_SDRAM_CFG[NUM_PR] has a value higher than 1. To calculate the max possible value when DDR_SDRAM_CFG[NUM_PR] is higher than 1, use the following formula: (tREFI/clk period) x (NUM_PR) = REFINT A timing tDISKEW (skew between MDQS and MDQ) is depicted in DDR2 and DDR3 SDRAM Interface Input Timing Diagram in MPC8360 Hardware spec. For measuring tDISKEW, please instruct me from which point of the MDQS waveform and to which point of MDQ waveform should be measured? For measuring MDQS, it should be at the cross point. For case of MDQ it is derated to the VREF. Why does MCK to MDQS Skew tDDKHMH has such a high value of +/-525ps for DDR3 800M data rate for MPC8360? I am afraid that write-leveling can NOT remove all internal MCK to MDQS skew from tDDKHMH. Can you please let me know how much internal skew will be removed after write-leveling? tDDKHMH value of +/-525ps for MPC8360 part is a conservative value in the HW spec. For DDR3 with write leveling enabled, this AC timing parameter would be a non-factor.

For MPC8541, what is the maximum bit rate clock for SSI? Is it really 12.285MHz or can it be run up to platform clock / 8? Maximum bit rate clock for SSI is as per hardware spec i.e. 12.285MHz. This is the maximum speed at which the SSI IP is guaranteed to work. From a system perspective it is possible to clock it at a higher speed, but for MPC8541 that is not supported. If platform clock is 400MHz, please use appropriate values of DIV2, PSR and PM to ensure that the bit rate clock for SSI does not exceed 12.285MHz.

Please specify the DDR read only and write only counters for MPC8308. Event 19 counts DDR reads only while event 27 counts DDR writes only in MPC8308. How are DDR errors cleared in the ESUMR reg (bit 8)? Do they need to re-init the DDR? You need to clear the ERR_DEFECT [MBE] bit (write 1 to clear). After that the ESUMR bit 8 will be cleared.

This section is essentially created to help all PowerQUICC Processor users ranging from customers to designers to help provide the best solution to the most frequently encountered questions related to PowerQUICC Processor products. Feel free to browse through the various product FAQs to get answers to most commonly encountered questions on topics like DDR3, Ethernet (eTSEC), Booting, USB, Hardware Spec/Reference Manual and more. Drop a comment or two on how we can keep building these pages. Also, feel free to give your suggestions on what you feel should be added to the FAQs or to the FAQ section as a whole. We intend our Community to grow while mutually helping each other and by reducing design times by providing hands-on solution to tricky problems and questions.                                                                                                                                                                        MPC8306/MPC8306S FAQs MPC8306/MPC8306S Clocking Specific FAQs MPC8306/MPC8306S Hardware Specifications/Reference Manual Specific FAQs MPC8306/MPC8306S QUICC Engine Specific FAQs MPC8308 FAQs MPC8308 Clocking Specific FAQs MPC8308 DDR Specific FAQs MPC8308 PCIe Specific FAQs MPC8360 FAQs MPC8360 Clocking Specific FAQs MPC8360 DDR Specific FAQs MPC8535 FAQs MPC8535 Clocking Specific FAQs MPC8535 DDR Specific FAQs MPC8535 eSDHC Specific FAQs MPC8535 Hardware Specifications/Reference Manual Specific FAQs MPC8536 FAQs MPC8536 Clocking Specific FAQs MPC8536 DDR Specific FAQs MPC8536 eSDHC Specific FAQs MPC8536 Hardware Specifications/Reference Manual Specific FAQs MPC8541 FAQs MPC8541 Clocking Specific FAQs MPC8541 DDR Specific FAQs MPC8541 eSDHC Specific FAQs MPC8541 Ethernet (eTSEC) Specific FAQs MPC8541 Hardware Specifications/Reference Manual Specific FAQs MPC8541 PCIe Specific FAQs MPC8541 Power Management Specific FAQs MPC8543 FAQs MPC8543/MPC8545/MPC8547/MPC8548 GPIO Specific FAQs MPC8543/MPC8545/MPC8547/MPC8548 Hardware Specifications/Reference Manual Specific FAQs MPC8567/MPC8568 FAQs MPC8567/MPC8568 Hardware Specifications/Reference Manual Specific FAQs

Does the PCIe controller go to D3 hot state automatically if the user does not configure any registers? Should the external device be in D3 hot state explicitly before MPC8541 goes to sleep mode? PCIe controller will not go to D3 hot state automatically. Software has to write Powerstate field of PMCSR register. If the downstream component is in D3 hot state, then permissible states for Upstream component are D0-D3hot. Refer Section 5.3.2 of Base specification 1.0a The Bus states are L1 or L2/L3 Ready if the power is going to be removed. The procedure for entry into these states is described in Section 5.3.2.1 and 5.3.2.3 What internal interrupt numbers are assigned to PCIe1 through PCIe3 in MPC8541? All PCIe interrupts in MPC8541 are error interrupts and are ORed with other error interrupts to result in "Error" which is mapped to #0 of the OPIC.

Is it correct that TIMING_CFG_5[RODT_ON] and TIMING_CFG_5[RODT_OFF] do not affect internal ODT circuit for MPC8536? These values are always set in u-boot for our DDR3 based boards (e.g. P2020DS, MPC8569MDS). However external ODT is never enabled for SDRAM reads, this could lead to a conclusion that internal ODT is also affected by the TIMING_CFG_5 setting. Can you comment? TIMING_CFG_5 register is only for DRAM ODT (external ODT), this is verified and confirmed. As for your suggestion that because in most cases the read ODT on DRAM is off and hence it has something to do with internal ODT is not a valid assumption. The Read ODT for DRAM is an option available if required. In most cases it will not apply, but there may be a configuration that may require it and then the option is available for such users. Please clarify the meaning of TIMING_CFG_5 register for DDR3 controller of the MPC8536. The sentence ".. relevant ODT signal(s)" is common to all fields. What is this referring to? Is that both a) an internal signal controlling internal IOs (enabled by CFG_2[ODT_CFG]) and b) the external MODT[] signals going to the SDRAM? If yes, what is the delay between the assertion of the internal ODT signal (e.g. set by TIMING_CFG_5[RODT_ON])and actual switching of the internal RTT? These are related to the ODT timings to the DRAM. If ODT during reads is not used, then the RODT_ON and RODT_OFF values can be cleared. These are the ODT signal turn ON/OFF latency. For DDR3 it is defined as WL-2=CWL+AL-2. If one DIMM slot is used then there is no need for dynamic ODT setting.

I would like to know if output signals of blocks which are not clocked during sleep mode are driven or not. For example, are eTSEC2 RGMII signals driven during sleep mode? Yes, they would be driven but there would be no activity on them. Please note that this is for "sleep" mode NOT "deep sleep" MPC8541 supports “Wake on LAN” from the Deep Sleep. If TSEC operates via SGMII it needs for SVDD,XVDD, SVDD2,VDD2, SDAVDD and SDAVDD2 (SGMII power). All these powers are switchable in the Deep Sleep. Can we leave these rails powered in the Deep Sleep and expect that the MPC8541 will support “Wake on LAN” via SGMII? Serdes is powered down during deep sleep, so Wake up on LAN is not supported for Deep Sleep in SGMII mode. Wake on LAN is supported for RGMII. Please note only eTSEC1 supports this feature. (Assuming eSTEC1 and eTSEC2 as the nomenclature) Are there any pull-downs for signals POWER_EN and ASLEEP on the MPC8541 board? Is BVDD switched off using POWER_EN? LOE has pull down via 4.7k ohms resistor as POR config. LWE has neither pull-up nor pull-down. Yes, BVdd is switched off using POWER_EN.

Note 2 of table 13 in MPC6536 hardware spec mentions: "Peak-to-peak noise on MVREFn may not exceed +/- 1% of the DC value." What is "the DC value"? The DC value is the GVdd value. Do you have any typical estimated numbers for running at 3.0Gsb vs running at 1.5Gbs for MPC8536? Would there be any significant power savings? The 8536 SATA I/O power consumptions for 1.5Gb is 240 mW and for 3.0Gb is 270 mW.

Freescale-PC PCI express connector.