Project file to bitfile corruption

[bmccarney]

I have a "good" bitfile that when deployed to the target allows us to meet our system requirements in position error and settling time.  Unfortunately there are other known issues with this build that need to be fixed before we can hand over the system.  The problem I have run into however is that every attempt to rebuild this project, even without any changes made to the environment or VI's, results in a build that has drastically higher position error.  At this point I also question whether the project that was used to generate the original "good" build is actually correct, or if a different project had been used; several duplicate projects were created at around the same date as the "good" build so it is hard to know.  In any event attempts to rebuild any of those files without changes still does not get us the original performance.  

Backups were created of the drive that housed these files, but unfortunately these were manually done and did not occur near to the time of the "good" build (6 months prior, 6 months after).  To my knowledge there have been no updates to LabView that were installed, in part because we had been having so many issues that I'm sure they didn't want to create other unknowns during development.  So we are still running LabView 2014 (version 14.0f1), and are building on NI 9155 chassis, I can list the modules installed as well if that would be of value.

Is there any way that I can determine the project file from the bitfile?  Are there environmental things that could have changed, and if so how can I check?  Any other thoughts?  We're really in a jam on this one, and I'd appreciate any ideas and assistance.

Ben

[yea_likethecity]

BMC,

The bitfile is constructed as an XML file so you can open it in an XML viewer or a web browser to see things like the VI it's associated with and the device it was built for, but from what I've seen you cannot see the project it was built in. As for changes between bitfiles, you could open them in a text compare program to see what's different but if the only differences appear in the bitstream portion it may not tell you very much. I'm not sure I understand your situation, it sounds like you have one bitfile that achieves good performance, but recompiling that bitfile even with seemingly no changes results in worse performance. It also seems like you're not sure which project the good bitfile is associated with and need some way to figure it out. Is that right?

[bmccarney]

Hi Austin,

In essence, that's it.  Every attempt to recompile the project (any of them that could have been originally used to create the file) result in worse performance.  If we have located the original file and did attempt a rebuild without any VI or setting changes, would there be any difference in the bitfiles (or specifically the bitstream)?  

Otherwise I'll check out the file in XML and see if I can get anything from it.

Thanks,
Ben

[yea_likethecity · Accepted solution]

Ben,

If you don't change anything at all I don't know why there would be differences between the files, functionally. The Xilinx tools may show small differences in how they're compiled and I have seen small differences arise when the same components are moved around on a block diagram. In particular I've seen slightly better performance arise from cleaner FPGA block diagrams.

[GerdW]

Hi bmc,

even if it does not help with your current problem I recommend to employ some kind of code revisioning tool (like GIT or Subversion) to avoid problems like this in the future! It would be so easy to check out the version used for your "working compilation"…

Can you start to recreate the FPGA VI stepwise, enabling certain parts with each compilation? In which way the new compilations behave different than the old one?

[bmccarney]

Alright, I figured out what had happened.  I checked out the bitfiles in an XML viewer, and while it doesn't list the project the file was built from it did call out Fixed Point configurations for some of the controls.  This allowed me to trace the build to an even older project file that had run at a faster rate, which had supposedly been abandoned due to poor performance.  Suddenly everything makes sense again.

I really appreciate the help, and yes configuration management will be a key issue moving forward.

Thanks!

Ben