FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6669 Discussions

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

M_DK_FPGA
New Contributor I
5,821 Views

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.

 

Labels (1)
0 Kudos
1 Solution
Wincent_Altera
Employee
3,333 Views

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
 
Hope that able to help you to move a step forward, let me know if further clarification is needed.

Regards,
Wincent_Altera

 

View solution in original post

0 Kudos
38 Replies
RongYuan
Employee
3,608 Views

Hi,

For HDMI Sink, you might need to turn on Support FRL when AXIS_VVP Full is used.


7.2. HDMI Sink Parameters


Regards,

Rong


0 Kudos
M_DK_FPGA
New Contributor I
3,556 Views

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.

HDMI Intel FPGA IP User Guide (UG-HDMI) - Support for AXIS with FRL as 0 - Part.png

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.

HDMI PHY Intel FPGA IP User Guide (ug_hdmi_phy) - FRL and AXIS - Part.png

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

 

0 Kudos
M_DK_FPGA
New Contributor I
3,510 Views

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

 

0 Kudos
RongYuan
Employee
3,477 Views

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


0 Kudos
M_DK_FPGA
New Contributor I
3,257 Views

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

 

0 Kudos
RongYuan
Employee
3,213 Views

Hi,

These could be doc errors. Some limitations not mentioned clearly.


Regards,

Rong


0 Kudos
M_DK_FPGA
New Contributor I
3,183 Views

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

 

0 Kudos
RongYuan
Employee
3,152 Views

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


0 Kudos
M_DK_FPGA
New Contributor I
3,105 Views

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

 

0 Kudos
RongYuan
Employee
3,075 Views

Hi,

Your modification may need further check and investigation in order to meet your requirements. Please file an IPS for this.


Thanks,

Rong


0 Kudos
M_DK_FPGA
New Contributor I
3,033 Views

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

 

0 Kudos
RongYuan
Employee
3,010 Views

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


0 Kudos
M_DK_FPGA
New Contributor I
2,909 Views

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

 

0 Kudos
M_DK_FPGA
New Contributor I
2,831 Views

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

 

0 Kudos
RongYuan
Employee
2,538 Views

Hi,

You may contact Altera local representative to help the account issue.


Regards,

Rong


0 Kudos
M_DK_FPGA
New Contributor I
2,458 Views

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

 

 

0 Kudos
Wincent_Altera
Employee
2,385 Views

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 

"You must instantiate the HDMI core with Support FRL = 0 (for Intel® Arria® 10) or Support FRL = 1 (for Intel® Agilex™ F-tile) and Enable Active Video Protocol = AXIS-VVP Full to use Intel HDMI TX or RX PHY IP."

 

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

0 Kudos
M_DK_FPGA
New Contributor I
2,334 Views

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

 

0 Kudos
Wincent_Altera
Employee
2,318 Views

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

0 Kudos
Reply