Does P1025 support 16 bits DDR3? I found DDR_SDRAM_CFG{DBW] can be set to 16bits. But no 16bits DDR3 feature is claimed? Theoretically the DDR controller supports 16 bit mode. But the mode has not been tested/verified/validated in P1025. We recommend you to not use 16 mode of P1025. “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 P1025? 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 P4040, does DDRCLK and PCIe (SerDes) ref clock support a spread spectrum reference? DDRCLK and PCIe (SerDes) ref clock support spread spectrum. Please note that since SGMII doesn't support spread spectrum, if SGMII is used on any SERDES lane, spread spectrum should not be applied to SERDES REF clock. What are the DDRCLK and PCIe (SerDes) reference clock spread spectrum parameters for P4040?  DDRCLK and PCIe (SerDes) reference clock are designed to work with a spread spectrum clock (+0 to –0.5% spreading at 30–33 KHz rate is allowed), assuming both ends have same reference clock. For better results, a source without significant unintended modulation should be used.

Can a spread spectrum clock be used for the 66.66 Mhz DDR clock of the P1023? 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  % For P1023 package, which is the GTX clock pin for TSEC1 and TSEC2? According to the P1023 ballmap, V21 is the GTX clock pin of TSEC1 and T19 is the GTX clock pin of TSEC2.

P1016 spec says that the QUICC engine periodically polls its Rx/Tx rings and if a BD is not empty, checks the ownership flag and moves to the next step. How does the user application trigger/control the QE to start polling? For TX BD ring, (after configured) QE will periodically poll the ring and process the BD that is not empty and then move to next BD. When a BD is actually transmitted, a "transmission complete" event (and interrupt if enabled) will be generated, so the BD/Buffer can be released. For RX BD ring, (after configured) QE will pre-fetch a BD and then process the BD when data is received. When a packet (frame) is received, a "received" event (and interrupt if enabled) will be generated, so the BD/Buffer can be released/processed. If no empty BD is available during the pre-fetch, an "out-of-BD" error will be reported. Is there any suggested approach to determining the tx/rx ring buffer sizes on the peripherals that interface to the UCC? How can I decide on the ring size? The bandwidth would be 45 Mbps. The MTU on the serial interface can range up to 16k Bytes. Even if MTU could be 16K bytes, the average frame could be much smaller. Find out the average frame size and pick up a buffer size that is bit larger than the average frame size. This usually creates a good balance of efficiency between processing time and memory usage. It is much more efficient in terms of processing time to process a frame of 16K in one BD/Buffer of 16K size than in 16 BDs/Buffers of 1K size. However, if all buffers are 16K size while 90% of the frames are 1K, most memory is wasted. Generally, the ring size should be equal to the number of BD’s required to accommodate the largest possible frame size + 4 extra BDs. However, over here the bandwidth is relatively high (45M) and could be quite bursty. Hence we would suggest starting with "TWO largest possible frame size + 4 extra BDs"

The on-chip ROM code does not set up any local access windows (LAWs). Access to the CCSR address space or the L2 cache does not require a LAW. It is the user’s responsibility to set up a LAW through a control word address/data pair for the desired target address and execution starting address (which is typically in either DDR or local bus memory space). Required Configurations for SD Card/MMC Booting The configuration settings required to boot from an SD card/MMC are as follows: Ensure that cfg_rom_loc[0:3] (Boot_Rom_Loc) are driven with a value of 0b0111. Only one core can be in booting mode. If your device has multiple cores, all other cores must be in a boot hold-off mode. The CPU boot configuration input, cfg_cpux_boot, should be 0, where x is from 1 to n (n = the number of cores). Booting from the eSDHC interface can occur from different SD card slots if multiple SD card slots are designed on the board. In this case, ensure the appropriate SD card/MMC is selected For example, on the P5010 board, bit 7 of the SW8 is used to select which SD/MMC slot is used. If SW8[7] = 1, an SD card/MMC must be put to the external SD card/MMC slot (J1). TIP The polarity of the SDHC_CD signal should be active-low.  Required Configurations for EEPROM Booting The configuration settings required to boot from an EEPROM are as follows: Ensure that cfg_rom_loc[0:3] (Boot_Rom_Loc) are driven with a value of 0b0110. Only one core can be in booting mode. If your device has multiple cores, all other cores must be in a boot hold-off mode. The CPU boot configuration input, cfg_cpux_boot, should be 0, where x is from 1 to n (n = the number of cores). The eSPI chip select 0 (SPI_CS[0]) must be connected to the EEPROM that is used for booting. No other chip select can be used for booting. This is because during booting, the eSPI controller is configured to operate in master mode. Booting from the eSPI interface only works with SPI_CS[0].

Please specify the DDR read only and write only counters for P1023. Event 19 counts DDR reads only while event 27 counts DDR writes only in P1023. 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.

What is the integrated phase noise jitter requirement for SD_REF_CLK and SYSCLK for P2041? We don't have the integrated phase noise jitter, the SYSCLK we defined the period jitter and phase noise. For SD_REF_CLK, we follow the PCIe industrial standard spec and it defined peak-to-peak jitters. What is the PLL loop bandwidth of internal PLL in P2040 which uses 100MHz and 125MHz refclks from system? The PLL loop bandwidth of internal PLL is >= 500 KHz. The PLL bandwidth varies with many factors including ref clock rate.