Creating Corporate Standards? Beware… // Cool Verification
Cool Verification has a post that strikes close to home describing the pitfalls of corporate infrastructure organizations that try to push the tools down from on high instead of letting the people who will use those tools decide what is best.
It is a very tough balancing act because if your development team have the wrong tools it can be frustrating and time consuming as they fight with the tools instead of producing deliverables. On the flipside, a non-homogenius environment can lead to code that won't compile with different EDA tools, maintenance nightmares with essential mission-critical components written in languages no one is familiar with, and integration woes as you try to improve your schedule by re-using blocks from other projects, except now you have to run mixed-mode simulations.
One approach I liked is standardizing languages based on task:
- one scripting language for environment support (perl, python, specific shell-script)
- one scripting language for application development (perl, python)
- one language for web development (perl cgi, php, python, ruby on rails)
- one object oriented programming language (c++, java)
- one hardware description language (verilog-95, verilog-2k1, vhdl…. don't forget a common RTL coding guideline)
- one hardware verification language (systemverilog, e)
- and of course choosing a re-use framework (AVM, VMM, eRM)
No code lives in a vacuum. It will be poked, and prodded and forced to to things it wasn't originally intended to do. It will be modified long after the original author has moved on. It will be hijacked in some attempt at re-use.
Of course, for every piece of code that seems to take on a life of its own, there are numerous more who die by the wayside as they encounter the "not developed here syndrome" (because it's easier to rewrite code than it is to understand it, the counter argument can be found here). At least if the same language is being spoken everywhere in the organization there is a greater chance that the code will survive in it's new home.