Over-compex environments

One of the problems that I encountered with many of the design teams I worked with is overly-complex work environments. Somehow it seems that almost every design team gradually evolves to a situation where nobody really knows how it all works. The good teams usually identify the problem, assign someone to put some order into it, and if they are successful they will reach a situation where one person now understands how it all works; but if they are really good, they will actually reach a simple solution where multiple people can understand “the system”.

This is how to know if you are on the right track:
“The System” you have should consist of what’s installed on your primary computer (PC, Laptop, Workstation, Xterminal etc.), standard desktop, where you do your editing, where you do your runs, source control, config files .cshrc etc., directory structure, filelists, compile script, run script, queuing (lsf), where your coverage information/ log files/ block verification/ failed tests go to, and standard practices.

To add a new user should be a matter of minutes (at most), till he can successfully run tests, make a change, rerun, see wave files etc.

The run script should be generic enough, that you can:
a. Choose to run individual parts (compile only, run only) etc.
b. Work with a make-file to assure that you are only recompiling the parts that you have changed
c. Be able to output its commands to a file which you can run manually with your addition
d. “push” a new version of a tool release by simply changing a constant in a config file.
e. Be able to be modified/debugged by multiple people.
f. Be able to run regressions
g. Be able to recreate failed tests efficiently (on specific releases, versions, tags etc)


Each design group needs a skilled engineer with good knowledge of Unix/Perl, who is good with “customers”, organized and methodical to set up this type of system for them.

If people are not comfortable using the development environment (they keep complainging about the scripts), if people are not efficiently using the licenses available, if some of your users frequently waste hours on integration issues or if you have made mistakes in using the wrong versions of RTL, or testbench; I suggest you take a step back and make the change.