Hacker News Reader

Comment by joe_the_user | Hacker News Reader

I would like to know what about motion planning makes it more suitable for a FPGA than a GPU.

Wasn't able find any scholarly papers on this particular project searching the various references. Can any supply some more information?

View on HN

Here's the original paper: http://people.ee.duke.edu/~sorin/papers/rss16_chip.pdf

In short: collision detection checking across all of the edges in a PRM graph takes 99% of planning time and can be done compeletely independently.

For this task, I think a GPU should be faster than an FPGA in the same price range, but it will be less power efficient.

Source: I looked at CPU vs GPU vs FPGA vs ASIC for deep learning algorithms.

When concerned with robotics, several obvious ones come to mind around power and footprint.

It's very easy to go from FPGA "source code" to a foundry and get a chip with exactly the same thing implemented, and at a cheap price if your scale is large enough.

Yeah but why can't you do it on a normal CPU or GPU?

You can do both CPU and GPU, but time and power consumption are both order-of-magnitude worse than using dedicated hardware. The robotic arms are also used untethered in factories, where having a computer near them is inconvenient.

The article describes results for using a Xeon CPU. The linked paper cites other papers where a GPU was used.

I said the same thing a year ago when I had FPGA synthesized verilog and decided to go get a real chip made. Closing timing along with optimizing for PPA for an ASIC vs an FPGA is a royal PITA. And that's just on the front end design work... A core on a FPGA gives you no real idea when it comes to placement or all of the other hurdles of the backend flow of a real ASIC!

We ended up re doing everything (which overall was a good thing, as we made a lot better decisions from the beginning by redesigning), but that's show biz.

This used to be Altera's "Hardcopy" advantage: an easy gate-array version of their FPGAs could (in theory) be made because: 1. the gate array uses the same gates as the FPGA, just the interconnect is customized. 2. Use Primetime compatible timing constraints for the FPGA design to begin with.

While obviously better than just the FPGA, it is still very inefficient compared to a real ASIC. Altera and Xilinx both stopped offering their programs in this area due to the fact that it as it is not really cost effective to have the same transistor level mask set and then have to buy all new masks on top once you get to sub 28nm processes.

As for primetime, we use Synopsys Synplify Pro for FPGA synthesis, and while it does a better job than Altera/Xilinx's tools, it does no where near as well (and works very differently) compared ot physical aware synthesis from Design Compiler or RC/Genus.

Primetime is just the timing checker.. where the syntax for sdc files originated I think.

We found that Synplify Pro is not quite as good as the vendor tools (xst/quartus) for FPGA synthesis, but I've not compared them recently.

Actually there used to be a version of DC for FPGAs, but it was not good at all. I think it was not as prepared to duplicate logic or flops as compared with the FPGA specific tools.

Reply on news.ycombinator.com