Why?
I have exactly the opposite feeling when I'm dealing with software - "if only I could design my own cache here, how much easier would it be to get around this bottleneck!"
Not until you hit a deep semantic difference between your hardware and a code you're trying to build.
For example, there are many things that are best expressed as a Network-on-Chip: a pipeline of specialised CPU cores each doing something simple. And such a notion is not that easy to represent in a pure software without a gigantic performance penalty. A pair of a CPU core and a small piece of code running on top of it can be far simpler than any piece of code written for an existing but not fitting architecture.
A simple example of such would be a dedicated Forth processor plus a Forth implementation. They two together are often much simpler than, say, a standalone Forth implementation for x86.
High-level synthesis tools on the other hand might make your claim true. They're a combo of HW and SW languages.
"A simple example of such would be a dedicated Forth processor plus a Forth implementation. They two together are often much simpler than, say, a standalone Forth implementation for x86. "
Simpler for who? The person implementing both a Forth implementation and a x86 processor? Or the person just implementing a Forth on x86? I've seen Forth implementations in SW. They're trivial. Compilers, libraries, and hardware do all the heavy lifting. I'll put it to the test, though, as I feel you might have picked a good example.
J1 Forth CPU Verilog code http://excamera.com/files/j1demo/verilog/j1.v
eForth assembler for Z80 & such in few assembly instructions http://www.figuk.plus.com/4thres/systems.htm
Forth interpreter in Ada (1985) http://www.forth.com/archive/jfar/vol3/no2/article7.pdf
Maybe it's just that I don't know Verilog. However, the Verilog code looks more like the assembler in second link. It's like a pile of gibberish. The Ada code is very straightforward. I bet the debugging was easier, too. S, I'm still not sold on hardware reducing complexity versus software implementation.
I'm 100% agreeing on improving performance esp where semantic mismatch occurs. Hell, that's what inspired me to ask you and some others to evaluate those two or three HLS tools so I could start cranking out accelerators if one was legit. ;)
The cost in time and complexity of solving a problem in hardware is almost always larger.
When writing software you gain a level of abstraction. You do not have to deal with getting a special hardware (the FPGA), mess with proprietary buggy tools, and all the nitty gritty stuff of proper reset, multiple clock domains, timing closure where each rebuild of your code might take multiple hours to close. And don't get me started with writing HDL-code.
I implemented an object tracker using a FPGA and a webcam and there were multiple hardware problems that needed to be handled such as buffering data in the sdram (design a sdram memory controller), research and implement image filters and debug why the camera image sometimes got corrupted (the connection cables were too long).
Almost all of these problems would have been gone by instead connecting an USB-webcam to my PC and utilize the openCV library.