1
\$\begingroup\$

I want to see how certain algorithm would fit FPGA architecture and plan to implement it with HLS tool like CλaSH which produces VHDL/Verilog. All I know about FPGAs so far is it's an array of interconnected logic blocks. So I wonder how can I ensure it's gonna be possible at all since every code construct consumes a certain amount of logic blocks of FPGA and it simply might not have enough of it?

For example when developing an algorithm for CPU prior to even trying to run it you need to ensure that it will have enough memory to load the code. It's never the problem with modern PCs anymore but it's very tight with FPGAs, right?

Is there a way to determine how much logic blocks an implementation requires prior to running it (... purchasing a dev board)? Are there any other considerations needed to be accounted for like logic blocks array width/length (which determine the flow parallelism?), etc?

\$\endgroup\$
  • 3
    \$\begingroup\$ Yes you should. Alongside simulation (where you do most of the work),occasional trial synthesis runs are good practice to (a) establish that your design actually is synthesisable and (b) to highlight resource or clock speed problems you may need to resolve. For small or medium designs yo ucan do this with the free downloadable tools, no need to choose a specific FPGA until you know which is appropriate. \$\endgroup\$ – Brian Drummond Mar 24 at 13:02
  • 1
    \$\begingroup\$ Every development tool I've ever used will provide some kind of resource usage report, which will give you an idea of how much of the FPGA's primitives you're using. Typically the dev tool makes this available after the Implementation stage (converting your design into primitives and wiring for a specific FPGA IC). I've had to switch FPGAs in mid-development because because I maxed out the resources on smaller chips. That said, you pretty much have to create the design to judge its size. And sometimes you have plenty of SLICEs or LUTs, but nowhere leftover to route your data, for example. \$\endgroup\$ – schadjo Mar 24 at 13:13
  • 2
    \$\begingroup\$ You buy what the FPGA manufacturers have in their catalogues. You order a custom FPGA is you're the military of a large country and have a bazillion dollars. \$\endgroup\$ – Neil_UK Mar 24 at 13:30
  • 1
    \$\begingroup\$ @slav What's your budget? digikey.com/product-detail/en/xilinx-inc/XCVU47P-3FSVH2892E/… \$\endgroup\$ – schadjo Mar 24 at 13:32
  • 1
    \$\begingroup\$ @Slav If you're not a large country military, and you're not a large customer, then you lobby the FPGA manufacturers, and hope their marketing department sees merit in your suggestions. As a small (10k per year level) user, I lobbied Analog Devices and Xilinx for years to make their fast ADCs and FPGAs easier to connect. By the time high speed JESD204B was properly available, I was retired. I'd like to think I contributed a little to their motivation, perhaps 0.001%, or maybe a few more zeroes in there! \$\endgroup\$ – Neil_UK Mar 24 at 14:09
3
\$\begingroup\$

Your question is rather broad.

To start with: the good new is that you don't need to buy an FPGA board to find out how big your design is. The development tool will tell you. It will also tell you if you exceed the number of resources (Memories, LUTs, Registers, DSPs or I/O pins.) If it does not fit, you select a bigger FPGA in the tool setting, until you get to the really BIG ones you probably can't afford because they are e.g. $15000 each.

The second good new is that most FPGA development tools are free, at least for the smaller FPGAs. And 'small' is still rather big.

The not-so-good new is that HLS is still in development. We ran some tests and they still markedly under-perform compared to Verilog or VHDL. But for just comparing algorithms they are probably good enough.

Now as to "flow, parallelism" you get into difficult areas. The more logic in parallel or more pipeline stages the faster the algorithm will run. But also the resources utilization (area) will go up. It is one of the many tasks of an HDL designer to try to find a balance between speed and area.

Getting to "array width/length". That is the fastest way I found to fill an FPGA. I recently designed code for convolution matrices. It was a module which had the matrix width/height as parameters. With little trouble I managed to fill 60% of the FPGA with that module alone (It was supposed to use 15%).

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ Thank you for answer. Surprising to see a criticism towards HLS since I thought the higher level description is - the more ways remain to optimize the solution (with lower-level ones it's hard to see patterns etc.). Also, weird to see a differentiation between small and big FPGAs - aren't they just arrays? It's understandingly how they might differ with IPs provided, but principally differ just from their sizes, hmm? \$\endgroup\$ – Slav Mar 24 at 16:22
  • 1
    \$\begingroup\$ HLS is coming, it is just not there yet. Like the first compilers these things need time to develop. "weird to see a differentiation between small and big FPGAs" I don't think I am doing that other then pointing out that really big ones are expensive. \$\endgroup\$ – Oldfart Mar 24 at 16:29
  • 1
    \$\begingroup\$ There’s two basic types of FPGAs. Low-to-midrange types optimized for systems, which include rich I/O sets and sometimes even hard CPU macros (like Xilinx Zynq for example.) The other type is optimized for logic resources, and don’t have fancy I/O macros or CPUs. These are most often used for ASIC prototyping. \$\endgroup\$ – hacktastical Mar 24 at 17:51
1
\$\begingroup\$

The larger and more timing-critical your design, the more it should be aware of the underlying logic resources implementing it. This is true whether you’re working with an FPGA or ASIC flow. You will need to understand this to get the device to fit and to close timing.

FPGAs have hardware macros that help with this: RAM, special I/O, ALU/DSP blocks, clocking / PLL and other resources that improve performance and density. A good way to take advantage of these is to use the library elements that come with the tool flow. Not only does this save time, but they serve as a jumping-off point for a more optimal design later as you gain familiarity with the IP blocks on chip.

Pure logic can be optimized for the LUT structure that’s available, but in most cases it’s better to let the synthesis tool figure that out.

| improve this answer | |
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.