I don’t use SDHC, and we use SPI at 2.5V (CVDD=2.5V). In this case for P3041 unused SDHC pins are pulled up to 2.5V. If I want to maintain compatibility with P4040, what happens when unused SDHC pins (SDHC_DATA [0-3], SDHC_CMD) in P4040 are pulled up to 2.5V instead of 3.3V?
As long as the pullup on these pins satisfies the minimum Vih of 2.0 V for a 3.3V input then this would be ok. Alternative is to pull to ground.
I want to lower the CPU power consumption with make CPU frequency from 1.2GHz to 1 GHz or 800 MHz for P1031 hardware. When P3041core is configured to be 1GHZ/ 800 MHz, what is the core’s power consumption?
If you disable L2 cache, you can use 47mW/100MHz per core for lower bins. If L2 is not disabled, then you need to use 65mW/100MHz per core for the lower bin.
If I don’t use SDHC, how should I connect the SDHC_DATA and SDHC_CLK?
SDHC is output signal and you can leave as NC. It shouldn't matter to either pull-up or pull-down for unused SDHC interfaces.
In Freescale P3041_DS schematics, the "HRST" button is connected to the LRST_B signal which is routed to the FPGA. What logic is applied to the LRST_B signal inside the FPGA, and what is the FPGA output signal connected to on the CPU?
LRST is one of the Reset sources that is coming from the Pushbutton.
It will cause: CPU_PORESET CPU_TRST And Peripheral_reset (PHY_RST_B, GEN_RST_B, SGMII_XAUI_SLOT_RST_B)
I do not use Secure Boot feature in my P3014 design. What should I do with Vdd_LP pin?
If Secure Boot feature is not to be used, VDD_LP can be left unconnected, but should be tied to GND to reduce noise.
I have Nor Flash, Nand Flash, NVRAM and CPLD connected on eLBC with data buffer in between. All devices are in high impedance when not selected. Should the OE of data buffer be connected to GND directly or by using “AND” gate with CS0, CS1…CSn as the OE?
It should be “AND”ed with all used CSn to generate the OE. This can prevent any potential data bus conflict.
Does access to CCSR & DCSR registers require CoreNet usage in P3041? Can a SEU single-bit error in any CoreNet register prevent further reading from internal config registers?
Yes, CCSR/DCSR accesses go through CoreNet. There is no ECC on CCSR internal registers so there is no automatic scrubbing or repair that is possible. So such prevention is not possible.