A problem that exists for synthesis tools is that most HDLs have been created for simulation and not specifically for synthesis. Therefore, only a subset of any HDL can be used to write synthesizable code. Synthesis vendors seem to arbitrarily support only the minimum subset that gets_the_job_done. I find that this "limitation" makes the code less readable and thus less maintainable than TestBench code.

Another HDL problem is that it's easy to write nonsense code. If functional simulation doesn't find the nonsense you wind up with some very interesting hardware. BTW, formal verification won't find the nonsense either.

Sandstrom Engineering has created a program (actually a VHDL model, PreSynth.vhd) that reads a non-synthesizable VHDL file and annotates a copy of it with synthesizable VHDL (where possible). The program also flags nonsense constructs which I hope will finally make formal verification realizable. This new, annotated code is then submitted to synthesis.

Constructs like ALIAS, ASSERT, BUFFER, NATURAL, POSITIVE, rising_edge, falling_edge, and many more can now be used in your code. PreSynth.vhd substitutes a synthesizable construct in place of the non-synthesizable construct. In the case of an assert message, for instance, PreSynth.vhd places the translate_off/on pragma around the construct so that warning messages in synthesis are reduced.

Constructs like FILE are truly not synthesizable. An error message is generated:

-- ERR_001 : File constructs not supported by synthesis tools,
-- *** YOU MUST FIX YOUR CODE ***

One of the lint features of this program looks for the nonsense construct of comparing arrays of different sizes. A warning message is generated:

-- WRN_001 : Arrays are not the same size.

Good_design_practice checks include drawing attention to any outputs that are not registered.