Is there an obvious way to prevent an FPGA multiply from using DSPs?

[Thoric]

OK, this is weird. I wanted to attach the project for you, but it's massive, so I created a copy of the Project and removed everything unrelated to this 9516 test FPGA code (ie the PC code, Real-Time Code, unused FIFOs etc.). Note that I left all hardware definitions in place. The FPGA code is unchanged, absolutely unchanged, but when I compile it in this project it succeeds!

So I went back to the original Project and compiled the test FPGA VI and guess what - it still fails. The same code. Two projects with identical hardware definitions, one a clone of the other but with unrelated items removed. What the h***?

So, because I've experienced corruption of project items before (especially when migrating between LV versions) I took a blank project and dragged everything from the original project into it, making a brand new duplicate project. I then performed a compile of the 9516 test FPGA code but it still failed.

So I'm now removing the unrelated Project items block by block to discover at what point it compiles...

[Thoric]

update: In the cloned project I removed project items group by group until I only had the FPGA Build Specifications remaining (and the 9516 test FPGA VI). I deleted the build specs, rebuilt the test VI with default compiler settings and it compiled.

Going back to the original Project and deleting the build specification for the 9516 Test FPGA VI and recompiling it results in a fail. Same timing error as I'm seeing all along.

Not sure what to do now. If I attached the slimmed down clone Project, the FPGA VI compiles fine so there's nothing for you to study TJ.

If I attached the original Project it'll have to be through secure means because we need to protect the content and, secondly, it's pretty big.

Suggestions??

[T-REX$]

Can you zip and password protect the code, then upload it to  ftp://ftp.ni.com/incoming (using windows explorer is recommended). Then just PM me the password to the zip. If you need a tool to password protect the zip file, then I recommend 7-zip.

Interesting to see that this is heading towards a project corruption issue...

[Thoric]

Hi TJ,

In the past couple of hours I tried something related. As well as deleting the Build Specification I pressed CTRL+Shift Run Arrow to force recompile the entire FPGA heirarchy. This then compiled successfully on the original project, and not just the 9516 Test FPGA VI but also the very original full VI.

This is an absolute first for that VI in any version of LV since 2009. And very disappointing that we've been avoiding upgrading the project all this time due to compile failures when it seems to be a project corruption.

On an interesting note, when I closed the Project LabVIEW crashed nastily. This was before I got a chance to save the Project so after reloading it I still have no Build Specs. I'll have to compile it all again to see if I can repeat the success.

I'll also try to zip it up protected and PM you the password...

[Thoric]

I'm afraid I'm unable to zip up the project. The project dependencies are a bit dispersed due to the history of the project, and if I perform a "File > Save As > Duplicate .lvproj" LabVIEW thinks for about 10 minutes then crashes out. I think there might be some serious project tree corruption here, I'm seeing too much ungraceful exiting

[PaulRB]

Hi Thoric,

I'm not sure why timing is failing, but I can tell you that you shouldn't be running the 9516 FPGA methods in a loop that is running at 100kHz. In the 9516 manual, you will notice that the maximum position loop rate for the 9516 is 20kHz. The main reason for this restriction is that it takes time to transfer all of the data between the 9516 and the FPGA. The 951x modules have more data to transfer than most other C Series modules and so that is why it can take up to 50usec for this to happen. You can probably get better performance than 50usec, but you certainly won't be able to get 10usec.

Again, this may not be what is making the timing fail, but it is a good change to make to your code.

Thanks, 

[Thoric]

Paul, what are the consequences of calling the 9516 encoder methods at 100kHz? Our code compiles ok in LV2009 and our encoder position data seems to vary for each 10us sample. This indicates to me that it works, no?

[PaulRB]

Hi Thoric,

Nothing bad will happen if you try calling the encoder methods at 10usec. However, the loop will not actually run at 10usec because the methods block until they are finished. The Write and Read methods will return pretty quickly (~10 clock ticks), but the scan method takes much longer. I just did some benchmarking and it looks like the scan method takes ~30usec to finish, so you won't be able to read from the encoder any faster than that. If you're seeing something different, I would be curious to see your code.

Thanks, 

[Thoric]

Well now, that's certainly got me thinking. We were pretty happy with the 100kHz data coming back from these modules, but we do actually run our system at fractions of the 100kHz also so it may be that we've been checking 10kHz data and decided we were happy. Let me check some genuine 100kHz data and see what we can see...

[Thoric]

We're still looking for some 100kHz data. It appears we do the large majority of acquisitions at 10kHz or less, so we won't be subject to the 30us limit you've identified. We don't actually have a useable machine around to perform a 100kHz test but we're not far from building a new one so we might be able to conduct a fresh test soon. Until then....