bitfile signature doesn't match

[christian_w]

I have 3 development workstations with LabVIEW + RT and FPGA option version 2010 SP1 and none of them accepts a bitfile compiled on an other station than the creator workstation.

If I zip my project incl. build (bitfile) and and drop it to an other dev workstation the bitfile signature check fails.

The target is a MXIe RIO chassis (LX110). I haven't tested other targets under v2010SP1 so far, but can't remember such problems with cRIO systems.

Any ideas what's wrong here ?

br Christian

[JoGrMu]

Hello Christian,

my name is Johannes Graeper and I am NI applications engineer. I will take over your request.

Here are some questions I would ask you to answer:

When you build the bitfile on the dev computer, and then move it to another computer, it will not work with the MXIe-RIO on the target computer?  Could you provide an example project with a bitfile using the 9159 (your computer will be the dev computer) and I will see if I can get it to work on my PC (my computer will be the target computer).  Also, what MXIe card are you using in your PC?  What modules are you using?  How are you moving the bitfile to the FPGA (RIO device driver or through the Open/Close FPGA reference?  At what point do you see the error?  Could you please attach a screenshot?  Furthermore, since you are using 2010SP1 you are using NI-RIO 3.6 correct? 

I look forward to hearing from you.

Johannes Graeper

Applications Engineering

National Instruments

[christian_w]

Hello Johannes,

thanks for your reply. I made some additional tests and it seems that there's some path dependency in the signature check. The check already fails if I move my project to a different location on the same computer! I still suppose that this behaviour is MXI or LX110 specific because there are no such problem with cRIO(Virtex or LX50) devices.

To your questions

I'm not allowed to send you specific code. I'll have to setup an example project..

MXIe card is NI PCIe-8361, 1 Port MXI-Express Interface

I use NI-RIO 3.6

The error occurs if I start the signature check via the build specifications context menu.

Your Question

> How are you moving the bitfile to the FPGA (RIO device driver or through the Open/Close FPGA reference?

I'm not sure how to answer. To deploy the application I first use the RIO device driver (device setup) and in the realtime exe I open the reference to the FPGA main VI. In the dev environment I just start the FPGA main VI and then the RT main VI.

Best regards

Christian

[mdmorar]

Hi I am having a similar problem as this one. Here is my scenario.

I have compile an FPGA on a single cRIO. Verfied that all my IOV variables are deployed and the bitfile matches.

I proceed to take that cRIO and image it with the RAD utility. I take that image and put it on a newly formatted cRIO.

My RT is spawning the FPGA reference using the bitfile, but when you check with my dev environment if the cRIO bitfile matches, it does not. I lose all signals for the modules that sit on the FPGA.?

How do I ensure that my image will work on ALL the cRIOs I image in the future if the bitfile does not get transfered with the compile? I tried using the build specification instead and recompiling but still not luck the image does not accept it.

My next step is to try and use the VI itself in the FPGA reference call.

If anyone has a solution I'm all ears. I'm stumped at this.

Thanks,

Monil

[MrQuestion]

mdmorar,

You said that when you connect the cRIO to the DEV machine for bitfile confirmation it fails. You never mentioned if the cRIO was functional before you connected the DEV machine.

I have always used "Dynamic mode" and open by bitfile for creating my fpga reference.

I also always check the "Separate compiled code from source file" box under the VI properties.

Anytime you do anything with the VI on your dev machine LabVIEW likes to fool around with the compiled code. This includes just opening it to see what’s there, and I suspect when you sneeze around it as well. 

When this happens LabVIEW all of a sudden doesn't think that it's own FPGA bitfile that it just compile is valid. 

You will often find yourself just staring at the screen in disbelief when you want to go and deploy your solution and LabVIEW is telling you in the most inappropriate way "NO". You must recompile first.

Then you remember, ohh, ya while I was working on the RT code the last couple hours I took a peak at the FPGA code because I forgot something, and then you realize that you just invalidated your compiled bitfile for nothing.

Also, don’t recycle your *.ctl between the RT and FPGA world. Keep your refnums, and type defs separate. Because changing any of these will force a recompile (except for some versions of 2011, in which case it would just make LabVIEW go POOF)

I’m in a regulatory industry, and the formal release process required that I release the Bitfile code separate from the RT code (thus two part numbers) I had to prove that I could keep one version of the RT code the same while modifying the FPGA without a recompile of the rt code, and vice versa for modifying the RT code.

-good luck

[mdmorar]

Hey,

thanks for the reply. I will look into these suggestions and settings. I know I am creating the reference with dynamic mode on and not including the VI in my VI properties, but I will double check.

Also, I will check if there are any controls that sit on RT and move them to the FPGA just for clarity, and seperate them out.

I suspect there are none, but I may have overlooked something.

Thanks,