LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

FPGA Write/Inject/Edit data post compilation

Hello Labview community,

 

Is there any way to write, inject, or edit data post or during FPGA compilation? I am trying to do a form of version control where I change a indicator or constant to be a version number and bit hash. I need to figure out a way to write to the fpga after it compiles whether it be editing the bitsream, injecting a tcl script during compilation (which doesn't seem possible. Seems like its only possible via host vi scipts which would run after compilation).

 

Any guidance would be appreciated. Thanks!

0 Kudos
Message 1 of 13
(2,834 Views)

Why does it have to be after compilation?

Can't you use scripting to do it before the compilation? Possibly on an automated build machine that checks out your code from SCC, etc?

It's not FPGA, but I do this for my PPL files (adding a version VI to the library before building, with version number and hash from git).

 


GCentral
0 Kudos
Message 2 of 13
(2,803 Views)

We want to embed it into the vi, so we cant know the bitfile or a api files (the end goal is to go to get the c api and such and gives it to a linux machine) until after compilation. Also if its after compilation, then we're doing a circular logic flow of getting the hash, compiling, committing, reupdating the has, compiling, commiting, etc.

0 Kudos
Message 3 of 13
(2,801 Views)

@bchang32 wrote:

We want to embed it into the vi, so we cant know the bitfile or a api files (the end goal is to go to get the c api and such and gives it to a linux machine) until after compilation. 


Sorry - I don't really understand this bit.

 


@bchang32 wrote:

Also if its after compilation, then we're doing a circular logic flow of getting the hash, compiling, committing, reupdating the has, compiling, commiting, etc.


On the other hand, this is clear. But is it inherently a problem (maybe for you it is, but I wonder) if the commit hash stored in the bitfile is the commit of the source from which the bitfile was built, rather than the commit in which the compiled bitfile is stored?

 

Of course a bitfile takes a while to generate (for me, around 20-30 minutes, but I gather it can be much longer in some cases) and so I understand why you'd want to store it in the repository. I just don't know if you can't use the source commit for the version.

 

Version number is much simpler, since you can increment it in whatever way you like before the build.

 

With regards to the original idea of injecting some values after build - wouldn't you have the same problem? You'd change the bitfile, and then want to commit it again. But then you'd need to change the same part of the bitfile (unless you can use the smudge filtering).


GCentral
0 Kudos
Message 4 of 13
(2,783 Views)

So we want it all automated vs manually updating the version number since the user could forget to do that and thus having conflicting v1.0.0.0s. At the end of the day, we want to send the linux user the lvbitx file and he or she should be able to determine which version/build it is.

 


@cbutcher wrote:

With regards to the original idea of injecting some values after build - wouldn't you have the same problem? You'd change the bitfile, and then want to commit it again. But then you'd need to change the same part of the bitfile (unless you can use the smudge filtering).

 


We are hoping for a way to fill out the register some way during or after compilation. I am currently looking into tcl files but with the labview compiler, I'm not sure if theres a way I can inject a tcl script somewhere in there.

0 Kudos
Message 5 of 13
(2,759 Views)

Whoops error, please ignore this. For some reason I cant delete

0 Kudos
Message 6 of 13
(2,767 Views)

Hello,

 

Is there any way to mess with/edit the vivado software that labview FPGA uses to compile vis? I want to add a tcl file (like this http://www.irtc-hq.com/wp-content/uploads/2015/04/FPGA-TCL-Scripting-2014-02-24.pdf) to edit registers pre, during, or post compilation.

 

Any informatino would be appreciated.

 

Thanks!

0 Kudos
Message 7 of 13
(2,768 Views)

I've never tried this with LabVIEW FPGA but this could work:

 

https://forums.ni.com/t5/Example-Code/RT-EXE-Versioning-Example/ta-p/3751234


Certified LabVIEW Architect, Certified Professional Instructor
ALE Consultants

Introduction to LabVIEW FPGA for RF, Radar, and Electronic Warfare Applications
0 Kudos
Message 8 of 13
(2,742 Views)

So the issue with this one is that we want to avoid using a host vi. We only want to use FPGA vi.

0 Kudos
Message 9 of 13
(2,738 Views)

@bchang32 wrote:

So we want it all automated vs manually updating the version number since the user could forget to do that and thus having conflicting v1.0.0.0s. At the end of the day, we want to send the linux user the lvbitx file and he or she should be able to determine which version/build it is.

 


@cbutcher wrote:

With regards to the original idea of injecting some values after build - wouldn't you have the same problem? You'd change the bitfile, and then want to commit it again. But then you'd need to change the same part of the bitfile (unless you can use the smudge filtering).

 


We are hoping for a way to fill out the register some way during or after compilation. I am currently looking into tcl files but with the labview compiler, I'm not sure if theres a way I can inject a tcl script somewhere in there.


Maybe a quick question: how are you building the bitfile? You've mentioned a Linux computer a couple of times and passing off a C API(?) but I'm not sure I've understood correctly.

When you say someone should be able to find the version from the .lvbitx file, does that imply whilst it is running (i.e., I run the FPGA VI on an FPGA, and want to check a front panel indicator telling me the version) or you want to grep some value from the file on (host computer) disk?

 

What I'm doing for my PPL builds is basically this (which covers the first but not the second option above):

Script a Version VI and add to library (you wouldn't add to library probably)Script a Version VI and add to library (you wouldn't add to library probably)

Get current version from git tagsGet current version from git tags

Set new version based on old version and "Build Type"Set new version based on old version and "Build Type"Template for the VI to get versionTemplate for the VI to get version

Parse the version string from git to a Version clusterParse the version string from git to a Version cluster

and should work for FPGA too (substituting the string containing the version hash for probably the actual number given as a hex string here, since no strings on FPGA).

You'd want to avoid the creating a new VI and instead modify an existing VI, since you'd need the FPGA VI to call that VI in your actual source code (so no need for the Adding to Library stuff).

This is scripted during my build process, so for you this could be done automatically after checking out the source, before calling the Vivado/ISE compiler, but perhaps you're doing something completely different...

 

It avoids any manual interaction with version numbering (beyond specifying the "Build Type" via commit message) and ensures all the PPLs are build with automatically increasing version numbers.


GCentral
0 Kudos
Message 10 of 13
(2,706 Views)