Compile Error in FlexRIO FPGA when using derived clock

[AlexAAuck]

I am attempting to compile FPGA code for a 7965R in a PXIe-1073 Chassis. Attached is a screen shot of the code I'm attempting to compile and specifically the clock that seems to be causing the issue. I am trying to write 128bits to DRAM at 12.5 MHz (Derived write rate from 100MHz single cycle timed loop with a write operation every 8 cycles). Once the DRAM has absorbed the data I would then like to read it out as fast as possible (but below 100MHz as running at 100MHz is right on the edge of line speed and is probably responsible for my data loss issues) into a To-Host DMA. I've tried to set up a 90MHz Clock which is derived from the PXIe DstarA Clock (which seemed to be only one where I could modify its clock speed).

Unfortunately I get the following error after the compile runs all the way through to placing and routing:

Error -61499 occurred at niFpgaCompileWorker_AnalyzeTimingViolations.vi<-niFpgaCompileWorker_AnalyzeTimingPaths.vi<-niFpgaCompileWorker_CheckForErrors.vi<-niFpgaCompileWorker_JobComplete.vi<-niFpgaCompile_Worker.vi:1

Possible reason(s):

LabVIEW FPGA:  An internal software error in the LabVIEW FPGA Module has occurred.  Please contact National Instruments technical support at ni.com/support.

Additional Information: This timing violation is other than Period(<twConstInt>)
This timing violation is other than Period(<twConstInt>)



Return Code:-3003

Start Time: 6:18:21 p.m.
End Time: 7:14:35 p.m.
Total Time: 00:56:14

Any ideas what's going on?

P.S. I've also attached a screen shot of the way I set the clock up.

[JordanG]

Hey AlexAAuck,

Would you be willing to post your code so we can try reproducing this behavior on our end? Also, will you please attach any Xilinx logs/reports that were generated when the compile failed? This looks to be associated with the Xilinx tools, so those reports will help us figure out exactly what's going on.

Thanks,

Jordan

[AlexAAuck]

Hey Jordan,

Attached is a zip file of my code as well as the Xilinx Log for that compile. Still getting the same problem even though I'm now using a "derived clock" from the 40MHz base clock, rather than something based of DstarA.

[charris]

Alex:

I took a look at the project, but there are a couple VIs and typedefs missing for me to compile the VI.

• Camera Link Data Mapping (typedef)
• CL Configuration (typedef)
• Serial Interface.vi
• Counter.vi
• Rising Edge Detector.vi
• Falling Edge Detector.vi

If you have any issues posting those up here, let me know. We can arrange other methods of getting the files across if need be.

[AlexAAuck]

Hi charris,

All of these subvis can be found in the labview 2009/examples/flexrio/io modules/ni 1483/ sub folders.

[charris]

Alex:

That would explain it. I don't have the vision SW installed for that example, so I'll go grab it.

[AlexAAuck]

Just to update you, I'm now working on a completely separate piece of code (that uses the same base code). With all the DRAM sections removed. Also there are no custom clocks present. But I'm still getting the same error as in the OP.

I've attached the xilinx log for this compile, and also the different version of the VI I'm using. This is starting to become a serious road block.

[AlexAAuck]

Yet more data, I added an older version that I know compiles sucessfully and it's now returning the same error. I'm pretty sure the error is nothing to do with my code, something in Labview has broken. I'm on the verge of doing a reinstall but I really don't want to as it's a long painful process.

[AlexAAuck]

Ok, some more information.

I reinstalled the FPGA module, but this had no effect on the compile, the same error as in the OP was generated. I tried removing the custom clock (in this case it was an 80MHz derived from the 40MHz base) and it worked! All my code is compiling now. This is odd as there were no custom clocks in any code except the DRAM and all were reporting the same error. So it seems just having the custom clock in my project was causing compile failure.

Now I'm struck with the issue that I can't manipulate DRAM at anything other than 100MHz (too fast, probably resulting in my lossy data transfers) or 40MHz (too slow). So I've narrowed the issue down, can one of you engineers suggest a fix?

Regards,

Alex

[charris]

Alex:

I think I have something figured out.

I sat down with one of our R&D engineers and tried some things out on the compile farm. Here's what we found:

In the project, you've specified the clock domains for DRAM writes and reads:

However, in the FPGA VI, the SCTLs with the DRAM read/write operations are not always specified with the correct clock domain:

If you correct the specified clock domains on your SCTLs to match the project configuration, it should go through without timing violations (regardless of whether or not the clock source is derived).

We got it to compile successfully on LV 2010/RIO 3.6 after making those changes.

Let me know if you still have issues after making those changes, and we can move forward from there.

Thanks!