Forum Discussion
Bug: Import of QDB file partition fails in Quartus Pro versions that use DNI
- 2 years ago
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
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