How are High-throughput Math Functions in Labview FPGA allowed in SCTL?

[linu95k]

Actually I am trying to implement CORDIC myself.

[rolfk]

---

@linu95k wrote:

Actually I am trying to implement CORDIC myself.

---

Hmmm. Can you elaborate on the reasons? I mean anybody is welcome to reinvent the wheel over and over again, but what is the purpose of this? Is it for a school project? Is it for your personal education?

The algorithme itself isn't quite so complicated. https://en.wikipedia.org/wiki/CORDIC gives a good overall explanation of it and even a Matlab code example. Implementing this in the empty sequence box isn't quite rocket science. Getting all the corner conditions and handshaking right will be a different beast of burden however. And testing it to proof that it actually works correctly will be an even bigger piece of work.

Trying to parallelize it so you can do pipelining to reduce the latency will however make it considerably more complex (and resource hungry).

[linu95k]

What I'm trying to achieve is a ground level understanding of limitations of LabVIEW FPGA (which are many) and trying to understand the reasons and work-arounds of these limitations applying my own understanding. 

I know it is tedious but I has been done so I'm keen on knowing how it's done and if it can be done in a better way.

[rolfk]

Good luck with that. Although your statement about limitations of LabVIEW FPGA makes me believe, that you are not exactly understanding what you are trying to do.

Yes, FPGA has limitations in some ways compared to a software implementation of certain algorithmes. That has not so much to do with LabVIEW as more being a principal feature of trying to implement algorithms in hardware.

If you believe you can do better, by all means have a go at it. You will almost certainly discover however that it is a lot of work and while you may be able to improve certain aspects of it, it will come with costs in other areas such as significantly higher resource usage, lower performance or shortcuts that do not cover certain corner cases. Every such solution may have its merits depending on your exact use case, but is most likely not a generically usable solution.

At the core of many of these functions is actual Xilinx IP knowledge that NI simply reuses rather than reinventing the wheel again. I would very much doubt that anyone without VERY deep analytical knowledge of both the algorithms as well as the specifics of implementing them in an FPGA device, will be able to beat the Xilinx developers at this.