SoC: Codesign and Test -> Flow is shaky for programmable SoCs

To illustrate that point it's useful to examine in detail all aspects of a typical FPGA SoC design flow: processor selection and design, verification, synthesis, floor planning, routing and debugging. We use as an example an actual design of a Voice-over-Internet-Protocol (VoIP) phone with a Web-based GUI for control. The target clock frequency was 25 MHz.

The design uses an Altera Apex20K400 as the programmable platform because it's the largest FPGA at present. In addition to the microprocessor, the system also included some peripherals and an interconnecting bus. The microprocessor was by far the most complex part of the system to implement.

It's extremely important to thoroughly research your processor and FPGA selection up front. The advantages offered when configuring your own application-specific processor are very powerful. However, this capability can also seem somewhat overwhelming, especially if you lack experience with microprocessor architecture and design. Fortunately, there are alternatives that allow engineers to tailor their processor without the headaches of a "from-scratch" design. These alternatives are offered by processor IP companies, which make tools that abstract processor architecture from the underlying design. Once your processor is configured, these to ols automatically deliver a fully designed and verified processor within approximately two hours. The VoIP design example discussed here uses just such a tailored processor scheme, based on the Tensilica's Xtensa processor.

After the selection and configuration of a processor, the rest of the system design is relatively straightforward. The next step is to select a bus, a memory architecture, peripherals and I/O. With the system architecture completed, it's time to move on to the implementation phase of the project. In the VoIP design example, Verilog was chosen as the RTL. Once assembly of the system RTL was complete, the next step was to verify correct

operation in simulation before programming the FPGA. Many FPGA designers skip this verification step since there is very little risk in programming an FPGA. That approach works in smaller systems, but is often unworkable when trying to debug large SoC designs.

The first step in verification is to construct a system-level testbench. T his testbench includes the portion of the design contained within the FPGA as well as any peripherals or memories outside the core. The inclusion of memories external to the FPGA is especially critical if the processor fetches program or data from these memories, as is often the case. The task of building the system testbench was made much easier because of an example system model that the processor vendor provided with their core.

After synthesis, Altera's Quartus software was used to route the design in less than two hours. The routed design reached the performance goals of 25 MHz and 45 percent utilization. Key to this effort was the floor-planning tools of the vendor, the ability to group logic. Although 25 MHz may not seem fast, it was more than adequate for this design. The reason was processor efficiency. Because the processor was custom tailored to the application, it didn't need a clock rate as high as might be required by a conventional processor. The application was able to run an operatin g system with a full TCP/IP stack, G.711 vocoder and GUI Web server with cycles to spare for future enhancements. That's impressive processing power for a 25-MHz clock rate.

After the layout phase, the designers proceeded to program and boot the design. It was soon discovered that in a device with hundreds of thousands of gates, a low-level approach was not practical. Using the Xtensa on-chip debug (OCD) module that the designers added to the processor during configuration gave them all of the capabilities of an in-circuit emulator. With features such as single step, register examination and modification, the designers were able to systematically debug the software and system design. Since the OCD feature is optional, it could be removed after debug, thereby saving FPGA resources for the final design.

In the end, the example design resulted in a VoIP telephone on a single FPGA within three weeks. The design ran at the targeted 25 MHz and was able to support the desired Web-based GUI and full TCP/IP protocol stack. The parts of the flow that worked well were floor planning and routing of the FPGA.

The flow needed modification for synthesis, verification and debugging. In these cases, designers were able to overcome difficulties through the use of third-party tools and some innovative use of the processor as a system debugging tool.