Hacker News Reader

Comment by Symmetry | Hacker News Reader

To push this up from the comments, if you're interested in why this is important or what the authors are trying to do the PDF where they describe their approach and architecture is really interesting.

http://www.rsg.ci.i.u-tokyo.ac.jp/members/shioya/pdfs/Mashim...

View on HN

If I understand this correctly:

Typically, I think of an FPGA as something used to accelerate specialized operations. But sometimes, in the middle of one of these specialized operations, you might want to do something more general, like run a network stack, without returning to the CPU. A soft processor like this allows you to run an ordinary network stack (with ordinary code) inside the FPGA.

Is that right?

I thought one of the things people used FPGAs for was accelerating network stacks, so I don't quite know why you'd want to use a soft processor for that. But it does make sense that you'd want to be able to run ordinary code in an FPGA (as part of a larger FPGA operation that is not ordinary code).

EDIT: Also, I don't understand this statement: "for example, one main compute kernel, which is too complex to deploy on dedicated hardware, is run by specialized soft processors". What do the authors mean "too complex to deploy on dedicated hardware"?

Generally softcores are used for command and control for the FPGA. For eg you have a framegrabber and you would like to adjust the shutter speed, fps etc you would create a softcore and run normal firmware to setup the registers based on the users choice.

You can think of FPGA as an ASIC and the softcore to control this ASIC. The hot data path and heavy processing is done in the FPGA and processing options for the ASIC can be done using the softcore firmware.

It's definitely common to accelerate specialized operations without the overhead of a general processor, but it's also possible to effectively use them as a much more flexible microprocessor when you need it.

If you go looking for a microcontroller for your project, you have to choose among what is available. Maybe this microcontroller has two hardware UART interfaces and 1 SPI interface. If I don't need any UART but instead need a CANBUS interface that microcontroller won't work for me. Sure I can bitbang the protocol on GPIO ports but that uses up a lot of the limited processing power on the microcontroller... Usually that means a more expensive microcontroller.

There is a threshold that you can cross where a small FPGA is cheaper than a microcontroller that has enough pins and processing power for your application. This does come with an additional upfront design cost of also writing (but more often integrating) the soft cores but sometimes that makes sense.

Sometimes peripherals just don't exist at the price point you need. Try and find a microcontroller that has a MMIO controller for under $5 (I probably couldn't do it at under $10 but I haven't gone looking recently), it's rare they're needed but sometimes a design requires one.

There has also been a lot of recent interest in doing formal verification of hardware logic. A lot of the microprocessors and even that full CPU in whatever device you're reading this on has a lot of undocumented black boxes and undefined behaviours both of which prevent that verification from being meaningful.

To make a custom chip it requires one time mask fees of up to $30 million for a 5nm chip. If your volume is high then you can amortize that cost. If not then you probably go to an FPGA. An FPGA has a high per part cost but no custom mask costs and you can reprogram it in a few hours / days instead of 2 months for a new custom chip to be manufactured.

A high end FPGA already has hardened CPU blocks, USB and PCIE interfaces, and lots of other things built in. Then it has a large area of generic reconfigurable logic that you can customize to do whatever you want.

This reconfigurable logic will not be as fast as a custom chip but it is still far faster than software and can be used to implement your own CPU (assuming you don't want to use the hardened CPU or got an FPGA without them)

>What do the authors mean "too complex to deploy on dedicated hardware"?

It costs time and effort to translate a software function to HDL/FPGA, so it's not always worth doing. For example you could do TCP/IP in hardware, but unless you have particular performance requirements (say HFT) you're probably better off with a soft core and a tested software TCP/IP stack.

Also each feature translated to hardware takes up space in the fabric. When you crunch numbers on an FPGA, it's ideal if you can lay out the entire sequence of operations as one big pipeline, so you can keep throughput as high as possible. Sufficiently long or complex sequences may not translate efficiently to FPGA.

FPGAs are frequently not connected with a dedicated CPU at all, and even when they are they may be connected over a link with lower bandwidth/higher latency than you would like. In these cases you usually have a bunch of management and logic tasks which are better suited to a CPU (basically anything with a large number of different serial steps and complex control flow will probably synthesize poorly directly to an FPGA: this is probably what the authors described as 'too complex for dedicated hardware'), so you synthesize a CPU in the FPGA fabric which usually has a direct memory map to whatever registers you need in the FPGA design to accomplish your goals. This is common enough basically every FPGA vendor also sells FPGA SOCs which have a hard CPU attached to the fabric, and if you are using one of those then you will generally not synthesize a CPU in the fabric because it'll usually be slower and less power efficient than the hard CPU you have. But that CPU also isn't free and if your CPU compute requirements are not particularly high than the soft CPU might be more efficient for your usecare (or a hard CPU may not be an option in the range you need).

Ok, we've changed the URL to that from https://github.com/rsd-devel/rsd, which doesn't give much background.

Reply on news.ycombinator.com