Deepfifo AXI query

[Guest]

Hi,

I have a rather strange issue when using your module with a MIG4. In simulations, this works perfectly, but on HW, the MIG pulls down the WREADY after the WADDR 0x4000 mark (data width is 256 bits). The reason I'm posting this here is because the same MIG works fine in all my other designs, so I was wondering if there is something about the deepfifo AXI master. The waveforms look fine, though. Each AW phase initiates a burst of 16 and the responses seem correct until the 2nd beat of the burst where address reaches 0x4000. Then WREADY drops and stays low.

Any clues will be appreciated.

Ameet

[support]

Hello,

Let me ask a possibly stupid question: Is this a problem? Does this cause Deepfifo not to work properly?

Was the MIG controller requested a burst longer than a single word on that last burst that turned out to be only one beat long?

The thing is that Deepfifo uses the external memory only for preventing the block RAMs from overflowing with data. So if the data consumer begins reading data at a reasonable rate, it may very well be that Deepfifo stops using the DDR memory, and manages everything with the block RAMs.

Regards,
Eli

[Guest]

Ah, apologies! I should have been clearer. I am holding the read enable of the post FIFO low. I wanted to force non bypass mode to see if it would fill the entire 1GByte of DDR space. The write bandwidth into the pre FIFO is about 25Gbps, which is much lower than the bandwidth that the interconnect or the MIG4 are configured for.

[support]

Hello,

This is odd indeed. I guess the way to figure this out is to check all AXI signals and verify that nothing fishy goes on there. And since you have other designs working with the same MIG controller, maybe compare with them.

Regards,
Eli

[Guest]

Thank you, Eli. I will debug this further.

[Guest]

This is just strange. The MIG4 dies at address 0x4000 (16KB) and pulls AWREADY low. I am now sure it is not connected to throughput, because it stops at the same address regardless of the FIFO rate. If I replace the MIG with a BRAM, writes run all the way through the size of the RAM (as expected).

Any chance this has been encountered at your end in your initial FPGA bringup when you were first testing this IP? I know that this should mean the issue lies at the AXI endpoint and not in the deepfifo, but the same MIG works fine in other setups. The only difference is that there it is part of a processor's address map as well. Here it is just mapped as 0x0-0x3FFF_FFFF (1GB). But again, this is handled by decoding in the interconnects.

It's almost as if something is holding up the MIG's command FSM. But why, oh why?

[support]

Hello,

I know for a fact that deepfifo has been used in quite a few projects, only judging by those who turn up with questions. And I'm probably seeing just the tip of the iceberg. So had there been a problem as serious as you describe with deepfifo, I should have known about it long ago.

The only thing I can suggest is to double-check the instantiation parameters (in particular log2_word_width, which I guess should be 8 as you use a 256 bit interface). But then comes the question why the simulation ran so nicely.

Other than that, I would suggest writing a small module that issues the same bursts to the MIG controller and see what happens.

You mentioned that in the previous design the memory was shared by a processor's memory map. So there was some AXI switch involved, I guess. Maybe it fixed something that doesn't get fixed now. Just a wild guess.

When you find the problem, please come back and write about it. I'm really curious what's going on.

Regards,
Eli

[Guest]

Arrrgh! I had messed up the WLAST assignment in one spot. The BRAM AXI controller didn't complain, but the MIG did, and I decided to put an ILA on that at the very end. I'm concatenating FIFO's to create higher throughput by using multiple DDR controllers.

My apologies! This was a brain freeze on my part. Everything works just fine.

[support]

All's well that ends well.