3 ms·

> 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

by sklogic 11y ago

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

nickpsecurity 11y ago
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 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 http://www.figuk.plus.com/4thres/systems.htm Forth interpreter in Ada (1985) http://www.forth.com/archive/jfar/vol3/no2/article7.pdf 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. ;)

by sklogic 11y ago

nickpsecurity 11y ago

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 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 http://www.figuk.plus.com/4thres/systems.htm Forth interpreter in Ada (1985) http://www.forth.com/archive/jfar/vol3/no2/article7.pdf 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. ;)