Closed mablinov closed 1 year ago
After having read back my own post, I think I'm confusing two separate issues: The critical warnings, and the actual bitstream generation failure.
The actual bitstream generation failure error is not referencing any PCIe signals. Infact it is referencing the following signals:
code[2:0]
clk
led
ok
It's worth mentioning that I have no clue what or where these signals even come from - They're not anywhere in the board design (that I can see), but if I click the hyperlinked code[2:0]
field in the error report, I get taken to a device view where I am offered to set a default signal type:
I just set these to LVCMOS33, save the settings back to the normal.xdc
constraints file when prompted to do so, and then re-run the implementation step followed by the bitstream generation step.
This got rid of one error: However, the "Port placement" error remained:
I was tempted to just randomly assign a location, but I'm going to try to figure out where these signals are even coming from. Looking at the top-level board design file, I can't visually see where or who is instantiating those signals by those names:
Ok, I (think) I've found the issue! I wasn't even building the Top.bd
design: I was building the CodeBlinker.v
example!
...
module CodeBlinker(
input clk,
input ok,
input [2:0] code,
output reg led
);
...
Vivado definitely had some kind of crazy bug: I clicked "Refresh hierarchy" in the "Sources" tab, and "Top_wrapper" magically became the "Top" design file:
Unfortunately I didn't have the foresight to take a screenshot before clicking "Refresh hierarchy", but if I expanded Top.bd
, I would have found CodeBlinker.v
nested under it and highlighted in bold, with Top_Wrapper.v
being grouped under an "External Modules" drop-down group.
I can confirm that Vivado detected the changes by asking about "details" of why its out of date:
Going to re-run everything and post results.
Ok, here's my full findings and resolution:
(TL;DR: Before doing anything, upgrade all IP blocks, and then you must "Refresh Hierarchy" for changes to take effect.)
When you first open the project in Vivado 2022.2, and you accept the offer to migrate the project, you will actually be staring at a semi-broken project. The top module, Top_wrapper.v
, will be coloured in red, because it doesn't exist:
Vivado evidently then falls-back by setting the next module as the top-level module, which in this case is the CodeBlinker.v
module.
If you right-click on the board design file to re-generate the top-level wrapper, you will get the following error:
The reason they're locked is because they are out of date, and Vivado insists that you open the "Report IP Status" tool to update them.
So go ahead and update the blocks, but after it finishes you must click "Refresh Hierarchy" by right-clicking on the "Design Sources" folder in the "Sources" tab. Then the top-level wrapper gets created, and Vivado finally figures out that that is what we're trying to build.
After that, do the full synth -> implementation -> bitstream flow, and it should work.
Hi all, I'm on Windows 10 using a freshly-installed Vivado 2022.2.
I'm failling on the bitstream generation step of the sample project, with the following error:
There's also a ton of warnings about
'set_property' expects atleast one object
, which look like this:In the picture above, I noticed that the "Ports" drop-down menu doesn't have anything relating to PCIe, other than
pci_reset
, andpcie_clkreq_I
- is that expected? Shouldn't I be seeing the PCIe lane signals in the top-level Ports listing?Another thing of note: I did get a dialogue asking me to migrate from Vivado 2022.1 (which I did), and when opening the
Top.bd
block design file, I got a prompt that 9 IP blocks needed updating. Updating them went through almost without a hitch apart from one warning:Anyway, I'm still fiddling with the project, but I'm posting here in the hopes that maybe someone can catch something that I can't see?