<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Dec 17, 2018 at 6:31 AM Mendell, Mark P <<a href="mailto:mark.p.mendell@intel.com">mark.p.mendell@intel.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-CA">
<div class="gmail-m_-1642117242325642430WordSection1">
<p class="MsoNormal"><span>Not only do FPGAs not support recursion, we don’t even support calls! 
<b>All</b> user code must be inlined into one kernel/component, which is then used to create HDL for the FPGA.</span></p></div></div></blockquote><div><br></div><div>That's an implementation choice. Verilog allows you to use recursion to generate complex structured circuits. Of course, it's all just inlined and the recursions have to hit bottom during that process.</div><div><br></div><div>Do you also insist on no loops, or at least only loops with explicit fixed trip counts? What about AREF?</div><div><br></div><div>I've worked on a GPU back end for llvm where we inlined all function calls into each shader/kernel. That was convenient, but only ever as a stop-gap and OpenCL 1.2 lets you get away with that.</div><div><br></div><div>On very restricted machines it's often easier to create a simple interpreter using the native features and then target your actual program at the interpreter. It's slower, of course, but much more flexible. This applies equally as much to FPGAs as it did to things like the 6502 forty years ago where most programming was done in either tokenised BASIC or else Pascal compiled to bytecode (or even SWEET16). Every day I use an FPGA programmed to interpret RISC-V opcodes and it supports not only function calls and stacks and recursion, it's running a full Debian Linux as quickly as an early Pentium or PowerPC did.</div><div><br></div><div>Depending on the performance needs, an interpreter might be a good option for the OP.</div><div><br></div></div></div>