How to make an FPGA project compatible with GIT?

[heel]

We have a project with a FlexRio board PXIe-5763 in a PXIe-1083 chassis attached to the PC via USB. We use LabVIEW21.0/64bit. For some obscure reason the project is broken after a round of checkin - checkout through GIT.

The story is:

1. The project includes a Xilinx IP (Fir Compiler). It works nicely.
2. I check _everything_ into GIT and check it out into a new workspace.
3. I use git's autocrlf = true (text file will checkin as LF and checkout as CRLF). I notice that the .vhd files in the xilinx folder gets converted from LF ending to CRLF endings. Also the time stamps are changed by this checkout.
4. Also I note that it is required to mark the bitfiles as binary so that they dont get eol converted LF->CRLF. This is done by having a file .gitattributes  in the root with a line *.lvbitx binary
5. Now when in the new workspace we try to use the vi with the Xilinx Fir Compiler IP the following errors appear:
   
   1. Build specification cannot find the bitfile
   2. The xilinx Ip cannot be regenerated
   3. The xilinx ip cannot be reconfigured. Well it can but - it has lost all configuration information and starts config from scratch so of very little use.

If I replace all the xilinx generated files under the folder where the vi with the xilinx ip is, with the set of files from the original workspace reconfiguration works as expected, picking up the config from the .xci file.

But project still cannot locate the bitfile! The bitfile _is_ still there - of course but LV has lost the link.

So bottom line is that because GIT alters the files in some subtle way, the LV project and xilinx compiler fails to find the files it need.

I have made test cases and it is systematic.

I really hope someone has a hint as to use a LabVIEW FPGA project together with GIT.

Here are some of the errors we see.

[Terry_ALE]

Set certain file extensions to be treated as a binary. This will prevent merging of files.

The paths is another story. We have a workflow that prevents this issue from happening. Because some things work off of absolute paths this has to be the same for all. We also provide screenshots of how the Xilinx IP is setup as a backup.

[heel]

Terry_ALE,

Thanks for the hints.

As I read your reply - I can only see the screenshots of how the Xilinx IP is backed up in the cited book. Right?

Indeed the issue of the missing bitfile is easy to reproduce: if you simply move the project to another folder the bitfile can no more be found by the project!

If you look in the .lvproj file there are both absolute and project relative paths for the original bitfile.

---

<Property Name="NI.LV.FPGA.LastCompiledBitfilePath" Type="Path">/an abs path/FPGA Bitfiles/nifpgagittest_FPGATarget_testofdecimation_tkVrhw7oy90.lvbitx</Property>

                                                                                <Property Name="NI.LV.FPGA.LastCompiledBitfilePathRelativeToProject" Type="Path">FPGA Bitfiles/nifpgagittest_FPGATarget_testofdecimation_tkVrhw7oy90.lvbitx</Property>

The absolute path is not updated to the new location upon loading of the project. The relative path is still valid, but it appears not to be used – or it would have found the bitfile properly.

Patching up the .lvproj with an editor to use the right absolute path makes LV see the bitfile:

Now one could think or expect that LabVIEW just uses the absolute path and not the relative path to locate the bitfile, but this is not the case either. To verify this make a copy of the project and place it next to the original project - this will have an absolute path to the original bitfile. But this does not work. Check signature returns

So it uses neither absolute nor relative path but some hybrid.

Wow – looks like there is a bit of polishing work left on this tool, the intentions are there but not yet properly implemented.

I would expect NI to publish a work-around or fix the problem. So user do not have to resort to this kind of reverse engineering.

I just now found this idea exchange touching on this problem: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-FPGA-Bitfile-signature-and-Xilinx-IPs-version-co... 

[heel · Accepted solution]

For the records - here is how I dealt with the problem of GIT changing LF to CRLF (EOF conversion) in the Xilinx folder files:

Add a text file with name

.gitattributes

to the project root. Start with a . and it may not have an extension. This may be tricky unless you set file explorer's options to show extensions.

The content is:

*.lvbitx binary
test[[:space:]]of[[:space:]]decimation/Decimation_X10/** binary

The first line makes sure the bitfiles are not being EOF converted and it should work as is for other users as well.

Now here comes the tricky part:

The second line is how to deal with the Xilinx IP folder EOF conversion. In this case the complication is 1) it is a sub folder 2) the path is likely to have spaces somewhere (if you work like I do).

So the given example is for a windows path with name

test of decimation\Decimation_X10\

So \ becomes / and space becomes [[:space:]] - now who would have guessed that.

You need one line for each Xilinx folder unless you group all into one common folder.

[Terry_ALE]

Xilinx IP configurations are stored as screenshots for our projects.  I know this is not ideal.  I find it to be a relatively small step and has marginal impact on FPGA projects where long and failed compiles represent the majority of the challenges.

One solution is to maintain a computer that is for building only.  Once all of the paths have been created they no longer need to be re-run.