Richard Goering

EE Times

(03/28/2006 8:45 PM EST)

SAN JOSE, Calif. — The best designs are simple designs, and the key to successful silicon intellectual property (IP) design is keeping code simple, said Synopsys fellow Michael Keating at the International Symposium on the Quality of Electronic Design (ISQED) here Tuesday (March 28). But that`s a complicated matter, he said.

``Ultimately, the quality of a design depends on the simplicity of its execution,`` Keating said. ``The art of design is the art of making the complex appear very simple.``

Keating outlined two ``basic rules of design`` that he said are often violated in practice. One is that if it`s not tested, it`s broken. Another is that if it`s not simple, it will never work.

Keating does IP development work at Synopsys, and during the past year he decided to work on some test chips to implement IP, similar to what customers would do. It was an ``eye opening experience,`` he said.

The problem with IP-based system-on-chip (SoC) design, Keating said, is that engineers who write applications know little about the device drivers or real-time operating system, and engineers who design the chip didn`t design the third-party IP. ``Nobody really understands what`s going on,`` he said. ``Lots of people understand parts of it, but nobody understands the whole design.``

Keating was implementing IP that was described in over 2,500 pages of documentation. He used the documentation as a reference, but didn`t read all 2,500 pages. When he ran into problems with signals that weren`t being generated, he sought help from Synopsys applications engineers, who didn`t know enough about the chip design to solve his problem. When he read the actual code, Keating could see why the signals weren`t generated.

Referring to the code, Keating said, was faster and more accurate than reading the documentation. Further, the documentation was missing key information. ``Documentation can be a reference, but it`s not the solution to the communications problem between the IP provider and the customer,`` he said.

Keating`s conclusion? ``Code is what really counts,`` he said. ``It`s what I fought my way through as I was trying to put the chip together. Code, and data extracted from code, is the core form of communication between designers in IP-based SoC design.``

But to be usable as a documentation tool, IP code has to be simple. And it takes a great deal of effort to structure simple code, Keating said. ``Code is like a novel — it`s read by many people,`` he said. ``The secret to writing a novel is rewrite, rewrite, rewrite.``

In simple code, Keating said, all structures are explicit. Simple code contains clearly perceptible patterns, a ``reasonable`` number of elements, and a regular structure. Keating said that hierarchical state machines, which have an explicit state space and structure, can have a dramatic effect in improving the readability of code.

But there`s a time to go visual, Keating said. ``You can create structure with well written code, but it`s very, very hard to see structure in code,`` he said. State machine diagrams, he noted, are ``incredibly effective`` for seeing patterns. And block diagrams can quickly identify problems that are almost impossible to figure out from code.

``Visual design input will be a key element of designs going forward,`` Keating said. But tools that generate code from drawings have had a low rate of adoption, he noted. What`s needed, Keating said, are tools that generate drawings from code. No tool does this well today, he said, but with SystemVerilog, it should be possible to extract block diagrams with minimal clutter.

What Keating would ultimately like to see is a development system where code and drawings are linked together, and a change to the code will change the diagram. ``When you`re doing IP based design, you`re always debugging somebody else`s code,`` he noted.