I recently pulled down SDK 1.3.2 from Freescale's SDK download site and had a chance to try and install it on a P3041DS system I have lying around. There's a lot of info in the ISO, but I thought I'd go through an initial build step by step to document what the flow is. First thing to note is that there is more than one ISO image available. I already have a Ubuntu lucid machine, that I use as a build machine. So I didn't need the virtual images. I'll need the source file - so I downloaded QorIQ_SDK_V1-3-2_SOURCE_ISO, and I am going to try this on a P3041, so I downloaded the e500mc binary. The binary isn't necessary, but it speeds up the builds significantly. When they've finished downloading, the first thing to do is mount the source ISO Within the source ISO there's an install script. I run that and let it do it's thing. Important to note that there's documentation contained within the document's directory. If you go to documents/START_HERE.html you will get html based documentation on the SDK. And, if you keep drilling down and go to documents/sdk_documentation/pdf there are some pdf documents for various features. The document QorIQ_SDK_Infocenter.pdf is a complete collection of the SDK documentation taken from the Freescale infocenter site. Once, the source is install, I do the same for the binary. Make sure you install the binary on top of the source (i.e. in the same directory). We then call the FSL poky script - which sets up the build. In this command the -m tells it what machine you're going to build to. -j indicates the number of jobs for make to spawn, and -t is how many bitbake tasks to be run in parallel. At this point I'm ready to build. I have some options for which image I want to build - I'll go with the core image, which contains some of the more common packages. So, at this point I need to make sure I'm in the build_p3041ds_release directory, and issue the command bitbake fsl-image-core which initiates the build process. When all is said and done, I can find my images in the build_p3041ds_release/tmp/demply/images directory. In my case, I have quite a few images because I've actually built the core and full images. Next, I have to grab these images and deploy them to my target.

In a previous document, I went through the basic steps of building SDK 1.3.2 for the first time. Now I'm ready to deploy the images onto my target, a P3041DS system. Fortunately my P3041 already has a U-boot and linux install on it. So I can just try and update the SDK from within U-boot. I boot up my trusty terminal - I use putty, and connect to my local COM port at 115200 baudrate. My Ubuntu server already has a tftp server installed, and I link my images over from the SDK build/deploy/images directory over to the /tftpboot directory. The QorIQ_SDK_Infocenter.pdf document within the install has information on the flash bank usage for the current SDK. Make sure you use the document and flash map from the current SDK, as things change. I ended up with a system that didn't boot when I used the older location for the fman uCode (from SDK 1.x) on the SDK 1.3.2 system. Here is a table from the document that shows the flash map for a couple of the QorIQ DS system. It's important to note here that this covers the NOR flash - which is what I'm currently using. You may want to experiment with using NAND or SPI based flash instead - but for my purposes I'm going to re-image NOR flash. The NOR on these development systems is banked, meaning that the most significant address line is tied to a DIP switch. So I can have multiple images in Flash at one time, and switch between them (especially helpful when I mistakenly corrupt one). I'm currently in bank0 (which is the "current bank" in the table above). From this, I see that the addresses I should be interested in are located at: Name Address rcw 0xe8000000 Linux.uImage 0xe8020000 uBoot 0xeff800000 fman uCode 0xeff40000 device tree 0xe8800000 linux rootfs 0xe9300000 To verify that this is correct, I can dump out my RCW: And I can also dump out my current U-boot (which should always start with an ASCII header identifying it): at this point I can start updating the images directly from my TFTP server. I have my tftp server already defined via the U-boot environment serverip, so I just tftp the U-boot image to a randomly picked address in RAM of 0x100000. The transfer went ok, so I can burn it into flash now. I will first erase the flash starting at 0xeff80000. Since U-boot is 0x80000 size, I'll erase from 0xeff80000 for size 0x80000. Apparently my sectors were protected. So I need to unprotect first, then erase again. And by reading the flash, I verify that it has been erased (erased NOR always reads back all 0xF's) So, now I can burn the flash: I use a binary copy. And then verify that the image was written correctly. Then we go through the same technique with the other images. I'll burn the fman ucode as well: Then for the actual images and dtb, you have an option of burning them, but I'll tftp them instead. For this I created a U-boot environment variable called ramboot, and point the image names to the paths on my server: At this point I can save the environment to flash via a saveenv command in U-boot. I'll re-boot into the new U-boot to make sure it works (if it doesn't for some reason, I can jump back to a different U-boot I had previously burned in the alternate bank, or else I'll have to use a debugger to re-burn the flash). Then, from within U-boot I can run ramboot, and if all goes well it should fetch the images and boot all the way into the new SDK. Eventually it should boot all the way to a linux prompt.

      A shared-MAC device is one that can be used from two Linux and/or USDPAA partitions. Shared-MAC net device can be used in two scenarios, two or more Linux separate partitions under control of hypervisor(topaz), one Linux and one USDPAA running in the same partition.       1. DPAA Ethernet Driver Types       2. BMan Driver for shared-MAC and MAC-less port       3. QMan Driver for shared-MAC and MAC-less port       4. Running  Shared-MAC between USDPAA and Linux

If SPI is not being used, how should SPI_CLK and SPI_MOSI be terminated in P1020/P1011? SPI_CLK and SPI_MOSI should be pulled up, if not used.

The SGMII SerDes of the 4080 can operate at either 1.25G or 2.5G. Is there a register to configure this or it just depends on the clock multipliers of the SerDes PLL? As long as you select the RCW settings for SRDS_PRTCL and the DIV and RATIO settings to select the clock speed, the SerDes registers will default to the correct value based on those RCW settings. Does P4080 SerDes in XAUI mode support 10GBase-CX4 (IEEE802.3 clause54)? In other words, are SerDes XAUI receivers and transmitters capable of communication over a 15 meter 10GBase-CX4 cable? P4080 is not designed for such long distances. An appropriate 10GBASE-CX4 PHY is needed to support such distances.

Can you please give more details about 32 address signals for the eLBC implementation on P2040? Below is a detailed explanation of 32 address signals for the eLBC implementation on P2040: LAD[0:15] - these are multiplexed address/data signals that need to be externally latched using the LALE signal. LA[16:31] - these are dedicated address signals. LAD[0] is the most significant address signal and LA[31] is the least significant address signal. Can the Local Bus FCM support two, 2GByte (16Gbit) NAND devices, if they are the appropriate page size (2K SLC)? FCM can support two devices, each one is connected to a separate /CS.

What is requirement for the voltage ripple of DDR3 controller MVref? The nominal value of MVref is 1.5V. 1%, +/- 7.5mV is the tolerance value for MVref (ripple range). Can you please explain the RDRVR resistance for DDR3 SDRAM memory interface? RDRVR is the "Driver" resistance. It is the resistance at the driver side. Half strength is ~40 ohms and full strength is ~20 ohms. How can I determine the power rating of the resistor connected to MDIC0 and MDIC1 for both half strength and full strength? The MDIC resistors connected to MDIC [0:1] signals used for either full or half drive strength calibration do not draw much current. So you can use 1/16W rated resistors for either half or full drive calibration.

Referring to P1011 IBIS model, there are models of various pin type. Could you please provide brief description on each model name shown below (Extracted from P1010 IBIS file)? 1) DDR related inputs: ddr2_drvr_18, ddr2_drvr_35, ddr2_rcvr_150, ddr2_rcvr_50, ddr2_rcvr_75, ddr2_rcvr_noterm, ddr3_drvr_17, ddr3_drvr_40, ddr3_rcvr_120, ddr3_rcvr_60, ddr3_rcvr_noterm 2) opdalg_out, pouv_out, rx_pzctl, tx_pzctl, ptrmr100_cm 3) v180_in_wb, v330_in_wb, v250_wb, v250_in_wb, v180_wb, v330_wb For DDR related models: Model name shows DDR type and driver impedance. For example, ddr2_drvr_18 should be used for DDR2 and 18 ohm drive strength. For opdalg_out, pouv_out, ptrmr100_cm, rx_pzctl, tx_pzctl - The pins using these models don't have any other choice of model. For v180_in_wb, v330_in_wb, v250_wb, v250_in_wb, v180_wb, v330_wb - These should be chosen for the interfaces with LVCMOS I/Os like eLBC. The numbers in the name depict the voltage level, e.g. v180_in_wb is applicable for 1.8V receiver. For other models - Those are not utilized directly for any pin so user can ignore them.

Do you have any additional info on the USB VBUSCLMP pin. The manual says that it is the divided down Vbus. What is the divisor? The P1010 RDB schematic has a diode protecting this pin. What are the critical specifications for the diode? The diode was supposed to be used for in OTG mode. Since the USB phy in P1010 doesn't support OTG, you may choose to ignore it. The VBUS operates at 5V. But VBUSCLMP operates at 3.3V. So you should implement a potential divider to bring down 5V to 3.3V as shown in RDB. In case using on-chip USB PHY, low-speed mode is not supported at all? Or it can be supported if operating in "Host" mode? Low-speed mode (LS) is supported in Host mode but not in device mode. Can you tell me whether USB internal PHY on P1010 supports UTMI+ Level3 or not? UTMI+ Level3 is supported in P1010 Please advise how power supply to USB port should be controlled when using on-chip USB PHY. Without controlling through IFC bus (via CPLD) like P1010RDB schematic, is there other way to control for it? DRVVBUS should be used to control the external VBUS supply. By mistake this signal has been shown as a ULPI signal in P1010 RM because of which P1010RDB designer have not used it for externals VBUS control. About USBVDD1_8(J21,K21), on HWspec Table1 Notes 20 says that "20.This pin should be connected to Vss through 1μF.No need to supply power to this pin. 1.8V output may be observed on this pin during normal working conditions." Is it okay to tie J21 and K21 pins together and connect to Vss via a "single" 1uF capacitor? Or 1uF cap is required for each pin respectively? It should be okay to combine both the pins and connecting to Vss via single 1uF capacitor. If the whole USB (controller and PHY) is not used, user still needs to supply USBVDD3_3 power, Right? What is the reason?  Yes it is required to provide USBVDD3_3 even if USB controller and PHY are not used at all. This is a requirement from design to keep the logic in a sane state. If the whole USB is not used, does user need to follow power sequencing of USBVDD3_3, assuming USBVDD3_3 supply needs to be present? Following the sequence between USBVDD3_3 and other 3.3V supplies is not required. It is must to provide supply to USBVDD3_3 even if the USB PHY is not used. A suggestion, if USB PHY is not used customer can supply this pin with the same regulator which would be used to supply other 3.3V supply pins of SoC. Make sure that the ramp rate constraint is still followed for USBVDD3_3.

Time division multiplexing(TDM) is a communication term for multiplexing several channels on the same link. QUICC multi-channel controller(QMC) is a firmware package which uses a unified communication controller(UCC) working in slow mode. The QMC is used to emulates up to 64 time-division serial channels through a time-division-multiplexed(TDM) physical interface. Each of QMC channels can be independently programmed to support either HDLC or transparent protocols. This document introduces TDM QMC driver implementation in Linux Kernel for the processors with QE UCC working in slow mode. Data flow over a QMC channel involves a TDM line and a UCC, working in slow mode. For each channel, Tx data flow consists of data transfer from the external memory to the TDM physical connection. Rx data flow consists of data transfer from the TDM physical connection to the external memory. In both data flows, the major stations are: data buffers, UCC, and the TDM line. Please refer to the following figure for the data flow, the driver requires to configure two levels of routing tables. The first level consists of the SI RAM routing tables, Tx and Rx, which are common to other controllers as well. 1. QE TDM QMC Driver Introduction 2. Driver Architecture and Components 2.1 QMC Driver Memory Allocation 2.2 QMC and TDM Devices Initialization 2.2.1 SI RAM entry initialization 2.2.2 UCC Slow Mode QMC Initialization 2.2.3 QMC Channel Initialization 2.2.4 QMC TSA Slot Initialization 2.3 QMC Channel Interrupt Handling 2.4 QMC and TDM Configuration 2.4.1 Enable and Configure QMC Channel 2.4.2 Enable QMC 2.4.3 Enable TDM 3. QMC TDM Driver Calling Sequence 4. QMC TDM DTS Definition 5. Configure QMC TDM Driver and Running the Testing Program

For P2010/P2020, 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 P2010/P2020 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 P2010/P2020 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 P2010/P2020? 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 P2010 part is a conservative value in the HW spec. For DDR3 with write leveling enabled, this AC timing parameter would be a non-factor.

To enable SD interface in SPI boot on P1010RDB: 1. Perform the following updates in u-boot a) Modify pmuxcr to enable SD bus in case of SPI boot b) Update the corresponding static mux implementation in u-boot 2. Perform the following updates in Linux a) Disable IFC from device tree and kernel defconfig The patch details to enable SD interface are given below. A zip file, AN4336SW.zip, containing the patches for u-boot and Linux accompanies this application note. The file can be downloaded from [1]. U-Boot   Extract the u-boot code from the QorIQ SDK 1.0.1 iso   Apply the patch, u-boot-p1010rdb-enabling-sd-in-spi-boot.patch   Compile the u-boot using "make" command for SPI Flash    make ARCH=powerpc   CROSS_COMPILE=/opt/freescale/usr/local/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc-linux-gnu- P1010RDB_SPIFLASH   Use the boot_format utility to generate the spiimage. For more information, see SDK manual.   Update the SPI Flash with the above built spiimage Linux Extract the Linux source code from QorIQ SDK 1.0.1 iso Apply the patch, linux-p1010rdb-enabling-sd-in-spi-boot.patch Compile Linux using make command #make ARCH=powerpc  CROSS_COMPILE=/opt/freescale/usr/local/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc-linux-gnuarch/  powerpc/configs/qoriq_sdk_nonsmp_defconfig  #make ARCH=powerpc  CROSS_COMPILE=/opt/freescale/usr/local/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc-linux-gnu- Compile the dts ./sripts/dtc/dtc -f -I dts -O dtb -R 8 -S 0x3000  arc/powerpc/boot/dts/p1010rdb.dts.dts > p1010rdb.dtb.dtb With the updated SPI bootloader, Linux uImage and p1010rdb.dtb, the user must be able to enable SD interface on P1010RDB. NOTE The above-mentioned changes must be done only when the user specifically requires the SD interface using SPI boot. For all other boot methods, these patches must not be used.

P1010 has only a single pair of MCK signal, while my device has four Chip Select signals. In a scenario connecting a lot of memory devices under four CS, can the single pair of MCK really drive all of memory devices which are connected by fly-by topology on each CS? In case of P1010 (which has only one MCK), is it really practical to connect DDR3 memory devices under all of four CS? Would it be necessary to use "external CLK buffer" in such a case using four CS? P1010 was designed for low-cost systems, and as such some of the pins seen on other QorIQ devices (CKE2/3, ODT2/3) were removed to save on cost. For a single-rank, fly-by topology, only one CS would be used. If more ranks were needed, this would be addressed with stacked memories (DDR3 devices that take up to four CS signals). How does one set up the P1010 or P1014 for a 16 bit data bus size? To set the data bus width, you need to set DDR_SDRAM_CFG[DBW] bits of the register given in section 9.4.1.7, Page-9-20 of P1010RM Rev-B. Is it allowed to use four chip-selects with P1010? In my understanding, one ODT signal should be used and be controlled per chip-select? However P1010 has two MODT. P1010 is designed to use only one chip select with discrete DDR3 DRAM. This requires one CS, one ODT, and one CKE with one clock pair. Additional CS/ODT/CKE are designed for using stacked die DDR3 DRAMs. The four CS, two ODT & CKE, are useful if dual or quad stacked die discrete DDR3 DRAM were used. For the write leveling, does the P1010 use DQ[0,8,16,24] or use all DQ bit to drive status back to the DDR controller? P1010 DDR controller can support the write leveling status on any of the data bits within the data byte from a JEDEC standard DDR3 SDRAM.

The SGMII SerDes of the 3041 can operate at either 1.25G or 2.5G. Is there a register to configure this or it just depends on the clock multipliers of the SerDes PLL? As long as you select the RCW settings for SRDS_PRTCL and the DIV and RATIO settings to select the clock speed, the SerDes registers will default to the correct value based on those RCW settings. Does P3041 SerDes in XAUI mode support 10GBase-CX4 (IEEE802.3 clause54)? In other words, are SerDes XAUI receivers and transmitters capable of communication over a 15 meter 10GBase-CX4 cable? P3041 is not designed for such long distances. An appropriate 10GBASE-CX4 PHY is needed to support such distances.

Usually, when I turn on the option of "reset target on launch" CW resets CPU again while connecting to CPU. With P1015, CodeWarrior (CW) does not connect to CPU when the option is on, only when I disable the option, CW can connect to CPU. What could be the problem? . "Reset target on launch" asserts HRESET to the target, thereby resetting the hardware. In most cases this is a required step, but where you don't want to assert HRESET or where your Target Initialization (.cfg) file does this for you with the "reset 1" command, you can do without this option enabled. "P10xx-P20xxRDB_P1011_jtag.txt" JTAG Configuration file is required by 8.8 CW PA for all single-core P10xx processors. Please load the “P20xxRDB_P1011_jtag.txt" JTAG Configuration file in your USB TAP configuration panel you mentioned about. 1) Set MACCFG1[Rx_Flow] && MACCFG1[Tx_Flow] to 1 2) Set RCTRL[LFC] to 1.

Routing the DDR Memory Channel To help ensure the DDR interface is properly optimized, Freescale recommends routing the DDR memory channel in this specific order: 1. Data 2. Address/command/control 3. Clocks Note: The address/command, control, and data groups all have a relationship to the routed clock. Therefore, the effective clock lengths used in the system must satisfy multiple relationships. It is recommended that the designer perform simulation and construct system timing budgets to ensure that these relationships are properly satisfied. Routing DDR3 Data Signals The DDR interface data signals (MDQ[0:63], MDQS[0:8], MDM[0:8], and MECC[0:7]) are source-synchronous signals by which memory and the controller capture the data using the data strobe rather than the clock itself. When transferring data, both edges of the strobe are used to achieve the 2x data rate. An associated data strobe (DQS and DQS) and data mask (DM) comprise each data byte lane. This 11-bit signal lane relationship is crucial for routing (see Table 1). When length-matching, the critical item is the variance of the signal lengths within a given byte lane to its strobe. Length matching across all bytes lanes is also important and must meet the t DQSS parameter as specified by JEDEC. This is also commonly referred to as the write data delay window. Typically, this timing is considerably more relaxed than the timing of the individual byte lanes themselves: Table 1: Byte Lane to Data Strobe and Data Mask Mapping Data Data Strobe Data Mask Lane Number MDQ[0:7] MDQS0, MDQS0 MDM0 Lane 0 MDQ[8:15] MDQS1, !MDQS1 MDM1 Lane 1 MDQ[16:23] MDQS2, !MDQS2 MDM2 Lane 2 MDQ[24:31] MDQS3, !MDQS3 MDM3 Lane 3 MDQ[32:39] MDQS4, !MDQS4 MDM4 Lane 4 MDQ[40:47] MDQS5, !MDQS5 MDM5 Lane 5 MDQ[48:55] MDQS6, !MDQS6 MDM6 Lane 6 MDQ[56:63] MDQS7, !MDQS7 MDM7 Lane 7 MECC[0:7] MDQS8, !MDQS8 MDM8 Lane 8 DDR Signal Group Layout Recommendations Table 2 lists the layout recommendations for DDR signal groups and the benefit of following each recommendation: Table 2: DDR Signal Groups Layout Recommendations Recommendation Benefit Route each data lane adjacent to a solid ground reference for the entire route to provide the lowest inductance for the return currents Provides the optimal signal integrity of the data interface Note: This concern is especially critical in designs that target the top-end interface speed, because the data switches at 2x the applied clock When the byte lanes are routed, route signals within a byte lane on the same critical layer as they traverse the PCB motherboard to the memories Helps minimize the number of vias per trace and provides uniform signal characteristics for each signal within the data group Alternate the byte lanes on different critical layers Facilitates ease of break-out from the controller perspective, and keeps the signals within the byte group together

As P1025RM.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. P1025 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 P1025/P1016, for UTOPIA pins UPC1_RxADDR [2:4]/UPC1_TxADDR [2:4], each signal has two pins described in p1025RM. 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 P1025/P1016, 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 P1025/P1016 reference manual.

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."

Routing the DDR Memory Channel To help ensure the DDR interface is properly optimized, Freescale recommends routing the DDR memory channel in this specific order: 1. Data 2. Address/command/control 3. Clocks Note: The address/command, control, and data groups all have a relationship to the routed clock. Therefore, the effective clock lengths used in the system must satisfy multiple relationships. It is recommended that the designer perform simulation and construct system timing budgets to ensure that these relationships are properly satisfied. Routing DDR3 Data Signals The DDR interface data signals (MDQ[0:63], MDQS[0:8], MDM[0:8], and MECC[0:7]) are source-synchronous signals by which memory and the controller capture the data using the data strobe rather than the clock itself. When transferring data, both edges of the strobe are used to achieve the 2x data rate. An associated data strobe (DQS and DQS) and data mask (DM) comprise each data byte lane. This 11-bit signal lane relationship is crucial for routing (see Table 1). When length-matching, the critical item is the variance of the signal lengths within a given byte lane to its strobe. Length matching across all bytes lanes is also important and must meet the t DQSS parameter as specified by JEDEC. This is also commonly referred to as the write data delay window. Typically, this timing is considerably more relaxed than the timing of the individual byte lanes themselves: Table 1: Byte Lane to Data Strobe and Data Mask Mapping Data Data Strobe Data Mask Lane Number MDQ[0:7] MDQS0, MDQS0 MDM0 Lane 0 MDQ[8:15] MDQS1, !MDQS1 MDM1 Lane 1 MDQ[16:23] MDQS2, !MDQS2 MDM2 Lane 2 MDQ[24:31] MDQS3, !MDQS3 MDM3 Lane 3 MDQ[32:39] MDQS4, !MDQS4 MDM4 Lane 4 MDQ[40:47] MDQS5, !MDQS5 MDM5 Lane 5 MDQ[48:55] MDQS6, !MDQS6 MDM6 Lane 6 MDQ[56:63] MDQS7, !MDQS7 MDM7 Lane 7 MECC[0:7] MDQS8, !MDQS8 MDM8 Lane 8 DDR Signal Group Layout Recommendations Table 2 lists the layout recommendations for DDR signal groups and the benefit of following each recommendation: Table 2: DDR Signal Groups Layout Recommendations Recommendation Benefit Route each data lane adjacent to a solid ground reference for the entire route to provide the lowest inductance for the return currents Provides the optimal signal integrity of the data interface Note: This concern is especially critical in designs that target the top-end interface speed, because the data switches at 2x the applied clock When the byte lanes are routed, route signals within a byte lane on the same critical layer as they traverse the PCB motherboard to the memories Helps minimize the number of vias per trace and provides uniform signal characteristics for each signal within the data group Alternate the byte lanes on different critical layers Facilitates ease of break-out from the controller perspective, and keeps the signals within the byte group together

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.