crio904xBaseLogicx in a cRIO 9057

[nkraemer]

I recently had a cRIO-9057 FPGA build fail due to a timing error. I'm using LabVIEW 18.02f (32 bit) and Vivado 2017.2 (64 bit).

Although the timing requirements of the 40 MHz clock I use are met, it appears some NI internal logic is failing. When I click "Investigate Timing Violations", there is one path comprised purely of non-diagram components that is failing. Most of the components of that path are prefixed with "crio/904xBaseLogicx/..."

Is the presence of 904x logic expected in a 905x cRIO? Is there anything I can do to help prevent these errors in the future besides playing around with build settings and performing minor-tweaks to hope I can get the build to succeed? I am using < 50% of slices, so I can't imagine I'm asking too much of my FPGA here.

[TyVo]

Hi Nkraemer,

I checked the compatibility of your hardware and software and everything looks good there. 

Are you seeing this error consistently with your code or only on some builds? Have you tried compiling a simpler code like a LabVIEW example to see if this error may be might be happening on other unrelated builds? Knowing all the different cases that we see this error can help us narrow down the root cause.

One good step here might be to Format Disk of the cRIO through NI MAX.

-TyVo

[nkraemer]

Hi TyVo, Thank you for your reply.

I am seeing the error only with some of my builds. Most of my builds (~70%) pass without issue, but occasionally one will fail. While this is not a show stopper, as I can usually get a successful build with minor tweaking and re-compiling, it is rather annoying.

If I had to guess, NI directly ported some of their code from the Kintex-7 based 904x series to the Artix-7 based 905x series. Some of that code only marginally passes on the slower Artix-7 fabric, and sometimes the Xilinx tools fail to meet the timing requirements when there are non-trivial amounts of user block-diagram logic to implement. Does this sound like a reasonable explanation to you?

How would formatting the disk of the cRIO affect whether or not I can successfully get my FPGA code to build?

-Nicholas

[TyVo]

Hi Nicholas,

I'm not personally familiar with the low level functionality of the compiler tools but it is Xilinx that makes the tools so I don't believe it would be an NI "porting" mistake. 

NI does have some documentation to help programming for timing performance on FPGA: http://zone.ni.com/reference/en-XX/help/371599K-01/lvfpgaconcepts/optimizing_fpga_vis/

I hope that can provide some amount of help.

-TyVo

[nturley · Accepted solution]

---

@nkraemer wrote:

If I had to guess, NI directly ported some of their code from the Kintex-7 based 904x series to the Artix-7 based 905x series. Some of that code only marginally passes on the slower Artix-7 fabric, and sometimes the Xilinx tools fail to meet the timing requirements when there are non-trivial amounts of user block-diagram logic to implement. Does this sound like a reasonable explanation to you?

---

This is all correct. A lot of the 904X logic was ported to the 905X family because they are very similar architectures. The timing performance on our Artix-7 FPGAs isn't as good as our Kintex-7s though. We applied several mitigations to get it to a good enough level before we shipped the product, but we still aren't happy with how often it fails. We have some fixes we are working on so in some future release we'll probably be able to get it down to less than 1% of compiles with 50% utilization.

Until we can get a better fix out, the only work around for 905X users is to either find ways to reduce their FPGA resource usage (ie offload IO to DAQmx) or upgrade their hardware to a bigger FPGA.

[nkraemer]

---

@nturley wrote:
We have some fixes we are working on so in some future release we'll probably be able to get it down to less than 1% of compiles with 50% utilization.

---

Thanks for the update nturley. Are you able to provide a rough timeline of when you expect to ship these fixes?

[nturley]

---

@nkraemer wrote:
Are you able to provide a rough timeline of when you expect to ship these fixes?

---

I'm always hesitant to comment to things we haven't finished yet, because priorities can change as things come up, but I would be surprised if it didn't make it into CompactRIO 19.1.

[yea_likethecity]

Hey all,

I wanted to chime in with some information for current and future readers:

1. This issue has nothing to do with the Xilinx tools, it's related to the IP that ships with NI-RIO
2. Reformatting the target will not have any effect on this issue
3. Optimizing code for timing is unlikely to have an effect, since this issue is due to components which the user does not have access to