Bug: Import of QDB file partition fails in Quartus Pro versions that use DNI

Intel support folks - Response, please?

Thanks,

-Roee

Roee,

I am looking into this. Will back to you with update

Roee,

I was on holiday, ill continue to take a look at the design and update you any finding

I am able to see the issue as mentioned with and without dni.

I am trying to see if we are able to disable dni for good here.

Hi Roee,

Update :

Yes this is a bug in the DNI flow.

This only happens in VHDL when there is a component declaration for the precompiled module, but no actual (empty) definition for it. In classic mode it was enough to have the component definition, but in DNI mode we error out if there is no actual empty stub file.

As a workaround you can add an actual definition to the project, this definition may be empty.

For example I added a vhdl file with just this to the step 2 project for the attached design, and this makes it work:

library ieee;

use ieee.std_logic_1164.all;

entity example_core is

port (

clk : in std_logic;

i0 : in std_logic;

i1 : in std_logic;

o : out std_logic);

end example_core;

architecture rtl of example_core is

begin

end rtl;

I have requested patch for both version 23.3/23.4 and will let you know if there is any update on this.

May I know if you are able to work on the workaround provided?

Do you you still need patch?

Hi Roee,

As discussed internally with developer, the workaround should be reliable and since there is plan in next Quartus release, the patch wont be needed. Let me know.

Thank you, @SyafieqS .

I'll test the workaround and get back to you on that later today.

Do you have an approximate release date for Quartus Pro 24.1?

Thanks,

-Roee

Roee,

I dont have the specific date, but as per 23.1, 24.1 Pro release should be around end of Q1 or few weeks early approximately.

Hi @SyafieqS ,

I've tested your workaround. I've found that the workaround lets Quartus get through that part of the flow without erroring out, but then there are still problems further downstream.

First sign of trouble is a warning that Quartus now generates about the undriven output of the stub:

Warning (21610): Output port "o" in instance "example_core_i" of entity "example_core" does not have a driver. Connecting to the default value "gnd".

It could be innocuous if this warning was generated before the QDB import, but this warning is generated at a point in the flow after the QDB has already been imported, when the stub should have already been replaced in the design by the imported QDB. So seeing this warning here seems to indicate that the stub is still lingering in the design in some form, and has not been completely replaced by the imported QDB.

There's also further evidence of stub vs. QDB problems even further down the flow, beyond what was the end point of the original trivial design example I provided.

I'm providing a new expanded version of my original example (see zip file attached). This version incorporates your workaround, and also expands on step 2 to make it a 3-layer hierarchy and export a QDB partition of the middle layer above the imported core.

In this example, you can see not only the warning (21610) that I mentioned above, but also additional critical warnings (24035) produced during the export of the mid-layer QDB partition that indicate problems in the database at the level of the imported QDB / stub:

Critical Warning (24035): The exported partition, "example_wrapper_level1_partition", has 2 ports being driven by the same source, "clk", outside it. Up to 10 such ports are listed below. Multiple ports sharing a source external to the partition may lead to routing conflicts in compiles that reuse this partition in another context.
Info (24036): example_wrapper_level1_i|example_core_i|clk.
Info (24036): example_wrapper_level1_i|clk.
Critical Warning (24035): The exported partition, "example_wrapper_level1_partition", has 2 ports being driven by the same source, "i1", outside it. Up to 10 such ports are listed below. Multiple ports sharing a source external to the partition may lead to routing conflicts in compiles that reuse this partition in another context.
Info (24036): example_wrapper_level1_i|example_core_i|i1.
Info (24036): example_wrapper_level1_i|i1.
Critical Warning (24035): The exported partition, "example_wrapper_level1_partition", has 2 ports being driven by the same source, "i0", outside it. Up to 10 such ports are listed below. Multiple ports sharing a source external to the partition may lead to routing conflicts in compiles that reuse this partition in another context.
Info (24036): example_wrapper_level1_i|example_core_i|i0.
Info (24036): example_wrapper_level1_i|i0.

And as before, all of the above problems only appear with DNI. In non-DNI versions, this all runs cleanly with no errors or warnings.

Can you please take a look? Firstly, can you confirm that I've implemented your workaround as you intended, or am I doing something wrong? And then, otherwise, does this suggest that the scope of the problems with QDB import in DNI may actually be bigger than we first thought?

Let me know.

Thanks,
-Roee