Some bad ideas refuse to die, no matter how hard you try.

That was my thought when I read the following statement in a comment to a MyHDL issue:

I think pretty much all of the MyHDL examples [in the manual] should be synthesizable.

This demonstrates a stubborn misunderstanding about MyHDL: that its primary goal is to be a synthesis language. The next sentence is even more explicit:

The reason is that folks (like me), when learning MyHDL, are going to want to type in the examples and synthesize them.

This is fundamentally problematic. MyHDL users whose first inclination is to synthesize are bound to end up with a lot of frustration. Your first inclination should be to simulate. Except for trivial experiments, it makes little sense to attempt conversion and synthesis unless you have verified your design in a test bench. The manual actually makes this very clear, in a section called Simulate first.

MyHDL is a simulation-oriented language, implemented as a library for general event-driven modeling and simulation of hardware systems. It supports a variety of tasks in the design process, not only synthesis. You can use it for architectural exploration through high-level modeling. And, most importantly, you can also use it to build sophisticated verification environments. The manual reflects all this by presenting the language in a general way, and covering its various applications in separate chapters.

In contrast to MyHDL modeling, conversion is very restricted, much like synthesis itself. This creates difficulties in the design flow that cannot be solved entirely. However, they are minor compared to the complexity of other tasks. In any case, the correct approach is to design a functionally correct model first, verified with a test suite. If code changes are required due to conversion or synthesis restrictions, you can make them without having to worry about breaking functionality. A classical case of separation of concerns.

The MyHDL approach is nothing new. It is basically identical to the approach pioneered by VHDL and Verilog. Those HDLs were designed before synthesis tools existed. Their semantics are defined in terms of their simulation behavior with no reference to synthesis.

Industrial usage of HDLs coincides with their nature. The bulk of the effort in industrial projects is in verification. Indeed, most of the progress and innovation in HDLs in the past decade is related to verification. Actually, that is how the design decision to embed MyHDL in a powerful general purpose language should be interpreted.

In light of the above, the fixation with synthesis of so many designers, even those that describe themselves as experienced, is rather remarkable. How this schizophrenic situation came about is an intriguing question, which I may address in future posts or essays.

The bottom line is that MyHDL is a simulation-oriented language. If you are not prepared to learn and use it like that, it is better to save yourself the frustration.