Hi, jnhong. Your reply is right on the mark.
I would appreciate your thoughts on a project I am doing. The process is to parse C code and execute the statements directly in a new cpu architecture. A conventional compiler generates some form of intermediate code that is then turned into sequences of target cpu instructions that take many clock cycles to execute. With a highly overlapped design using multi-port Ram that can write a result and read the next 2 operands in one cycle, the number of cycles is closer to a custom
RTL design. Also the hardware count is small so it becomes reasonable to have several dedicated to different tasks so the parallel operations increase overall performance without the complexity of multi-core.
The concept can be extended to C++/OOP although the dependence on stack allocation and garbage collection becomes a bit of a concern.
If procedural/abstract design is needed, then let's do it and not go through all the compiler complications.
Thanks for any comments and your reply.
The author asks why ESL has not been adopted more widely in design. And then proceeds to show an example that proves exactly why.
From page one: "ESL is ASIC or FPGA design and/or verification which leverages highly abstract software programming languages."
From page two: "Learning to write code for efficient hardware using an ESL design language requires an understanding of what ESL compilers do."
If designers need to know how yet another productivity tool works beneath the hood, why bother when they can just as quickly translate what's in their head into RTL? This explanation just adds yet another layer of complication to achieve the same task. There is an extra layer of automation to monitor and evaluate, and then the verification burden does not decrease anyway.
In contrast, the advantage of an Object-Oriented language like C++ is it automates a vast amount of housekeeping duties that is normally utilized in worthwhile C programs. You don't need to obsessively follow what the compiler is doing, you just need to ensure the functionality is correct. The examples in this article show how futile ESL is because you need to rewrite your code until you hit the proper pattern that pleases the compiler. We've all been there.
Until ESL compilers start doing the job of allowing highly abstract procedures to become very efficient implementations, then engineers will still need to count their bits and watch their wires. In that case, RTL is more direct and more transparent.
A mature ESL synthesis tool (also known as High Level Synthesis) would recognize all of these variant and provide several solutions from slow to fast, small to large. Modern language compilers can do these types of transforms. Think of it this way: If you can describe it methodically, then somebody can likely write compiler code to do it automatically. Still need a hardware savvy engineer to guide and evaluate the results, but initial coding can be simpler.