What are the control register descriptions for Frame Buffer IP (V13.1)?

[VCham]

Hello,

We are creating a video streaming pipeline using Altera IP cores and a Cyclone V FPGA. Our pipeline currently consists of a sensor, Clocked Video Input IP (V14), Frame Buffer IP (V13), and on-chip memory.

Our current behavior shows non repeating data being loaded into on-chip memory; however, our register reads give confusing results. Using NIOS II we read the run-time writer control port from the Frame Buffer IP and get the following data.

Register 0 : 1h

Register 1 : 1h

• starts out at 0h and increments once

Register 2 : 2h

• starts out at 0h and increments twice

Register 3 : 2ch

• starts out at 0h
• starts increment after Register 2 reaches 2h

Available documentation varies and is vague. Some documentation would suggest that we load two frames, and then drop the rest. However, I've seen one instance of Register 2 being listed as an Interrupt Register, and Register 3 as the Frame Counter.

Additionally, frame dropping is enabled in the Frame Buffer IP GUI. Prior to frame dropping being enabled, the CVI IP would indicate an overflow after passing 2 frames.

Can anyone confirm what the registers are for our version of the Frame Buffer IP? And in the case that we are in fact dropping all our frames due to an over flow issue, are there suggestions on how to fix this?

[CheePin_C_Intel]

Hi,

As I understand it, you are inquiring about the Frame Buffer IP control register details. For your information, just wonder if have had a chance to refer to the VIP Suite user guide for your specific version of Frame Buffer IP? As I look into the user guide v16.0, I can see a specific section "Frame Buffer Control Registers" which might be something that you are looking for.​ However, since you are using Frame Buffer IP v13.1, it would be great if you could refer to that specific version of user guide.

[VCham]

Yes. We did manage to find a V13.1 User Guide. This confirms that our application is loading 2 frames and then dropping the rest. We are confused by this behavior since data is still being loaded into the on-chip memory.

Aside from setting the go-bit is there something else that needs to be done in order to clear the internal buffers so that frames stop being dropped?

[CheePin_C_Intel]

Hi, As I understand it, you observe CVI overflow prior to the frame dropping. To further narrow isolate possible causes of the frame dropping or CVI overflow, it would be great if you could create a simple test design with TPG -> Frame Buffer -> CVO and run through Modelsim simulation to see if similar issue observed. If no issue observed, then you can try out in hardware. This could further isolate out CVI related issue from the debugging. Thank you. Best regards, Chee Pin