07-17-2018 06:18 AM - edited 07-17-2018 06:19 AM
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
11-18-2018 10:36 PM
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
07-19-2018 10:16 AM
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
07-20-2018 03:34 AM
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
07-20-2018 02:46 PM
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
07-23-2018 03:09 AM
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
07-24-2018 07:25 AM
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
07-25-2018 01:06 AM
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
07-31-2018 08:16 AM
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
07-31-2018 06:06 PM - edited 07-31-2018 07:06 PM
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
08-15-2018 08:02 AM
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
08-15-2018 07:13 PM
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
08-28-2018 03:13 PM
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
08-28-2018 06:41 PM
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
09-06-2018 12:30 PM
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:
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
09-13-2018 05:36 AM
Hi @samk,
Thanks for your help. I will ask this question on the axi Infrastructure board.
BR,
Sitting
10-15-2018 09:24 AM
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
11-09-2018 07:01 AM
11-09-2018 07:22 AM
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,
11-18-2018 10:36 PM
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