A general purpose CPU paired with an FPGA to offload specialized workloads onto seems like a really sweet deal - that is until you realize that configuring the FPGA with a new bitstream is pretty slow (so live reconfigurations would be irregular) and the toolchains for building code which controls interoperation between the CPU and whatever you've placed into the programmable fabric is poor (so designing good custom hardware accelerators is a time consuming dev task).
I spent a semester working with a Xilinx SoC, and the experience was enlightening. My computer engineering friends were very comfortable with gate description diagrams and debugging with input/output wires and waiting literal hours between test cycles. I was the only software engineer in the room, and all I could do was ask myself how anyone could be OK with this awful tooling situation. It really befuddled me - I was especially frustrated while using high-level synthesis tools which take C++ and convert it into a functioning hardware description (Alleviating the need to rewrite business logic in VHDL or Verilog). It would take well-formed C++ code with a simple API and give a pretty good hardware description (sometimes with better perf than a handwritten equivalent, with a little optimizing), but fail to generate a corresponding API for it on the associated CPU for anything beyond simple register access (despite starting with what was likely the desired software API)! IMO, FPGA tooling could use a lot of TLC, but maybe I just had a bad experience.
When you think of c++ you think sequentially, but hardware doesn't work that way. I think verilog or vhdl make more sense instead of trying to get c++ to work for hardware or having to come up with more c++ code to account for the way hardware works.
I spent a semester working with a Xilinx SoC, and the experience was enlightening. My computer engineering friends were very comfortable with gate description diagrams and debugging with input/output wires and waiting literal hours between test cycles. I was the only software engineer in the room, and all I could do was ask myself how anyone could be OK with this awful tooling situation. It really befuddled me - I was especially frustrated while using high-level synthesis tools which take C++ and convert it into a functioning hardware description (Alleviating the need to rewrite business logic in VHDL or Verilog). It would take well-formed C++ code with a simple API and give a pretty good hardware description (sometimes with better perf than a handwritten equivalent, with a little optimizing), but fail to generate a corresponding API for it on the associated CPU for anything beyond simple register access (despite starting with what was likely the desired software API)! IMO, FPGA tooling could use a lot of TLC, but maybe I just had a bad experience.