Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Xilinx XPS - DDR simulation / Access / Bursts

Status
Not open for further replies.

George Constantine

Newbie level 4
Joined
Jul 16, 2013
Messages
5
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
48
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!
 

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.
 

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

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.
 

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.

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.
 

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.
 
Last edited:

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.
 

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?
 
Last edited:

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.
 

Hi!

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

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.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top