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

[roeekalinsky]

Quartus Pro versions that use DNI fail when trying to import a partition from a QDB file.

The error observed, which doesn't occur with non-DNI versions, is as follows:

  Error (20045): Can't find the stub file for /"example_core/". File: example_wrapper.vhd Line: 21

I'm providing a simple design example that demonstrates the issue (zip file attached).

Build the example using any DNI version of Quartus Pro to see it fail, and build it using any non-DNI version of Quartus Pro to see it not fail.

See the README.txt in the zip file for further detail.

Thanks,

-Roee

[roeekalinsky]

Intel support folks -  Response, please?

Thanks,

-Roee

[SyafieqS]

Roee,

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

[roeekalinsky]

Ok, thank you, @SyafieqS .

-Roee

[SyafieqS]

Roee,

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

[SyafieqS]

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.

[SyafieqS]

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.

[SyafieqS]

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

Do you you still need patch?

[SyafieqS]

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.

[roeekalinsky]

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

[SyafieqS]

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.

[roeekalinsky]

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

[SyafieqS]

Roee,

Noted and thanks for the feedback.

I am getting this issue to developer.

Seem the scope is bigger that I expected.

Anyway please stay tune and let me know if there is any more valuable feedback regarding dni.

[SyafieqS]

Hi Roee,

Update from developer:

I'm seeing these critical warnings in both DNI and classic mode, so they suggest actual potential issues with the PR partitions:

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.

This one only happens in DNI mode:

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

This warning should not be produced, This will be removed. It is otherwise innocent.

I compared the atom netlists after synthesis between DNI and classic and they are the same. I checked both 23.3 and 23.4. 

Roee this should work fine. We do have extensive tests for partial reconfig in DNI mode, we were only missing the case where the design is VHDL and there is not stub.

[roeekalinsky]

Hi @SyafieqS ,

Re: "I'm seeing these critical warnings in both DNI and classic mode":

In what Quartus versions did you observe this?

I'm not seeing these warnings in Quartus 23.2 and earlier. I only see them in 23.3 and 23.4.

So is there still a classic mode in 23.3 and 23.4?

And are these warnings then just a separate bug that was introduced in 23.3 and 23.4 that's independent of DNI?

I'm just trying to understand the exact scope of each of these seemingly related issues.

And will all these issues that we've uncovered be fixed in 24.1? Removing the need for the stub, as well as removing the bogus warnings?

Thanks,
-Roee

[SyafieqS]

Hi Roee,

These critical warnings are newly introduced design rules for bottom-up compile. They are new in 23.3/23.4

These are intentionally created and are supposed to help the customer in preventing issues with their design. 

Yes all these issue discovered will be fixed in 24.1 and the plan has been submitted.

[roeekalinsky]

Thank you, @SyafieqS .

-Roee

[roeekalinsky · Accepted solution]

Hi @SyafieqS .

Testing with the newly released Quartus Pro 24.1, I can confirm that it fixes the original issue of this thread.  Error (20045) no longer appears, and a stub file is no longer required.

As for the other two incidentally related issues that came up in this thread:

I can confirm that the erroneously produced Warning (21610) has also been fixed.  With 24.1 this warning no longer appears.

However, the erroneously produced Critical Warning (24035) has not been fixed.  These still appear with 24.1.  And this is apparently a separate issue that's independent of the stub file issues.  With 24.1 it can be observed that these warnings are generated whether or not a stub file is used.

As the original issue of this thread has been addressed in 24.1, let's close out this thread at this point.  I will start a new thread to deal with the Critical Warning (24035) issue.

Thanks,

-Roee

[roeekalinsky]

Hi @SyafieqS ,

I've started a new thread dealing specifically with the Critical Warning (24035) issue, which remains unresolved at this time.  The thread is found here:

https://community.intel.com/t5/Intel-Quartus-Prime-Software/Bug-report-Quartus-Pro-24-1-erroneously-produces-Critical/m-p/1586508/highlight/true#M82428

Please rejoin/continue that discussion there and help resolve that issue.

Thanks,

-Roee