Xilinx XPS - DDR simulation / Access / Bursts

George Constantine said:

Hello!

I have a XUPV5 board. I am trying to create a DMA engine peripheral on the PLB bus.

After designing and implementing the peripheral, I developed a testbench. The waveforms comply with the PLB standard, as written in the plb_slave_burst and plb_master_burst user guides from Xilinx.

During testing of the peripheral in the system, there were a number of failures. I have narrowed them down to the following:

I scrapped the SDK application and created a simple one where microblaze writes 32 sequential words to the DDR. During simulation this doesn't work. Debugging the ilmb, microblaze executes instructions up to the write, and during the first write halts at that address.

I tried writing directly to the DDR from my PLB peripheral. This also failed.

Has anyone succeeded in writing to the DDR? Does anyone know if the MPMC controller in the base design supports bursts?

Thank you!

Click to expand...

George Constantine said:

Hi!

Thank you both for your responses!

@aruipksni
NPI was considered, at least for the DDR. Because DMA transfers could occur on any peripheral, I would prefer to remain on the PLB.

As for the design: Because of my inability to read/write to the DDR, I created a "sandbox" system using the board's definition. Only ilmb,dlmb,DDR and the microblaze core were left. I exported the design to the Xilinx SDK and created an application based on the hardware platform exported by XPS.

I created a new source file. For the sake of speed, I defined a macro for the base ddr address, then wrote 4 words.

Code:

#define BASEDDR (int*)0x90000000

int main(){
    *BASEDDR          = 0xDEADBEEF;
    *(BASEDDR + 1)  = 0xDEADBABE;
    *(BASEDDR + 2)  = 0xCAFEDECA;
    *(BASEDDR + 3)  = 0xDEAD9999;
}

The data (seems) to never be written to the ddr.

Click to expand...

aruipksni said:

Yes this is the basic check.however i sugest you to even create smaller application first just with your mb and bram and see that similar test will run on the bram. It might be that your mb doesnt work. Another thing of course is to run your test from bram and not from ddr memory space.

Click to expand...

George Constantine said:

Running a simple application that reads/writes to the bram works fine. Also writing to the plb_slave interface of my DMA engine from microblaze works ok.

Edit: In case it isn't clear, the program is loaded to the bram, using data2mem. This all runs in the simulator. I have tried both iSim and the Cadence IUS with the same results. I am beginning to consider the fact that DDR isn't simulated correctly.

Click to expand...

aruipksni said:

Well it looks like you have problems with ddr memory. First thing is to check it works with the example project. Most ddr problems are about you some missconfigured mpmc or speed problems means you need to try to reduce clock speed or mabee your board is faulty. So i guess run sample project with ddr and see if it work first. Then cross it to your nonfunctioning design see what are the differences. Then make adjustement.if still it is not working srart reduce your clock speed and check.

Click to expand...

George Constantine said:

Thank you for all your help! (And not giving up yet)!

I mentioned the board is a XUPV5. I downloaded the board support package from Xilinx.

About the board being faulty: I am running simulations (iSim), not in hardware.

EDIT: I made a mistake while writing the basic test. I forgot to use the volatile keyword, and the compiler was just writing to a register. Now, while the data of the first write appears on the bus, microblaze halts.

EDIT2: I just created a new application, using the memory test template in the SDK. This **appears** to simulate correctly (I am still testing). I added a single write to the base address in this template, and microblaze halts once again, at that address. Am I doing something wrong in my (SDK) code?

Click to expand...

George Constantine said:

Hi!

It turns out the DDR test halts the processor too. I am out of ideas.

Click to expand...