Reconfiguring Design -> Reconfigurability: Designer's key strategy

Reconfigurability: Designer's key strategy

Reconfigurability: Designer's key strategy
By Bernard Cole, EE Times
February 8, 2002 (11:47 a.m. EST)
URL: http://www.eetimes.com/story/OEG20020208S0040

A wide range of reconfigurable design options from microprocessor vendors, FPGA companies and researchers can help developers of net-centric appliances find the architecture with the right mix of performance, power dissipation and features, even as they struggle to hit a market window that has, over time, only gotten smaller.

Alternatives run the gamut from FPGA-based "systems on programmable chips," into which complete microprocessor architectures can be inserted, all the way to reconfigurable, tailored, synthesizable and adaptive processors.

"While reconfigurable and reprogrammable logic has always played a role in embedded developments, it has in the past never been at the center of the design, " said Paul Master, vice president and chief technology officer at Quicksilver Technology Inc. (San Jose, Calif.). "It was always on the periphery, where a specialist on the team, trained in ASIC or FPGA methodologies, would be assigned to develop a f unction in silicon that simply was not available in a standard microprocessors or logic."

Now that circuit densities are in the million-gate range — the point where entire systems can be implemented on a single chip — such reconfigurable methodologies have become a central strategy, Master said.

But even if a developer picks the technology alternative that is right for a given design, there is one more "gotcha" to overcome: software support. Just as important is a related problem facing both the hardware and the software developers on a project: how to determine what functions to incorporate into hardware and which into software, when to do it and how.

As contributors to this week's In Focus section indicate, addressing this last problem is on the mind of virtually every developer of a reconfigurable, adaptive, reprogrammable circuit design methodology. The result is an industry still divided over the best language and programming methodology for capturing system-wide functionality. One side has argued for a single grand, unifying language, while the other has advocated a heterogeneous approach.

According to Matthew Mahr, product-marketing engineer with the Excalibur Business Unit of Altera Corp. (San Jose), Altera realized early in the development of its FPGA-based system-on-programmable chip (SOPC) that everything would depend on devising a design methodology as similar as possible to the traditional top-down, sequential-programming schemes of embedded-software development. "It was very clear that the viability of SOPC depended as much on design flow as it did on the individual hardware components or processors," Mahr said.

Such a solution, said Quicksilver's Master, involves a cultural paradigm shift having to do with how software developers approach a design vs. the way hardware developers using ASIC and FPGA methodologies do it. Where embedded-hardware and software developers have focused on defining the overall problem and then working down to define the functional compon ents needed to implement the solution, he said, the process is exactly the opposite for ASIC and FPGA designers.

Hardware-based methodologies used in ASICs and FPGAs, from schematic capture to hardware-description languages (HDLs), have evolved from a bottom-up approach in which hardware functionality is developed by describing circuit structure, said Kjell Torklesson, vice president of engineering at Celoxica Ltd. (Abingdon, Oxfordshire, U.K.). To this end such approaches have focused on maintaining low-level design control.

Master said there are also fundamental differences between the way embedded developers, especially on the software side, define a problem and the way hardware developers at the FPGA and ASIC level do it. Where the embedded developer uses techniques that have grown out of 30 or more years of sequential code development in C, C++ and other languages, the FPGA or ASIC designer depends on HDL methods using parallel programming.

"There is a reason that systems developers raced away from logic-based design after the invention of the microprocessor," Master said. The MPU "forced them to spend as much or more time on hardware implementation details as on the overall design." The top-down, higher-level software development methodologies introduced with the microprocessor allowed them to get to a solution much faster.

Even in the era of multimillion-gate circuitry and systems-on-chip, it will take a lot for embedded developers to go back to the old approaches, said Celoxica's Torklesson. "Today's hardware design methodologies are computer-based interpretations of early tools such as bread-boards and logic analyzers," he said. "And although hardware design has progressed in abstraction to RTL [register-transfer level], the methodologies reflect their origins from the structural world."

However, shifting to a software-based methodology that forces hardware development at a much higher level of abstraction will benefit both sides — embedded-software developers, and ASIC and FPGA hardware developers — Torklesson said. That is because much of the work of problem definition and resolution and partitioning has already been done, so the design requires much less code and design effort.

Fortunately, said Ken Hines, vice president and chief technical officer at Consystant Technologies Inc. (Kirkland, Wash.), such methodologies are beginning to appear. They simplify the process of describing functionality in hardware through the application of a high-level approach to electronic design automation that is inspired by the software world.

Fusing software and hardware methodologies, these tools introduce three aspects of software development to the designer, Hines said: sequential-programming languages such as C or C++ for describing functionality; a design system with symbolic debugging; and libraries of predefined functions, including access to peripherals and processors in hardware via common application programming interfaces.

Krishna Palen, chief technical officer at Proceler Inc. (Berkeley, Calif.), believes a better solution is to allow embedded developers to deal with the problem as they always have — with some modifications. Rather than doing a best guess early in the process and then going back and repartitioning the design, Palen suggests shifting to a compiler-centric approach. But in place of two compilation mechanisms — one based on C or C++ code and the other on RTL code — Palen espouses a single, combined compilation step at the end of the code-development process.

With the right compilation tools, he said, a developer could determine which functions are best expressed in hardware and which in software, and then generate the appropriate output code: machine code for the most appropriate target standard microprocessor or RTL form for generation of the appropriate ASIC or FPGA.

It is still unclear which of the various approaches to combining FPGA/ASIC hardware methodologies will establish itself as a standard, said Paul Jordan, direct or of marketing at Elixent Ltd. (Bristol, England). However, he said, it is only a matter of time before every design has at least an element of reconfigurabilty.