programming languages : C,RTL, etc

Languages often constrain our thinking.

As the programming folks are running into a brick wall trying to parallelize C programs, hardware architects are running into a brick wall trying to capture design specifications and reduce them to synthesizable code. We can do the job just fine if the algorithm happens to be an instance of something RTL code naturally describes—that is, a data path or a synchronous state machine. Otherwise, we are in for a difficult, manual translation process with no guarantee of a positive result

And just as many programmers tend to think of algorithms in terms of C programs, many architects and designers tend to think of algorithms in terms of a sequence of synchronous registers separated by clouds of asynchronous logic. We've forgotten—if we ever knew—that such structures are one set of constructs that was once particularly useful to the computer industry, not a general description of the class of all algorithms. And that is severely hampering our attempts to elevate design to a level of abstraction above RTL. The problem is too hard because the implementation language is too specific, or perhaps because it is specific to the wrong constructs. It's an interesting view of the issue

original source : here