Embedded Systems: Programmable Logic -> Programmable-chip methods get fresh look

This new breed of device promises not only the lower chip costs of the full ASIC approach, but also gives designers back the "wiggle room" they had with traditional board-level designs. Yet the technology also presents daunting challenges that will force engineers to rethink programmable methods, tools and operating-system environments.

Contributors to this week's Focus section examine the issues involved, including software development and debug for various device combinations-especially those in which the CPU, ASIC and FPGA co-resid e on the same chip. Also explored are problems relating to software debug and OS selection when the processor architecture can now be adapted to the application.

"For board- or module-based embedded designs, the embedded designer always knew that there was the option to change things relatively late in the game, especially with regard to hardware components," said Ralph Zak, vice president of marketing at Adaptive Silicon Inc. (Los Gatos, Calif.). "With a full ASIC SoC [system-on-chip] design, much of that flexibility was eliminated. After a certain point you were committed, and the only way to fix anything was to wait until the silicon was produced and see if it worked or if a workaround could be incorporated into the software. If not, it was back to the drawing board and the expense of another design cycle and another roll of the silicon dice."

The programmable option opens up the design process all over again.

With the impressive boosts in clock rate and density afforded by the n ew 0.2- and 0.15-micron process technologies, makers of field-programmable gate arrays, complex programmable-logic devices (CPLDs) and a new breed of configurable-computing devices face a bewildering array of high-density solutions. For example, there are microcontrollers with FPGA/CPLD arrays resident on-chip to let designers implement the peripheral functions they want. Also, some new SoC methodologies implement the core processor in an FPGA surrounded by a standard ASIC design. Moreover, there are FPGAs of sufficient density and speed to allow a complete design, from the microprocessor to all of its peripheral functions, in a single system-on-a-programmable chip.

Altera's Dave Greenfield and Anna Chiang say programmable SoCs will revolutionize microprocessor design. Step one: Take down the hardware/software walls

But developers that expect to jump onto this new wave of embedded-computing alternatives will have to do a lot of rethinking. So will FPGA hardware and software vendors, which need to appeal to a broader range of potential customers than they have traditionally reached.

According to contributor Scott Hauck, associate professor of electrical engineering at the University of Washington, Seattle, there are several potential roadblocks to the increased use of system-on-programmable-chip methodologies. One is finding the software tools to make the transition between FPGAs and traditional ASICs, if need be. Also needed are hardware development tools that are easy to use for the majority of embedded designers, who are more comfortable with the serial programming nature of traditional languages than the parallel-programming requirements of languages like VHDL. Another item on the to-do list is operating-system environments that can be retargeted to sp ecific hardware platforms; and software development tool chains that are optimized-or can be-for each customized variation.

Hauck said the FPGA Conference, held last week in Monterey, Calif., normally focuses on improving the basic hardware tools: increasing density, speeding execution and developing more accurate mapping tools. But this year, he said, there was greater awareness of other issues relating to usage.

The main panel was titled "Is a marriage in the cards for programmable logic, microprocessors and ASICs?" "What is occurring to everyone in the programmable-logic market is that if this marriage takes place, it will require significant changes in the way we do things," said Hauck. "The challenges of reconfigurable systems are unlike those of other systems."

For starters, he said, "unlike ASICs they have a much more restricted interconnect, which dictates much different optimization goals." Further, "their fine-grained parallelism and low-level programmability are radical departures from the realities of standard processors. While there has been significant work on software tools designed specifically to optimize reconfigurable systems, there are many issues in the development of the hardware and software for such systems."

Another challenge, Hauck said, lies in mapping software, which requires tools far different from the hardware compilers and CAD algorithms typically used in ASIC-based SoC designs-partly because of the constraints that FPGAs impose, but also because of the types of users the high-density FPGA offerings hope to attract.

"If reconfigurable systems-on-chip are to achieve high acceptance in the embedded community, these formats must support input formats and methodologies familiar to software programmers, including C and other standard software languages," Hauck said.

"Hardware languages such as VHDL and Verilog are essentially parallel-programming environments," he said, "while the languages, tools and techniques used by most embedded -software developers are sequential."

Other than a radical reeducation effort, Mike Kafkowski, general manager of the embedded-software division at Mentor Graphics Corp. (Wilsonville, Ore.), believes high-level hardware programming environments are needed where such differences are masked. To this end, device makers are developing tools of their own. Altera Corp. (San Jose, Calif.), for example, has created tools to abstract implementations of its Excalibur family of devices to a much higher level.

"Programmable system-on-chip solutions will revolutionize the way designers do microprocessor-based designs," said contributor Anna S. Chiang, director of marketing for Altera's Excalibur business unit. "What is essential to the emergence and adoption of these new [devices] is providing a complete and integrated hardware and software solution that enables hardware design, system-software development, system generation and IP [intellectual-property] block integration, modeling and debug in a cohesi ve and easy-to-use design environment."

Work is also under way at major university laboratories to automate the process of developing and adapting processor architectures and instruction sets for use in configurable and programmable-logic environments. A surprising number of researchers at the Compilers, Architectures and Synthesis for Embedded Systems (Cases) conference last December focused on developing high-level methodologies, said conference chairman Krishna Palem, director of the Center for Research on Embedded Systems and Technology at Georgia Institute of Technology (Atlanta).

For example, researchers from Thomson-CSF and INRIA, the French research institute, have created a development system they call Prompt to map telecom applications onto SoC devices from specifications defined at a very high level.

Another effort, a flexible-instruction processor, is described in detail later in this section by researcher Wayne Luk at Imperial College in London. Using a high-level parall el language called Handel C, Luk and his colleagues describe in software various Java virtual machines and MIPS architectural variants, which can then be expressed in hardware form on high-density FPGAs.

Rather than use traditional high-level synthesis tools to generate hardware, contributors Timothy Callahan and John Wawrzynek, at the University of California, Berkeley, opt for automatic software compilation of specific hardware functions.

In the commercial world, vendors and developers alike are being cautious in their strategies for generating software-development tools and OSes for configurable-processor designs. Most efforts use open-source tools such as the GNU tool chain. That's the tactic Altera takes, for example, in its Excalibur line. To sidestep the issue of OS support, most reconfigurable-processor efforts depend on the availability of hard- or soft-core implementations of standard processors such as the ARM or MIPS architectures, which already have OS and tool support.

Two useful options here are Linux or the more recent open-source eCOS operating system supported by Red Hat Inc., said Kim Knuttila, vice president of engineering services at Red Hat (Durham, N.C.). "Both alternatives allow some customization: Linux by allowing components to be removed, and eCOS [by letting] the developer start with a bare-bones real-time kernel and build up in a very fine-grained way to get the features the architecture requires," Knuttila said.

However, Palem of Georgia Tech pointed out that something more dynamic and flexible will be needed as configurable-processor alternatives begin to catch on. Companies are assuming developers will not want the degree of customization that will be possible with this technology, he said. But the market dynamics are not on their side. "We will need some better methods for creating the companion tools and operating systems to go with the customizable variations that will be possible," said Palem.

Researchers have come up with a variety o f ways to get there, he said. One approach, detailed here by University of Michigan researchers Shighe Wang and Kang Shin, uses finite state machine techniques to build embedded software by selecting-and then connecting as needed-components in an asset library, specifying their behaviors and mapping them to an execution platform.

And Jurgen Teich and Ralph Weper of the University of Paderborn, Germany, have created a joined architecture/compiler environment that can generate implementations of architecture-specific instruction-set processors automatically; the instruction-set simulators and corresponding compilers use abstract state machine methodology.

"If the diverse consumer-oriented markets now emerging are any indication, developers may be asking for completely reconfigurable processor alternatives-and the software tools and OSes to support them-more quickly than we expect," said Palem. "We had better be ready."