Designers urged to bridge the hardware-software divide

Software engineers look at algorithmic or real-time models of applications, while hardware designers are concerned about microarchitectures, Magarshack said. They exchange design data, but at the end of the day "they are different and will remain different," he sa id.

Cisco Systems Inc. follows a "traditional" approach to design, said hardware engineer Sean Smith. "Hardware and software teams meet, define an architecture, and create a model," he said. "Once we agree on hardware/software partitioning we tend to go our separate ways, and then meet some time in the future."

Smith said Cisco develops a "tremendous amount of software" during verification, but there's little reuse beyond low-level diagnostics. He said that separate groups write verification code, diagnostic code, device drivers, and applications, with each following their own methodology.

Room to grow

Shrenik Mehta, senior engineering manager at Sun Microsystems Inc., said his company has had separate hardware and software teams for the past 15 years. Although there's regular communication and interaction, there is "some room for us to grow," he said.

But Ian Phillips, principal staff engineer at ARM Ltd., said that hardware and software worlds are actually moving closer together. "It's hard to define RTL as being different from software," he said. "Hardware and software are different ways of implementing logic, that's all. The design methodologies should be the same."

Axel Tillman, president and chief executive officer of EDA startup Novilit Inc., said that hardware and software are "wrongfully" separate today. "We need a new type of engineer who can combine hardware and software," he said. Following the philosophy of his company's AnyWare product, Tillman called for a new methodology that lets designers delay hardware/software implementation decisions.

Panelists also looked at points of interaction between hardware and software teams. Magarshack said this interaction occurs in three phases. First, there's an architectural definition stage with strong hardware/software interactions. Secondly, there's a development phase with weak interactions. And finally, there's a fast prototyping stage with very strong interactions.

Smith said Cisc o's design teams tend to partition hardware and software too early in the process, which "limits our options." He also said there's been "resistance" to the concept of hardware/software co-verification.

Magarshack said his company is a strong believer in emulation and prototyping platforms, but ARM's Phillips said the industry must do better. "This isn't the right way to go forward — it doesn't scale," he said. "You can't make a 100-times faster emulator or a 1,000-times faster simulator." What's required, he said, is a methodology change in which the focus shifts from testing to "designing it right."

Panelists agreed that a common language for hardware and software design, especially a universal language, is not on the immediate horizon. Novilit's AnyWare product does provide a common language for hardware and software, but it's aimed at one domain — telecommunications. "We don't believe one universal language will solve every problem. You've got to target one area," said Tillman.

A non-ambiguous, formal property language is a "holy grail," said Magarshack, but he said he doesn't see it happening any time soon. He said STMicroelectronics has had some success with the Esterel protocol language, and that software engineers make use of Matlab from The Mathworks Inc.

Smith said that English is a "very poor specification language" that results in a "staggering" misinterpretation of data. "We are inching our way towards the use of assertions in verification," he said. "Being able to formally specify the behaviors of interfaces is tremendously valuable."