Reconfiguring Design -> Development environment crucial for PLD-based processors

Development environment crucial for PLD-based processors

Development environment crucial for PLD-based processors
By Matthew Mahr, Product Marketing Engineer, Excalibur Business UnitMartin S. Won, Senior Member, Technical Staff, Altera Corp.,San Jose, Calif., EE Times
February 8, 2002 (12:58 p.m. EST)
URL: http://www.eetimes.com/story/OEG20020208S0061

A programmable-logic device-based processor offers exactly the features that the application needs. Once the processor is defined, the designer "owns" the architecture, and need never worry about availability. Software prototyping can begin immediately, because the PLD and embedded processor are available immediately. Custom hardware logic surrounding the CPU can be integrated day by day, and at each stage, software can be tested and issues resolved. In addition, the software team can make architectural suggestions to improve code efficiency and processor performance, and these software/hardware trade-offs can be implemented midway through the hardware design process.

We realized early in the design of such an environment, ultimately named SOPC Builder, that the tool flow to create a Nios processor-based system would be as important as the processor itself. As newcomers to a mature field, we would have to convince embedded designers to accept a new processor and a new design flow.

Our first uncertainty was whether they would accept a new instruction set. This issue was resolved by the fact that C had become a de facto standard for embedded design. Altera worked closely with Cygnus (now owned by Red Hat) to define an instruction-set architecture for which Cygnus could easily port and optimize its GNUPro Toolkit, a standard GNU environment that most designers feel comfortable with.

The issue of design flow became the bigger challenge. Off-the-shelf microcontrollers offer a well-defined set of peripherals and the manufacturer assumes the burden of integrating them with the processor. Configurable processors offer complete freedom, but could potentially create more work by forcing the designer to create the bus architecture, define the memory map, create interrupt logic and assign interrupt priorities. We believed that the benefits of SOPC Builder would attract embedded designers, but only if the additional requirements were minimal and posed low risk.

We decided the best way to ease the designer's burden would be to collect all the low-level details relating to the processor subsystem into a single tool. In the design of our tool we kept two things in mind. First, it must provide an intuitive graphical user interface (GUI) for designers to add and configure exactly the peripherals required by their system — including memory, custom peripherals and intellectual-property modules. Second, it must automate the task of system integration so that the designer is not stuck with "the manufacturer's job" of defining memory maps, interrupt control and bus architecture.

The GUI was the larger challenge; it needed to be intuitive, while allowing the user to configure complex systems. This includes defining systems with multiple bus masters, bus arbitration and direct-memory-access control, in addition to offering software and operating-system integration.

< /CENTER>

We arrived at what we humorously refer to as the "pool-table interface" to automate the process of adding components to the system. The user selects from a pool of available peripherals listed on one side of the development-environment window. The peripheral then appears in the table of components included in the current system, found on the opposite side of the same window.

Each peripheral may launch a configuration wizard, which allows the user to configure the peripheral's behavior for this system. The component-table GUI allows the user to enter a base address and interrupt priority for each peripheral.

Finally, we needed an intuitive way to connect the bus architecture and assign slave-side arbitration priorities. Our solution became the "patch panel," which resides in the middle of the development-environment window. Vertical lines represent masters; horizontal lines represent slaves. The patch panel allows the user to specify connections between master and slave peripherals and, optionally, assign weights to different masters. These weights determine how often each contending master gains access to a slave.

We designed our set of tools so that when the user clicks the "Generate" button, it generates each of the hardware components as well as an on-chip bus architecture to connect them, arbitration and interrupt logic. The program also produces a simulatable register-transfer-level description of the system as well as testbenches tailored to the specific hardware configuration. Optionally, it also synthesizes the hardware system into a single netlist.

With these elements in place, we felt we had automated the hardware-generation process to an initially satisfactory degree, but we also wanted to address the needs of the software designer. Using the information collected during the design process, we designed the environment to generate both C and assembly header files that define the memory map, interrupt priorities and a data structure corresponding to the register space for each peripheral.

This automated generation helps the software designer to deal with the potentially changing nature of the hardware; if the hardware changes, the header files are automatically updated. Also generated is a custom library of C and assembly routines for each peripheral that exists in the system. For example, if the system includes a UART, then SOPC Builder defines a C struct for accessing the UART's registers, and generates C and assembly routines that send and receive data over the UART.

After the tool was made available to engineers developing designs based on Nios, we found that many wanted to add their own components to the standard templates offered. They wanted to use it as a design tool for integration and reuse of their own custom modules, not just to connect a processor to standard peripherals that SOPC Builder offers. To meet this demand, we opened the hardware and software interfaces to the internal flow, allowing third parties to author their own SOPC components as wel l as using the existing templates.

We redesigned the development environment around an open, extensible standard for generating and connecting custom modules, which we referred to as "components." Under this standard, we defined a system-configuration file format called a System PTF file. This file is the recipe for the system; it defines the necessary details for SOPC Builder to generate a complete system.

We also defined a file format for the information specific to a component, called a Class PTF file. The Class PTF contains the necessary details for SOPC Builder to both configure and generate the component.