And then there are the error messages that come out of SystemC. You almost need another parser just to parse them. Basically they are C++ template error messages. I really can’t figure out how hardware engineers are supposed to be able to deal with them. And I suspect that many hardware folks will balk when they see their first multi-page compilation error report. I’ve found that g++ 4.x is much pickier about things than g++ 3.x was – a lot of our code is broken under g++ 4.x (ambiguous operator overloading, ambiguous this and that…).

We definitely need something else. If SystemC is supposed to be the answer, then the question was not formulated correctly.

Regarding reflection and introspection in BSV, rules, functions, modules, and interfaces are first-class data types and are completely manipulable using higher-order functions during static elaboration. The FSM embedded domain-specific language in BSV, and our recently announced “PAClib” library (Pipeline Architecture Composers) makes extensive use of this capability.

Another desideratum I’d add is “full synthesizability”, so that even very high-level models can be mapped easily to FPGA/emulation platforms, thereby exploiting their parallelism to provide, effectively, VERY fast simulation.

Getting a language accepted by a large community is another question altogether. And that’s my main rub.

We need to find a way to agree on a level of interoperability that is lower than language source code, so that language innovation can take place. If we are tied to source languages for interoperability, we will be very stuck for a long time.

Grant Martin :Something about having the profits of what are still partial monopolies gives Microsoft a lot more resources to invest in a whole host of language approaches, as well as in fundamental research.

That is true to some extent, but there is also the clear appreciation that programmer productivity and ease of use matters far more than any adherence to standards beyond the basic platform ABI and API. What “EDA” could do quite easily is to stop discussing languages for standards and rather move to platform ABI and some particular APIs. An ESL virtual machine would be great… but I guess that won’t replace SystemC any day soon.

Clearly, a lot of interesting results have emerged, and as Jakob says, it would be very interesting if there were similar moves in EDA/ESL towards better languages. However, even when the big EDA companies had some near-monopoly profits in various domains, they were not very innovative nor very visionary in really pushing design methods and fundamental tools and languages. Given the current state of EDA, I don’t see the innovations likely to come from the largest (albeit, some shrinking) companies soon.

Still, to be fair, there are some really cool things that have come out of the EDA field. Things like BlueSpec and “e” are pretty cool.