Can we just agree that perception is everything? Especially in IC design?

By Dennis Joseph

Is the dress black and blue, or white and gold? Is that a rabbit or a duck?

People looking at the exact same image often see it differently. While it can be fun to argue with friends about trivial disagreements like this one, it’s a lot less fun when you’re designing a computer chip and you’re arguing with your coworkers about how the layout looks. It’s frustrating, and impedes real work getting done. (Okay, maybe arguing with people on Twitter is also frustrating and impedes real work getting done).

Chip design teams are most effective when they’re aligned on their goals, their priorities, and what they’re looking at. Because many different electronic design automation (EDA) tools are used during the product development cycle, engineers working in different parts of the design and verification cycle get accustomed to a particular tool’s environment: its default colors, its default keyboard shortcuts, and its overall look and feel, all of which may vary greatly from one tool to the next.

At the end of the design cycle, when the layout is built for final verification, signoff, tapeout, and manufacturing, design engineers from throughout the design cycle who are familiar with different design tools must work with verification engineers to ensure their layouts function as intended and designed. Even after a chip has been manufactured, the layout is reviewed again to debug discrepancies between the simulated results and the actual manufactured product.

At this point, the last thing anyone wants is to argue over what something in that layout actually is. Is this black and blue object a resistor? Or is it that white and gold object over there? Teams can finish their tasks more quickly if there is a single environment where teammates can all agree on what is what. Standardization ensures consistency, right? But it’s not just about standardization, because we all see and interpret the same thing differently. It’s also important to have tools that are customizable. For example, it’s not very helpful to standardize on certain colors if some of your teammates are colorblind.

There are also the repetitive tasks that are part of any design process. Can’t those be automated? Wouldn’t that make things easier, faster, and less error prone? Save time and resources? Win-win-win! But when you’re working in a team, you want everyone on your team to get those benefits, not just one or two people. Especially if some team members need to perform certain tasks differently than everyone else. Again, standardization where possible is a good thing, but customization is equally important.

A customizable, extensible layout tool can improve engineers’ productivity by allowing them to focus on a particular task at hand without wasting time figuring out how the tool works, or running otherwise tedious, error-prone tasks. Of course, while this sounds great in theory, the reality is that no one wants to spend all their time configuring the perfect layout tool that caters to every individual preference. Moreover, for design teams to work together effectively, there must be at least some level of standardization, based on each team’s unique requirements.

Fortunately, the Calibre DESIGNrev layout viewer offers the flexibility and control teams need to work efficiently together. Engineers can customize the interface to suit their individual preferences, and still meet the team’s standardized requirements. Full scripting access to its functionality allows engineers to build additional functionality as needed to cater to their unique requirements. Once built, it’s easy for engineers to share these custom environments with each other, and for CAD teams to deploy them across a project, increasing productivity and decreasing the time to complete tasks. If you’re interested, download a copy of our technical paper, A custom layout environment improves productivity across IC design and verification flow. In it, we discuss in more detail the benefits of setting up a custom environment, and provide examples of how it’s done. It may be just what your team needs to get its work done and get chips to tapeout faster, leaving that much more time for trivial arguments on Twitter!