HDMI RX example and MIG, VDMA,CDMA problem

[sitting]

Hi,

I generated the HDMI example design on our custom board (Kintex7-325T), it worked fine and RX could receive infoframes.

When I add MIG, VDMA,CDMA and BRAM controller to my block design attached as below , HDMI RX didn't receive any infoframes. How can I do?

Thanks,

Sitting

[samk]

Hi @sitting,

How are you checking for receive of infoframes?

What clock speed are you running your MicroBlaze at?

What resolution are you using to test?

Regards,

Sam

[sitting]

Hi @samk,

Here is my code. My Microblaze is 150 MHz, and my test resolution is 3840*2160@60Hz.

void RxAuxCallback(void *CallbackRef) {
#ifdef XPAR_XV_HDMITXSS_NUM_INSTANCES

	XHdmiC_Aux *AuxPtr;
	AuxPtr = XV_HdmiRxSs_GetAuxiliary(&HdmiRxSs);
	/* In pass-through mode copy some aux packets into local buffer.
	   GCP does not need to be sent out because GCP packets on the TX side is
	   handled by the HDMI TX core fully. Starts storing Aux only when TX
	   stream has started to prevent AuxFifo Overflow.
	*/
	if(AuxPtr->Header.Byte[0] == AUX_VSIF_TYPE){
		//xil_printf("0x83.Byte[1]:%x\r\n",AuxPtr->Data.Byte[1]);
		//xil_printf("0x83.Byte[2]:%x\r\n",AuxPtr->Data.Byte[2]);
		//xil_printf("0x83.Byte[3]:%x\r\n",AuxPtr->Data.Byte[3]);
		//xil_printf("0x83.Byte[4]:%x\r\n",AuxPtr->Data.Byte[4]);
		//xil_printf("0x83.Byte[5]:%x\r\n",AuxPtr->Data.Byte[5]);
		//xil_printf("0x83.Byte[6]:%x\r\n",AuxPtr->Data.Byte[6]);
	}
	else if(AuxPtr->Header.Byte[0] == AUX_AVI_INFOFRAME_TYPE){
		RGB_range=(AuxPtr->Data.Byte[3] >> 2) & 0x3;
		YCC_range=(AuxPtr->Data.Byte[5] >> 6) & 0x3;
		Scan_range=AuxPtr->Data.Byte[1] & 0x3;
		Color_format=(AuxPtr->Data.Byte[1] >> 5) & 0x7;
		//xil_printf("0x82.Byte[3]:%x\r\n",AuxPtr->Data.Byte[3]);
		//xil_printf("0x82.Byte[5]:%x\r\n",AuxPtr->Data.Byte[5]);
		//xil_printf("0x82.Byte[1]:%x\r\n",AuxPtr->Data.Byte[1]);

	}
	else if(AuxPtr->Header.Byte[0] == AUX_AUDIO_INFOFRAME_TYPE){

		sample_size = AuxPtr->Data.Byte[2] & 0x03;
		sample_rate = (AuxPtr->Data.Byte[2]>>2) & 0x7;
		//xil_printf("0x84.Byte[1]:%x\r\n",AuxPtr->Data.Byte[1]);
	}
	if (IsPassThrough && AuxPtr->Header.Byte[0] !=
			AUX_GENERAL_CONTROL_PACKET_TYPE && AuxFifoStartFlag == TRUE) {
		memcpy(&(AuxFifo[AuxFifoEndIndex]), AuxPtr, sizeof(XHdmiC_Aux));

		if(AuxFifoEndIndex < (AUXFIFOSIZE - 1)) {
			AuxFifoEndIndex++;
		} else {
			AuxFifoEndIndex = 0;
		}

		if(AuxFifoCount >= AUXFIFOSIZE) {
			AuxFifoOvrFlowCnt++;
		}

		AuxFifoCount++;

	}
#endif

}

I moved MIG, VDMA,CDMA and BRAM controller to Microblaze D cache port, and RXAuxCallback function worked fine. Is this an issue?

I also found another problem, VPSS ip also affected RXAuxCallback function. If I added VPSS to my BD desgin, HDMI RX didn't receive any infoframes too.

Thanks

Sitting

[samk]

Hi @sitting,

When you say that there are no infoframes, do you mean that the interrupt never goes high? The handler is never called?

What version of the tools are you using?

Are you outputting your run to a console? Can you attach the output?

Regards,

Sam

[sitting]

Hi @samk,

I have tried vivado 2018.1 and 2018.2, there situations are the same.

There are two symptoms

1. The handler is called a few times

2. The receive data from aux_fifo is wrong.

When I change YCbCr colorspace, AUX still get RGB infoframe. ScanRange should be  overscan or underscan.

Normal log is as below:

Thanks

Sitting

[samk]

 @sitting,

To summarize.

The issue you see is that:

1. The handler is not called every time there is an infoframe. (Infoframes are lost)

2. When the handler is called, the data is not correct.

Moving forward.

Q1. Does this happen only for the 4K resolution or for all resolutions? 1080P?

Q2. Are the failures consistent or do they vary from test to test?t?

Q3. What are you using for a source?

-Sam

[sitting]

Hi @samk,

Q1. Does this happen only for the 4K resolution or for all resolutions? 1080P?

A1. For all resolutions.

Q2. Are the failures consistent or do they vary from test to test?t?

A2. The failures are consistent.

Q3. What are you using for a source?

A3. My source are laptops(DELL/HP/Lenovo).

Thanks

Sitting

[samk]

Hi @sitting,

I am not a processor expert, but I believe that ISRs can cause a program to jump from a callback. The best way to use the callback is to assist the ISR in moving the AUX data to the fifo. If the callback takes its time in moving the data, I believe that it is possible for the ISR to overwrite the memory space before the callback has moved the data into the fifo storage.

Moving forward, please remove all un-necessary logic from the callback function and put it in your main function. This should allow enough time for the AUX data to be saved into the fifo, where it can be serviced without racing a new AUX interrupt.

There is a limit to how many interrupts the processor can handle. If the processor is only servicing interrupts, it will not have time for the main function. This means that there is a limit to how many interrupt driven IP's the processor can handle, and this limit is a function of the frequency and the duration of interrupts. 

Please let me know the results of updating your callback function and or any additional information that may help with this issue. 

-Sam

[sitting]

Hi @samk,

Actually, I have generated new example design and only added MIG and BRAM controller ip.  Then I don't initialize MIG/bram controller in c code, and I just export example design and print the aux data at SDK. The result is still failed. You can refer my block design, there are no unnecessary function.

Sitting

[samk]

Hi Sitting,

Do you have a KC705? If you can reproduce this on one of our development boards, I can work on it from my side.

Regards,

Sam

[sitting]

Hi @samk,

Yes, I have a KC705, but I don't have HDMI FMC card. I think it can be reproduced on KC705 , because the Microblaze cache is the key point.

BR,

Sitting 

[samk]

Hi @sitting,

I do not believe this is a speed issue as previously mentioned we have tested the example design running the MicroBlaze down to 10MHz.

I was looking at an issue like this internally which turned out to be due to the source.

What are you using as a source?

Regards,

Sam

[sitting]

Hi @samk,

My source are Dell and HP laptops(Ex: Precision 7530/7520..7730/7720...etc). I enabled the dcache in the Microblaze and connected to MIG and BRAM, all of the infoframe can receive. But I  connected  MIG and BRAM to data port(AXI_DP), all of the infoframe cannot receive. It dosen't  make sense. Why MIG and BRAM cannot be connected to data port(AXI_DP)?

BR,

Sitting

[samk]

Hi @sitting,

I apologize for the delay. I was working on an issue like this internally, but it turned out to be a separate issue from yours. 

To summarize this topic:

1. Using a custom board with a (Kintex7-325T) your HDMI RX design works fine. However, when you add MIG, VDMA, CDMA, and BRAM to your block design, you no longer receive the infoframes. 
2. You then narrowed down the issue by only adding MIG and BRAM, which still shows the issue.
3. In the last email, you mention also enabling the dcache and connecting the MIG and BRAM which appears to be the issue.
4. We have narrowed down that this is not a MicroBlaze frequency issue and that you are not missing frames due to missing interrupts as well as verifying that there is not an issue with your driver calls.

Based on your last email this sounds like an AXI interface problem to the MicroBlaze. "Why can the MIG and BRAM not be connected to the AXI_DP" without causing the Infoframes to stop being received.

I am not familiar with the MicroBlaze; this may be better answered on the AXI-interface board. To help speed this up, please ask this question there as well and include your BD.

I will try and take a look at it from my side as well, but this does not sound like an issue with the IP or infoframes themselves being received.

Regards,

Sam

[sitting]

Hi @samk,

Thanks for your help. I will ask this question on the axi Infrastructure board.

BR,

Sitting

[samk]

Hi @sitting,

Was the axi infrastructure board able to help clear this up?

Is there still an issue? If so, I can see if there is anything I can do from my side.

Regards,

Sam

[sitting]

Hi @samk,

Sorry for the late reply. Finally, local FAE solved my problem. Thank you.

Sitting

[florentw]

Hi @sitting,

Thank you for updating the topic. Could you kindly share the solution with the community and then mark your reply as solution to close the topic?

Best Regards,

[sitting · Accepted solution]

Hi,

Local FAE find that all of the reference designs use cache port  of the Microblaze to access  memory element. To avoid the unknown problem, he recommend us to follow reference designs.

Thanks

Sitting