Same code compiles for cRIO-9074 but has reports non diagram component timing violation for cRIO-9067

[MarkCG]

Hi all, just got my new cRIO-9067. I converted my project over to cRIO-9067 from the cRIO 9074. Same module layout, same scan engine timing, same custom fpga code, (hybrid mode).  I have no problems compiling it for the 9074, which is a lower performance FPGA than the 9067's Zynq FPGA.  

The compilation windows final timing shows that the timing is met for all clocks-- 40, 80, and 120 MHz (I am using a derived clock for some sctl code). During the the end of the compilation, during the bitfile gen stage, I get the dreaded timing violation. Investigating the violation indicates that it is not the custom code, it's non diagram components. One of them seem to be related to the NI 9870 serial card I have in the chassis.

Why? Is there anything I can try with the compiler directives to fix this? You'd think that it would be easier to compile for the higher performance FPGA...

[MarkCG]

I've narrowed it down to the 120 MHz SCTL. I had this code nicely optimized and pipelined and it would compile for the spartan-3 FPGA on the cRIO 9074. It could meet the timing requirement of 8.3333 ns. 

Now I can't compile it at higher than 40MHz!  here the description from timing violation, tried for 80MHz-- 12.5 ns missed by 9.48 ns!!!! 

This non-diagram component is required in the design. Internal name: /Crio9401Resource1/Crio9401ResourceCorex/Crio9401x/GenIOControl[5].Crio9401IoControlx/Gen_OneSyncRegOrNoSCL.cModuleOutputDataReg_reg

This non-diagram component is required in the design. Internal name: /dio01_INST_0/O.

What am I doing wrong..

[Jacobson-ni]

Mark,

Could you explain what this application is doing, specifically if and how you are using your 9401 module in the FPGA code.

It would also be helpful to post some screenshots so we can see the timing violation analysis window as it appears.

[MarkCG]

Hi Matt, 

I am using the 9401 in FPGA mode to generate digital pulses. I am using SCTL clocked to a higher derived clock for better resolution.

here are some timing violation screenshots . The final timing says the timing for all clocks is met, then throws the error after when generating bitfile.

[MarkCG · Accepted solution]

Ok, don't ask me how I figured this out--- to get it to work I changed nothing except this: feed the I/O node an FPGA I/O reference instead of configuring the node via the "link to" menu. It doesn't make any sense but the compilation was successful when I did this. 

I know it's this because I created a very simple test VI in my project, and made sure that it does not compile without doing this. 

[Jacobson-ni]

Mark,

Sorry I wasn't too helpful in figuring this out, but I wanted to thank you for posting your solution after you figured it out.

[MarkCG]

Hi Matt,

my concern is that this really isn't expected behavior. If you want I can send a stripped down project that illustrates the behaviour. May be of use for future versions.

Regards,

Mark

[Jacobson-ni]

Mark,

If you can attach two simple projects, one that produces the compilation error that you posted about and one that shows the fixes you made to be able to compile the VI I will try to take a look at it.

I cannot promise how much I will be able to tell you about how expected this behaviour is or not but I can definitely take a look at it for you.