I can see for performance. Software seems better at managing complexity if good structure is used. What example do you have where software is harder to develop and test than hardware due to complexity?

> Software seems better at managing complexity if good structure is used.

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.

I still doubt it's better at reducing complexity because that stuff is horrific in RTL. I can express it with a parallel programming language with ease. A parallel programming language with macros and automatic placement onto cores/DSP's would be even easier. Describe it, compile, and it probably runs. With hardware, I'm looking at several more layers of verification, testing, material checks, and so on.

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. ;)