Panel moderator Desmond Kirkpatrick, senior staff CAD engineer at Intel, opened by citing various conference papers that either reflect the "chicken" or "ostrich" point of view. As in the nursery rhyme about Chicken Little, the character who believed the sky was falling, today's "interconnect Chicken Littles" are predicting disaster, Kirkpatrick said.

Kirkpatrick cited a 2003 ISPD paper that predicted that 70 percent of all cells will be buffers by the 32 nm node, if present trends continue. Yet like the giant birds who stick their heads in the sand when frightened, interconnect "ostriches" appear unconcerned, Kirkpatrick noted. "From the Chicken Little point of view, the ostriches are in deep denial," he said.

The 2003 ISPD paper was cited by the panel's leading "Chicken Little," Prashant Saxena, staff CAD engineer at Intel Labs. "Exploding buffer counts will break today's IC design paradigm," he said. "All realistic scaling projections encounter this problem."

There aren't easy solutions, Saxena said. Designers can shrink block sizes, but that just pushes the problem up to the chip assembly level. Designers can use fat wires, but that causes routing congestion. "The problem is here to stay," he said. "We are going to have a huge number of repeaters and we will have to learn to deal with them."

Pete Osler, senior engineer at IBM, said that he and the other IBM designers he's spoken to are ostriches. "We have problems right now we're having trouble solving," he said. "Designers can't even think about tomorrow's technology problems."

Osler said that buffers are an "obfuscation of logical function" that cause problems with in-place optimization and engineering change orders. Further, they're power-hungry. And then there's the looming problem of manufacturing variations. "Everyone I've talked to is concerned, and having more buffers in long routes mitigates that problem," he said.

Osler said he'd like to push the buffering problem "as deep into the process as possible," so engineers don't have to deal with it up front. He called for a "virtual buffer delay calculator" that operates as if buffers are already in place. He said IBM is considering voltage islands with flyover buffers, and hoping EDA research will help support that option.

Lou Scheffer, Cadence Design Systems fellow, ridiculed the notion that chips will ever get close to 70 percent of cells taken up by buffers. He compared the "Chicken Little" approach to buffering to overblown predictions of a Y2K crisis. "Yes, buffering is a real problem, but there are also solutions," he said.

Scheffer said that designers can optimize the use of buffers they have, minimize the need for long-distance communications, and adopt schemes in which long-distance communications doesn't take so many resources. There are architectural changes that can help, he said, like using more parallel independent units.

"Engineers are not completely stupid. They won't blindly follow the past," Scheffer said.

Dennis Sylvester, professor at the University of Michigan, noted that buffering is becoming a serious problem from a power standpoint. A significant portion of on-chip leakage can come from inverters and buffers, he said.

But there are new ideas, he said, like static pulsed busses as an alternative to CMOS repeaters. These busses, he said, can offer improvements in speed and power compared to traditional busses. Another possibility is "smarter repeaters" that can sense a transition early, and pass a locally-stored next state on immediately. This may result in a need for fewer repeaters.

Surrounded by ostriches, Saxena had a question: where will the EDA tools come from to support all these proposed architectural changes?

"The EDA industry is solving today's problems tomorrow," Saxena said. "For designs that tape out five years from now, the CAD solutions will still stick to today's methodology."

Osler also had a plea. "We need an out of the box buffering solution for next technology generations as quickly as possible," he said.

Although panelists had varying degrees of optimism or pessimism, all seemed to agree that changes in chip architecture will be needed soon, and that EDA tools must develop quickly to support those changes.