HDMI Intel FPGA IP as Receive with AXIS fails in Analysis & Synthesis of Quartus 24.3 Pro

[M_DK_FPGA]

Hi support,

When creating a design with "HDMI Intel FPGA IP" having significant values as:
- Direction: Receiver
- Enable Active Video Protocol: AXIS-VVP Full
- Support FRL: Untick (disabled)

Then Quartus 24.3 Pro Build 212 (newest) fails in Analysis & Synthesis with the errors:

Error(13224): Verilog HDL or VHDL error at hdmi_rx_core_altera_hdmi_1975_ozylggi.v(771): index 2 is out of range [1:0] for 'cv_vid_de'
Error: Failed to elaborate design:
Error: Flow failed: Errors generated during elaboration
Error: Quartus Prime Synthesis was unsuccessful. 3 errors, 0 warnings

Archived project is attached.

Question: Is there any known fix or workaround for this problem?

Regards
M_DK_FPGA

PS. It appears that an internal non-designer assigned value PIXELS_PER_CLOCK is assigned to 8, as for FRL enabled, thus causing an internal loop to go out of range.

[Wincent_Altera]

Hi @M_DK_FPGA ,

Can I get your help to provide RAM file .hex to me ?

Regards.
Wincent_Altera

[Wincent_Altera]

Hi @M_DK_FPGA ,

Another issue that I found based on your .qar file is your pin assignment is totally empty.
it could be lead to the error you are seeing.

You may refer to https://www.intel.com/content/www/us/en/docs/programmable/683814/current/intel-arria-10-gx-gt-and-sx-device-family.html

https://www.intel.com/content/www/us/en/support/programmable/support-resources/devices/lit-dp.html

To assign it, I will try to generate a design based on A10 GX devkit with AXIS-VVP full as per your reference once I get your .hex file.

Regards,

Wincent_Altera

[M_DK_FPGA]

Hi Wincent_Altera,

The .hex file used for EDID I used was just the one provided in the example, since the problem I see with the IP core does not depend on EDID.  However, I have attached the file anyway (renamed to .txt to allow attach).

Regarding the lack of pin placement, then I think it does not effect the problems reported in the encrypted IP cores and the problem with mismatch of vector size in the Verilog IP core.  Pin placement was not used in any of the compiles designs, and in the example with correct vector size in the Verilog IP core, the Quartus did automatic pin placement (also for transceivers) as it typically does quite effectively.

Regards
M_DK_FPGA

[Wincent_Altera]

Hi @M_DK_FPGA ,

I was able to generate and perform 100 % compilation by referring your .ip setup and EDID.hex file using AXIS-VVP Full in Arria 10 GX devkit. I attach the .qar here.

Can you please try this, you may copy the .qsf file into your own design.

Regards,
Wincent_Altera

[M_DK_FPGA]

Hi Wincent_Altera,

Thanks for the project file .qar.

I unpacked the files, and looked at the HDMI IP Rx and Tx cores.

Searching for VIDEO_PROTOCOL shows that the setting is "none" for clocked video, and not "vvp_full" for "AXIS-VVP Full"; relevant files are:

• ^/hdmi_0_example_design/rtl/hdmi_rx/hdmi_rx/hdmi_rx.html and .xml
• ^/hdmi_0_example_design/rtl/hdmi_tx/hdmi_tx/hdmi_tx.html and .xml

The design also shows it, since the HDMI IP Rx and Tx PHYs are not used as would require AXIS-VVP Full, but the transceivers for HDMI are made using GXB blocks directly.

May I suggest that you take a look at the original question from December 15 2024, and try to generate the HDMI Core with:
- Direction: Receiver
- Enable Active Video Protocol: AXIS-VVP Full
- Support FRL: Untick (disabled)

The generated design is also attached as a file .qar with the original question.

Simply by code inspection of the generated hdmi_rx_core_altera_hdmi_1975_ozylggi.v file, it is possible to see that there is problem with the design.

The module hdmi_rx_core_altera_hdmi_1975_ozylggi is used in file hdmi_rx_core.vhd at lines 192 forward through a component with configuration as:

...
hdmi_0 : component hdmi_rx_core_altera_hdmi_1975_ozylggi_cmp
    generic map (
        FAMILY => "Arria 10",
        SYMBOLS_PER_CLOCK => 2,
        PIXELS_PER_CLOCK => 8,
...

The module in file hdmi_rx_core_altera_hdmi_1975_ozylggi.v has code:

...
wire [SYMBOLS_PER_CLOCK - 1 : 0] cv_vid_de;
...
for (p=0; p<PIXELS_PER_CLOCK; p=p+1) begin: vid_data_p
...
    if(cv_vid_de[p] && (vid_valid == 1'b1)) begin
...

So loop variable p is in range 0 to PIXELS_PER_CLOCK - 1 = 8 - 1 = 7, but wire cv_vid_de is only defined with range 0 to SYMBOLS_PER_CLOCK - 1 = 2 - 1 = 1.

During synthesis, Quartus tries to access p[2], that is out of range, thus giving the error meassage:
Error(13224): Verilog HDL or VHDL error at hdmi_rx_core_altera_hdmi_1975_ozylggi.v(771): index 2 is out of range [1:0] for 'cv_vid_de'

This problem can be confirmed by code inspection, thus without any pin placement or other synthesis.

Have you tried to recreate the original problem that I reported, showing the above problem in the code ?

Regards
M_DK_FPGA

[M_DK_FPGA]

Hi Wincent_Altera,

Thanks for the project file .qar.

I unpacked the files, and looked at the HDMI IP Rx and Tx cores.

Searching for VIDEO_PROTOCOL shows that the setting is "none" for clocked video, and not "vvp_full" for "AXIS-VVP Full"; relevant files are:

• ^/hdmi_0_example_design/rtl/hdmi_rx/hdmi_rx/hdmi_rx.html and .xml
• ^/hdmi_0_example_design/rtl/hdmi_tx/hdmi_tx/hdmi_tx.html and .xml

The design also shows it, since the HDMI IP Rx and Tx PHYs are not used as would require AXIS-VVP Full, but the transceivers for HDMI are made using GXB blocks directly.

May I suggest that you take a look at the original question from December 15 2024, and try to generate the HDMI Core with:
- Direction: Receiver
- Enable Active Video Protocol: AXIS-VVP Full
- Support FRL: Untick (disabled)

The generated design is also attached as a file .qar with the original question.

Simply by code inspection of the generated hdmi_rx_core_altera_hdmi_1975_ozylggi.v file, it is possible to see that there is problem with the design.

The module hdmi_rx_core_altera_hdmi_1975_ozylggi is used in file hdmi_rx_core.vhd at lines 192 forward through a component with configuration as:

...
hdmi_0 : component hdmi_rx_core_altera_hdmi_1975_ozylggi_cmp
    generic map (
        FAMILY => "Arria 10",
        SYMBOLS_PER_CLOCK => 2,
        PIXELS_PER_CLOCK => 8,
...

The module in file hdmi_rx_core_altera_hdmi_1975_ozylggi.v has code:

...
wire [SYMBOLS_PER_CLOCK - 1 : 0] cv_vid_de;
...
for (p=0; p<PIXELS_PER_CLOCK; p=p+1) begin: vid_data_p
...
    if(cv_vid_de[p] && (vid_valid == 1'b1)) begin
...

So loop variable p is in range 0 to PIXELS_PER_CLOCK - 1 = 8 - 1 = 7, but wire cv_vid_de is only defined with range 0 to SYMBOLS_PER_CLOCK - 1 = 2 - 1 = 1.

During synthesis, Quartus tries to access p[2], that is out of range, thus giving the error meassage:
Error(13224): Verilog HDL or VHDL error at hdmi_rx_core_altera_hdmi_1975_ozylggi.v(771): index 2 is out of range [1:0] for 'cv_vid_de'

This problem can be confirmed by code inspection, thus without any pin placement or other synthesis.

Have you tried to recreate the original problem that I reported, showing the above problem in the code ?

Regards
M_DK_FPGA

[Wincent_Altera]

Hi @M_DK_FPGA ,

I follow your setup , and the compilation passing 100 % and I did not observed any synthesis error...
Attach the .qar file in the attachment.

If this still did not address your question, I would suggest to have a Teams Call meeting.
It would help me better understand the challenge that you are seeing now, My time zone will be GMT +8.
Let me know your convenience time and email address, will sent the meeting invitation upon your agreement.

Regards,

Wincent_Altera

[M_DK_FPGA]

Hi Wincent_Altera,

Thanks for the project file .qar.

The HDMI Rx IP shows that the Video Protocol is None, as you can seen in the attached image.

May I suggest that you try to unpack the qar file you attached, and check the actual IP setting.

You can also just search for VIDEO_PROTOCOL in the files, where you in file  ^/devkit2/hdmi_0_example_design/rtl/hdmi_rx/hdmi_rx/hdmi_rx.xml will find <parameter name="VIDEO_PROTOCOL" value="none" />.

Please also take a look at the originally generated code, where I in my previous answer described the mismatch between config parameters PIXELS_PER_CLOCK and SYMBOLS_PER_CLOCK.

Also you could try just to run the synthesis of the originally attached qar file, which will shown the problem.

That should be straight forward to do.

Thanks for the offer for a Teams Call

For now I think we have enough technical issues to resolve, so until the above is addressed I would not think a Teams Call is required.

Regards
M_DK_FPGA

[Wincent_Altera]

Hi,

Using HDMI PHY Intel FPGA IP Design example, it enable the AXIS-VVP-FULL by default.
As per mentioned by Rong Yuan in the past reply.

Next will try to disable AUX and deep color and see if I am able to replicate your issue or not.

Regards,

Wincent_Altera

[Wincent_Altera]

Hi @M_DK_FPGA ,

Sorry forget to update you, try to disable AUX and deep color the AXIS-VVP full by default disable again in new generated HDL.
I might need more time to check on this (around 7-14 days). 

Will update you back ASAP.

Regards,
Wincent_Altera

[Wincent_Altera]

Hi @M_DK_FPGA ,

we need more time to enable this feature, meanwhile do you able to file an IPS case ?
with IPS cases, it can help us to raise the ticket level into higher level.

From the previous reply, seen that you having problem to get that done.
My suggestion is to reach out to the distributor FAE where you got the product from.
They will help to file on behave, just put this Forum link in the description, I will be there to support you.

Regards,
Wincent_Altera

[M_DK_FPGA]

Hi Wincent_Altera,

Thanks for your feedback, and suggestion about raising an IPS case.

As described previously, then Intel rejected my request for an IPS account, so to make an IPS case I have to go through our FAE, who have offered the possibility through some shared IPS account.  However, I am reluctant to draw on the good will of our FAE, just to ask the same question and start yet another lengthy support case in another forum.

During this support case I have provided substantial material that indicates a problem in the HDMI core IP, starting with the initial posting more than 11 weeks ago, but there is no indication that support ever attempted to reproduce these problem, through it would only require synthesis of the uploaded archives, to acknowledge the problem. 

Instead I have been offered workarounds, that I dutifully have attempted, and provided replies in a day or two, but when I have pointed out problems with the workaround, my substantial issues and questions have not been addressed.

So as a small company we have been forced to search for another path through with the HDMI core IP, since relaying on support bears the risk of jeopardizing the project.

Regards
M_DK_FPGA

[Wincent_Altera]

Hi @M_DK_FPGA ,

I was able to replicate your issue as mentioned in 2 March 2025 reply.

try to disable AUX and deep color the AXIS-VVP full by default disable again in new generated HDL.
When remove the deep color at the IP core in Arria 10 in example design generation , we seeing the same error as yours.

I understand your frustration, Please do believe that I am trying my best to ensure your success. 
Also, i do understand your concern, I am working with our design team to fix this issue.  But the investigation may take longer time.

You can ignore the request to having IPS on this.
I will raise the support level in to higher level, hope we can get some investigation result back soon.
Please accept my apology if for the inconvenience cause to you.

Regards,
Wincent_Altera

[M_DK_FPGA]

Hi Wincent_Altera,

Thanks for getting back to this so quickly, and it is reassuring that you see the same tool behaviour.

It sounds good you will elevate the support case, if you concurs that there may be a problem in the HDMI core IP.

I am looking forward to any further updates.

Regards
M_DK_FPGA

[Wincent_Altera · Accepted solution]

Hi @M_DK_FPGA ,

I understand your reason to turn off the "support Aux" and "deep colour" with reason to support your custom  24 bit pixel data.
However , turning OFF support Aux and deep colour will make the output in-stable (blank most of the time).
Also, This will only save minor logic utilization. That why we make those two as default to suit most of the use cases.

Currently AXI Bridge is setting to 16BPS  (16x3 48bits).
If fewer bits are requires, you just need to pad the LSB without disable the AUX and Deep Colour.
Detail about the implementation you may refer to

• HDMI user guide 5.1.19. AXI4-Stream to Clocked Video Converter (AXI2CV) 
• Intel AXI Streaming Video Protocol Specification:  2.2.10. Packing RGB444 onto an RGB888 Interface 

Hope that able to help you to move a step forward, let me know if further clarification is needed.

Regards,
Wincent_Altera

[M_DK_FPGA]

Hi Wincent_Altera,

OK, thanks for the suggested workaround, and I see the point that the AUX and Deep Color features can be disabled by just tying the interface to constants, whereby synthesis will remove the idle design part. 

However, I still assume that disabling the features in the interface should not break synthesis, nor make output in-stable (blank most of the time), which may be relevant only to other users of the core, now that you have pointed out a possible workaround.

Please feel free to close the case if you think it is covered.

Regards
M_DK_FPGA

[Wincent_Altera]

Hi @M_DK_FPGA ,

First and foremost, I would sincerely apologies that the workaround take unexpected delivery time.
Please believe that, I am trying my best to ensure you and all of my client success.

Feel free to try out those workaround, if you facing any issue or anything need to be further clarified, please post a new forum.
If you need specific my support, you may point out my name "Wincent" in the description, It will be pleasure there to support you again. Hope this help to accelerate your current project progress.

Regards,
Wincent_Altera

[M_DK_FPGA]

Hi Wincent_Altera,

Thank you for your thoughtful response and your generous offer of future support—it is truly appreciated.

I will accept the suggested workaround as the solution and will post a new question in this forum if any further issues arise.

Best regards,
M_DK_FPGA