Re:How FPGAs work, and why you'll buy one (2013)
by nickpsecurity on Friday March 18, 2016 @01:36PM
(#11313440)
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.
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. ;)
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. ;)