I didn’t like the perl stuff in the beginning. At least you could have used Python This approach doesn’t feel right to me. As your input language is non-simulatable, the golden reference is not the input code, but the code that it generates. It should be the other way around. I prefer typing a little more to have it that way.

However, I really like the rest for two reasons.

First, the superiority of the single clocked process approach is clearly recognized.

Second, another recommended guideline in the RMM is implicitly discarded. I’m talking about the guideline “not to mix blocking and non-blocking assignments in a clocked process”. The fact that you encapsulate blocking assignments in functions doesn’t fundamentally alter the conclusion.

Still, I believe it would be useful to bury this guideline explicitly for the following reasons:

1. Some functionality is really too trivial to warrant encapsulation in a function. There’s nothing wrong with a few blocking assignments embedded in a clocked process!
2. Removing this guideline opens the way to the full use of “variable semantics” in RTL. Although only an minority of the designers understands it, this enables elegant coding solutions and is perfectly supported by synthesis tools. In particular, a variable can become a register, or a wire, *or both* after synthesis, depending on how it’s used. What matters is the behavior of the code – as it should be.

You could also add a section on how refactoring stimulates reuse. Through encapsulation, you can easily isolate functionality that can be reused elsewhere. E.g. the DMA FSM could now be reused in other designs.
Since reuse is such a hot topic in (hardware) design, I would be interested to read your perspective on this.