RHSResearchLLC / NiteFury-and-LiteFury

Public repository for Litefury & Nitefury
271 stars 71 forks source link

[Solved] Sample project won't build: PCIe ports missing? #22

Closed mablinov closed 1 year ago

mablinov commented 1 year ago

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:

bitstream-gen-failure

There's also a ton of warnings about 'set_property' expects atleast one object, which look like this:

post-synth-warnings

In the picture above, I noticed that the "Ports" drop-down menu doesn't have anything relating to PCIe, other than pci_reset, and pcie_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:

block-ip-update-critical-message

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?

mablinov commented 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:

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:

code-pins-unspecified

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:

port-placement-error

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:

top-level-board-design

mablinov commented 1 year ago

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:

post-refresh-hierarchy

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:

synth-and-impl-out-of-date

Going to re-run everything and post results.

mablinov commented 1 year ago

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:

unable-to-open-top-wrapper

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:

block-design-contains-locked-ip

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.