Xilinx XPS - DDR simulation / Access / Bursts

[George Constantine]

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!

 

[aruipksni]

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!

Why not use npi interface instead of plb. I think you first need to establish a basic stsble system. If you cant test the ddr from mb then your design is faulty. Just try first thr example project on the card and check how it works. Then you can expand the design furthet more but you will have to be caution about every modification you make.

 

[permute]

Make sure you have the addressing and configuration done correctly and that the ram has calibrated correctly.

 

[George Constantine]

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.

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

 

[aruipksni]

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.

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

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.

 

[George Constantine]

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.

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.

 

[aruipksni]

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.

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.

 

[George Constantine]

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.

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?

 

[aruipksni]

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?

1. if i continue the volatile isssue - try to remove code optimisaition - there is a switch that does it.
2. if ddr test code seem to pass ( i magine it checks a block of code) so are you shure you write to valid ddr memory mapped address ? use same addresses in the DDR TEXT application.
look at system.h header files for DDR base address.

 

[George Constantine]

Hi!

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

 

[aruipksni]

Hi!

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

i think mabbe your just try to use the good old fassion way (with all respect to cpu simulators) .
connect your jtage cabel to the board.
download the bitsream to the target.
connect a uart or usb uart and see what's happen.
of course you can single step with the debugger, and check line by line.