Xilinx Virtex 7 memory controller

Hello,

I'm working on a system with a Virtex 7 FPGA and DDR3 memory and I want to check the bandwidth of the DDR3 interface.

Is there a debug signal in the Xilinx Virtex 7 memory controller that strobes only when the bus is "busy" (either reading / writing / or precharging data) ?

You question is very specific and I haven't work in depth with the MIG DDR3 so I can answer only in vague.

During the IP-gen stage, you can choose the option to activate debug signals. There could be a possible debug signal among the many others that meet you criterion.

Study the example design simulation closely after having activated the debug signals.

IIRC, your method might not be correct. IIRC, the xilinx DDR3 controller does a lot of pilot reads -- reads of whatever was read last -- in order to keep the IO calibrated. Just looking at active cycles isn't a good choice. you should come up with a test that is more specific to your application.

I agree with all said.
However, I'm dealing here with a given design.

The application logic writes to the whole address space of the memory controller and then reads back the data.

The design fails to meet the required bandwidth and I think it happens because of inefficienties in the part of the user code that manages the DDR controller.

However, to prove it's not the DDR controller's fault, I've been asked to measure it's bandwidth (without any changes to the application's logic).

All I need is an "I'm not idle" signal from the DDR controller (this signal will be asserted when the controller is busy moving data + doing all the house keeping associated with it...).

My first thought is that the controller might be in BC4 mode vs BL8 mode. It is easy to confuse BC4 with BL4 without realizing there is a reduction in bandwidth. The second thought would be a poor choice of rank-bank-row-column address bits to user address bits.

After that, I would look at the source code for the controller and try to find something in a state machine that matches what you want. I don't think anything exists for your exact circumstance that is exposed. I would also look at this more in terms of the number of cycles where the user logic wants to transfer data but cannot. If the controller is thrashing -- doing mostly row operations -- it would show up as high performance. In such a case, the issue could be with the controller or the user logic.

My first thought is that the controller might be in BC4 mode vs BL8 mode. It is easy to confuse BC4 with BL4 without realizing there is a reduction in bandwidth.

Click to expand...

This has been excluded prior to posting.

The second thought would be a poor choice of rank-bank-row-column address bits to user address bits.

Click to expand...

Maybe. but I can't find any information that describes the mapping between the user address bits and the DDR address lines. I.E - how would I know what address bits on the APP side control the bank address?

shaiko said:

Maybe. but I can't find any information that describes the mapping between the user address bits and the DDR address lines. I.E - how would I know what address bits on the APP side control the bank address?

Click to expand...

It's a setting in MIS. You can use either row,bank,col or bank,row,col. See ug586 Fig 1-21