Lessons can be learned anywhere on earth, and we’ve accumulated a few from our international project— a 64-bit RISC processor design using silicon compilation (with 2.5 million transistors) that took two years to complete. Project teams were located on three continents: a US company provided the hardware description language; a European group (the two of us) was responsible for generating the HDL-based model that correctly described all signals on all pins for each instruction and every operational mode; and a Japanese company generated over 10 Mbytes of tests. Our team’s task was then to successfully pass these tests, after which another US company did the silicon compilation. Finally, another Japanese company did the fabrication. You can imagine the possibilities for complexity! Here are a few of the many lessons we learned.

Lesson #1: It’s tough for just one person to understand everything. A silicon compiler’s essential value is that it enables one person to fully understand a relatively complex design task; however, it’s extremely difficult for one person to manage every detail. In our case, the details were all signals on all pins for every instruction executed in each operational mode. It’s important that future HDL extensions contain language constructs to efficiently express such details!

Lesson #2: Coding rules for silicon compilation are underdeveloped. One nice thing about HDLs is that they let you adequately exploit the full parallelism at the lowest hardware levels for efficient programming. However, current silicon compilers get "confused" with too much parallelism, so the HDL programmer must serialize the description, which negatively affects programmer productivity. The solution? Develop design rules characterized by maximum parallelism yet without negative effects on synthesis efficiency!

Lesson #3: Don’t let silicon compiler warnings get you down. We’ve noticed that many silicon compilers generate correlated warnings. Consequently, a huge number of warnings results in a mere handful of coding rule violations. Therefore, the generated warnings must be orthogonalized!

Lesson #4: Be careful when naming variables. A silicon compiler shouldn’t specify how variable names are created. For example, our register variable names had to start with "r_." This can be confusing, especially of required of the HDL programmers after they’ve mostly completed their task.

Lesson #5: The environment keeps changing. The silicon compiler was fully developed by the time we started our work, but the programming rules that enabled synthesis were not. Consequently, creating rules was a trial-and-error experience. Also, the silicon-compilation design process is still lengthy, so the project requirements are likely to change during the design process. Nothing new!

Lesson #6: Testing is still the bottleneck. The first 90 percent of the project—design—was completed in six months, while the remaining 10 percent—testing—needed another 18 months!

Lesson #7: Beware the NIH problems. People who work in high tech tend to think very highly of themselves, and that characteristic caused some problems of the NIH ("not invented here") variety. When a test failed, entirely too much time was spent trying to determine who made the error rather than getting on with fixing it. The typical reaction was always to blame someone else for the error.

Lesson #8: Working on three continents is both pleasure and pain. If the phone woke you up in the early morning, you knew the call was from Japan. If the phone woke you up late at night, you knew the call was from the USA. After awhile, you learned the best time to send e-mail to get a prompt response. Cultural differences, although a source of fun, can provoke misunderstandings that create hard feelings.

Lesson #9: Time to market is still an issue. A major driver of silicon compiler development is fast time to market. However, the goal has not yet been met to accelerate very sophisticated processor-logic designs adequately. There’s lots of research room for new methodologies in the over-one-million-transistor arena.

Lesson #10: We’re always more clever after the fact! As the saying goes, "hindsight is 20-20." Looking back, it’s obvious that better planning up front would have eliminated many problems (although, unfortunately, none of the above!). Better planning would definitely have reduced the 18 months it took to eliminate the last 10 percent of errors. Also, we’re all now older and wiser, with two years’ more experience!

OUR PROCESSOR DESIGN PROJECT—with all its lessons learned—was one of life’s special experiences. During the two long years of work, one of the project team members passed away, and another one received a beautiful new baby. Sometimes, life resembles engineering so much!

Veljko Milutinovic and Zvezdan Petkovic

University of Belgrade