At a high level, it's a relatively simple tradeoff: software development for DSP or general-purpose microprocessors is typically much less labor-intensive than FPGA development. At the same time, the amount of computational throughput offered by an FPGA typically far exceeds what a CPU can do, because you can tailor the logic specifically for your application.
Most any processor that is advertised for "DSP" will have multiply-accumulate (MAC) instructions available, and it is common for DSP processors to be able to execute multiple instructions per cycle. If you read the specifications for TI's C6713, you'll see that they advertise that it can complete up to 8 instructions per cycle (not necessarily all MACs, but a mix of several types of instructions). Note that it is pretty difficult to get close to that throughput, but it is possible if you invest enough effort learning how the architecture works and structuring your code accordingly.
One other major difference between an FPGA implementation and the particular DSP that you noted is that the C6713 supports native floating-point capability (instead of just fixed-point). For some applications, this can make algorithm implementation much simpler, as you don't have to worry about the issues that come along with fixed-point computations. While it is possible to implement floating-point computations in an FPGA, such an implementation would be much more demanding on the hardware, so depending on how complex your algorithm is, you might run into issues with resource utilization, achievable clock speed, and so on.
You should start by quantifying what kind of computational demands your algorithm is going to place on your hardware. Then, decide how much engineering time you can allocate to the project; from there, the choice will likely be clear.
