- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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
Regards,
Wincent_Altera
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
For HDMI Sink, you might need to turn on Support FRL when AXIS_VVP Full is used.
Regards,
Rong
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Rong,
Thanks for your answer, and for looking into this.
As I understand the answer, then in order to use AXIS-VVP Full for video output protocol of an HDMI Sink (RX) core, it is required to use FRL = 1. The documentation for this is apparently in the description for parameter "Video in and out use the same clock"; a parameter that is unrelated to the parameter "Enable active video protocol" that assigns the video output protocol. As reference I have attached the PDF page where the figure in the answer is shown.
But doc "HDMI Intel FPGA IP User Guide" version 2023.12.04 page 17 "Table 7. HDMI Intel FPGA IP Resource Utilization" describes that AXIS is supported for FRL = 0, as shown in image below, and in attached PDF page.
Also, the HDMI PHY document "HDMI PHY Intel FPGA IP User Guide" version 2022.10.31 page 6 bottom, it requires FRL = 0 and AXIS enabled for our Arria 10 design, in order to use Intel HDMI TX or RX PHY IP, as shown in image below, and in attached PDF page.
So, if use of AXIS in the HDMI RX core requires that FRL = 1, the consequence is that HDMI RX PHY can't be used, according to the PHY documentation. Otherwise, if AXIS is not used in the HDMI RX core, then the HDMI RX PHY can't be used either. For Arria 10, it means that HDMI RX PHY can't be used in any case.
As an additional comment, then using FRL = 1 in the HDMI RX core will make the HDMI RX core more than 5 times larger, in a HDMI 2.0 design that does not require FRL.
The contradicting documentation parts referenced above, and the out of place note in the parameter description, makes me uncertain about what is actually supported in the HDMI RX core.
Question: Can you please revisit this question, based on the above information, and clarify what is actually supported, and what part of the documentation that is incorrect.
Regards,
M_DK_FPGA
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Your Intel Community Team,
After my above reply with question, I got a mail asking "Did it solve your problem?".
Based on this, I would like to point out that, that the problem is still open based on the contradictions in the documentation and tool, as I pointed out in the reply, where I also have an open question.
Any attention to this problem is greatly appreciated.
Regards,
M_DK_FPGA
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi M_DK_FPGA,
After my above reply with question, I got a mail asking "Did it solve your problem?".
-Thanks for the feedback. I'm still checking answers for your questions. Not sure why system sent you that.
Please allow some more time to confirm this issue.
Regards,
Rong
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Rong,
Hope you and others at Intel are well into the new year
Its been a while since the last update on this case.
Can you please provide a status, just to assume me that the case is still active ?
Regards,
M_DK_FPGA
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
These could be doc errors. Some limitations not mentioned clearly.
Regards,
Rong
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Rong,
Thanks for getting back to this question.
On the December 18th 2024 I made a pretty elaborate description for the possible contradictions in the documentation, and asked:
Question: Can you please revisit this question, based on the above information, and clarify what is actually supported, and what part of the documentation that is incorrect.
On the December 22nd 2024 you reassuringly wrote "Please allow some more time to confirm this issue.".
The answer today as "These could be doc errors. Some limitations not mentioned clearly." does not clarify what is actually supported, and does not describe what part of the documentation that is incorrect.
Can you please revisit my description and question from December 18th 2024, so we can determine how the HDMI Intel FPGA IP can be used, or let me know who to contact to get this question resolved.
Thanks in advance.
Regards
M_DK_FPGA
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
If you really want AXIS-VVP example, you can generate it from HDMI PHY IP. The example enables AXIS-VVP by default.
1. HDMI PHY Design Example Quick Start Guide for Intel® Arria® 10...
Regards,
Rong
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Rong,
Thanks for the suggested workaround.
I tried it by generating the example design for HDMI loop from Rx to Tx.
From this design I took the HDMI Rx core named "intel_hdmi_rx_core_0" and copied the directory and ip file to my own project.
The core is configured with enabled "Support Auxiliary" and enabled "Support Deep Color", thus 48 bit pixel data, where my design from 12-15-2024 only has 24 bit pixel data.
So after changing my original design from 24 to 48 bit pixel data, and using the HDMI Rx core named "intel_hdmi_rx_core_0", Quartus could successfully run the full build.
To modify the core to match our required configuration, I disabled "Support Auxiliary" and disable "Support Deep Color", and regenerated the core.
Then I edited the design to use 24 bit pixel data, to match the disabled "Support Deep Color", and ran Quartus build.
This resulted in the Quartus error in "Analysis & Synthesis":
Error(13224): Verilog HDL or VHDL error at intel_cv2axi_remap.sv(154): index ** is out of range [**:**] for '**'
Error: Failed to elaborate design:
Error: Flow failed: Errors generated during elaboration
The file intel_cv2axi_remap.sv is part of the HDMI Rx core and contains encrypted code, so I can't determine the reason for the error.
The suggested workaround with use of the example design, is thus only applicable if the HDMI Rx core can be used without core rebuild, making the workaround of limited use. Also, I expect the core will also break if rebuild is required at upgrade to a future Quartus Pro version, thus effectively inhibiting such upgrade.
So, it appears there is a problem with the HDMI Rx core build system, and I suppose that problem is also the reason for suggesting the workaround using the example design, instead of just advising use of the HDMI Rx core build system.
Question: Do you have any suggestion for fixing the above problem in file intel_cv2axi_remap.sv, or any other suggestions for how to generate the HDMI Rx core in the required configuration ?
Thanks in advance.
Regards
M_DK_FPGA
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Your modification may need further check and investigation in order to meet your requirements. Please file an IPS for this.
Thanks,
Rong
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Rong,
Thanks for replying so quickly.
I have attached the Quartus project with the failing core in the attached file "proj_24_3_0_212_hdmi_rx_core_modified.qar" for the problem I reported yesterday.
Please let me know and elaborate if you expect me to file an "IPS", as you requested.
Though it maybe interesting to debug the problem reported yesterday, based on the attached file "proj_24_3_0_212_hdmi_rx_core_modified.qar", I fear that we are getting out on a deroute here, and not really addressing the original question posted for more than a month ago.
Also, it appears that I get few specific answers or useful suggestions, even based on the quite elaborate replies and specific questions I post.
So may I kindly suggest, that you backtrack to the original report and maybe reply at 12-18-2024 in this support request, and see if you or others at Intel can address the original problem, since it appears as there is a problem with the HDMI Rx core generation tool.
Otherwise, please let me know how if you have other suggestion for addressing this support question more effectively.
Thanks in advance.
Regards
M_DK_FPGA
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Please follow below guide to create an account and send your question there.
https://www.intel.com/content/www/us/en/support/articles/000057045/ethernet-products.html
Regards,
Rong
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Rong,
Thanks for the link.
I have applied, and will let you know when application is confirmed, and I have then posted the question.
Regards
M_DK_FPGA
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Rong,
My application for IPS was declined based on the same account as used here.
Please let me know if you have any suggestions or resolution regarding my IPS application.
Also please address this support can here, if possible, since I see no other possibility for now.
Thanks in advance.
Regards
M_DK_FPGA
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
You may contact Altera local representative to help the account issue.
Regards,
Rong
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Rong,
Thanks for getting back to this question, though a reply time of 25 days is quite long.
We have tried to get support through our local representative, but we are not eligible for an IPS account.
However, the question about an IPS account should not derail the support effort here, unless community support is not able to address the question about whey the HDMI Intel FPGA IP as Receive with AXIS fails in Analysis & Synthesis of Quartus 24.3 Pro.
If community support is unable to address the support question, then please close the question.
Regards
M_DK_FPGA
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @M_DK_FPGA ,
I tried it by generating the example design for HDMI loop from Rx to Tx.
From this design I took the HDMI Rx core named "intel_hdmi_rx_core_0" and copied the directory and ip file to my own project.
>> I assume you try to generate the design example as suggested by Rong in the past reply right ?
>> Do you try to run compilation without any modification ? is it work ?
On the December 18th 2024 I made a pretty elaborate description for the possible contradictions in the documentation, and asked:
Question: Can you please revisit this question, based on the above information, and clarify what is actually supported, and what part of the documentation that is incorrect.
>> May I know which device that currently you are using ?
>> mentioned from this link: https://www.intel.com/content/www/us/en/docs/programmable/732147/22-3-1-0-1/hdmi-phy-overview.html
Error(13224): Verilog HDL or VHDL error at intel_cv2axi_remap.sv(154): index ** is out of range [**:**] for '**
>> just to check with you, if you remain 48 bit pixel data do you still able to see the same error ?
Meanwhile, I will check the .qar file attach by you, please allow me to have sometime on that.
Regards,
Wincent_Altera
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Wincent_Altera,
Thanks for looking into this case.
Initially I would like to note, that it may be worth starting with my initial issue, where I experience that the IP core build directly from Quartus does not synthesize. The project is attached with the original posting from 12-15-2024. I think it is very surprising that the IP build right from Quartus does not synthesize, and if my experience is correct, then it may point to a problem in Quartus.
Below I have put feedback/answers to your 3 questions.
>> I assume you try to generate the design example as suggested by Rong in the past reply right ?
>> Do you try to run compilation without any modification ? is it work ?
The design was compiled unmodified, except for changes at the interface that was made 48 bit instead of 24 bit, in order to match enable of "Support Deep Color".
>> May I know which device that currently you are using ?
Arria 10 GX (10AX032H3F34E2SG).
>> just to check with you, if you remain 48 bit pixel data do you still able to see the same error ?
After disable of "Support Deep Color", then the interface is only 24 bit, so in order to match the width I changed to 24 bits. Using 48 bit externally on a 24 bit interface does not is a mismatch of interface width.
With respect to the reported error, then that is in internal Intel IP design, that is not directly connected to the external interface where I change the interface width. The external interface width does therefore not affect the internal IP design, thus nor the reason for the error.
The failing design was attached in my reply at 01-16-2025, so you are able to inspect and try it from there.
Regards
M_DK_FPGA
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @M_DK_FPGA ,
Thanks for your clear clarification, please allow me to have 1-3 days to replicate your issue on my sides.
Will update you once I have any progress.
Regards,
Wincent_Altera

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page