We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

AR# 25154

MPMC2 v1.8 - Tips and Hints for Debug and Bring-Up of MPMC2 Designs


Are there any hints or tips for debugging an MPMC2 design?

When creating a webcase, please try to include information about which of these suggestions/tips you have implemented and what the results are.

When filing a webcase for support, provide as much information as possible.

Get the control.txt from the pcores directory and the system.mhs. In some cases the system.ucf is required.


This section describes ideas for debugging and bringing up an MPMC2 system.

1. It is recommended that new users start from one of the included reference design that most closely resembles the system they are trying to build and use the reference design as a starting point to model.

2. Make sure your design has memory at the boot vector of the processor. so that the processor starts up and has valid code to run out of reset. The boot code can be as simple as a branch to itself instruction ("bootloop"). After the processor boots and is stable, user can connect with XMD to write/read memory or load larger programs. User should not allow processor to have undefined memory at the boot vector or else erratic behavior may result.

a. Address 0xFFFFFFFC on PPC

b. 0x00000000 on MicroBlaze

3. Make sure your design meets timing and that proper timing constraints are in effect when running a design through the tools.

4. When bringing up MPMC2 on a new board, start with as simple of a design as possible and establish a working connection to memory before adding more ports.

5. If experiencing problems, try running at slower end of clock frequency range supported by your memory. This provides more timing margin for initial testing before trying higher frequencies

6. Use Chipscope to look at transactions across the PIMs or inside MPMC2 to help isolate problems

7. Try to run simulations of your design.

8. During memory initialization (following reset), the memory physical interface writes to the bottom locations in memory to set up the write training pattern. This can affect addresses between 0x00000000 and 0x000000FF. Therefore, after reset, these locations in memory will be overwritten. It is recommended that user software code stored in memory not start at address 0x0000000 of the memory. Software code should start at an address that is 0x100 offset into memory and the boot vector set to jump to this offset address.

For example, a PPC405 system would be set to boot at 0xFFFFFFFC and then jump to 0x00000100 in memory to start executing code out of memory. As an example, look at the software compile options in the MPMC2 reference designs.

9. When using ECC in debug mode, hardware considerations need to be taken into account when forcing errors. As a simple example, let us take a design with a memory that has 32 data bits and 4 ECC bits. In this case, every clock cycle, 64-bits of data will be written to memory. If you force a single bit error, the error will show up somewhere in the 64-bit range. If you did a 32-bit write to address 0x0 in your software, the error could either show up at address 0x0 or at 0x4. Additionally, since the burst length to memory is 4 data beats (4x32-bits), and since ECC requires read-modify-write, you will actually write one data error at either address 0x0 or 0x4, and one error at either 0x8 or 0xC. Now, if you read data from 0x0, your ECC status errors will report one error. However, if you write to address 0x0, you are going to do a read modify write, so you will read 4x32-bits of data, then modify address 0x0 and write it back. This will report two errors rather than one since you also read addresses 0x8 and 0xC.
AR# 25154
Date 04/14/2011
Status Archive
Type General Article
Page Bookmarked