Reconfiguring Design -> FPGAs speed audio application development

FPGAs speed audio application development
By Eric Ryherd, President and CEO, VAutomation Inc., Nashua, N.H., EE Times
February 8, 2002 (1:34 p.m. EST)
URL: http://www.eetimes.com/story/OEG20020208S0067

The field-programmable gate array technology that's available today makes it easy and inexpensive to prototype microcontrollers. The size of the microcontroller that can be implemented in a single FPGA may require some differences between the FPGA prototype and the ASIC version.

Those differences should be limited to on-chip memories to minimize risk. Performance in an FPGA is limited to about 20 MHz for a microcontroller application. Software integration and testing can begin before the hardware design is complete, which often shaves more than three months from the development schedule. The FPGA prototype can even be used for early production to achieve early market penetration.

Most microcontroller applications can be built in 10,000 to 30,000 ASIC gates and thus fit easily into either a Xilinx XC4062 or an Altera 10K100 FPGA.

For our audio application, we knew that we would only be producing a few dozen prototypes, so we were not concern ed about the cost of the FPGAs. We selected the Xilinx XC4062 in a PQ240 package. We also included an Altera 10K100, also in a PQ240 package. By populating the board with both FPGA vendors, we were able to compare the two families with the same design.

Once we added the other support logic required for the Universal Serial Bus and the audio support functions, we had a clear idea of what our prototype board needed: the IntelliCore Prototype System (IPS), which allows verification of a variety of designs, but focuses on an audio application, Universal Serial Bus (USB) speakers.

The IPS board contains both the Xilinx and Altera parts, which allows us to prototype in either of the two FPGA families. External interface components are also provided for various functions that are not provided in the digital FPGA logic.

The design team was able to take maximum advantage of FPGA flexibility to prototype a wide variety of cores and applications. The same IPS board can be configured for a USB speaker wit h an 8-bit RISC CPU, or a 1394 video camera with a 32-bit CPU or even an Intel 80186 CPU. The only difference in each case is the hardware design that is loaded into the FPGAs.

An 8-bit RISC CPU, the V8-µRISC, is the brains of the USB speaker application. The CPU core comes with various peripherals. All of the logic required fits inside of the FPGA. There is even plenty of additional space for other logic to be added as required.

We coded everything in VHDL and used a revision control system (RCS). Even the printed-circuit board for the IPS doesn't have a traditional schematic, just the plain ASCII-text VHDL file. We used a program to extract a netlist from the VHDL, which has pin-number attributes. We used this methodology to be able to simulate exactly the same design database as the pc-board is built to.

Since the files are ASCII, we were able to easily check them into the RCS. Consequently, we won't have the problem of the schematic files becoming out of date when a new revision of the schematic editor is released. The only downside to this methodology is that we don't have a graphical representation of the design.

A complete system-level simulation environment was developed in VHDL. The Model Technology VHDL simulator provided plenty of performance, allowing us to interconnect several IPS boards and simulate the entire design on a laptop PC. For logic synthesis we used Exemplar Galileo, which has excellent support for the Xilinx 4000 FPGA family. Place, route and timing analysis are all done using the Xilinx M1 tools. The synthesis and place and route tools were initially run on Sun workstations, but we have since transitioned to running those tools on both the Sun workstations and Windows 98 PCs.

For software development, we used the V8-µRISC C compiler and JTAG debugger. The V8 debugger allowed us to view the C or assembly source code and single-step or set breakpoints in the code. We still made use of a logic analyzer at various times, primarily when debugging hardware pr oblems.

While much of the design was simulated, we often found that it was simply easier and faster to debug new features on the FPGA prototype in the lab. This was especially true of software debug, due to the real-time nature of the system and the interaction with the external world. We would have needed to simulate the entire PC running Windows 98 to be able to simulate the "real" system. It would have taken months to simulate the same design that were were able to simply download in minutes into the FPGA prototype.

Simulation is critical when a specific behavior is identified in the FPGA prototype. A logic analyzer trace is taken and reproduced in the simulator. Simulation provides easy access to all internal signals and is much easier for detailed logic debugging. It is also easy to create test cases that in all probability will never happen in a real system.

In our application, we found that a big advantage of FPGAs was the high-pin-count packages used, such as a 240-pin plastic quad flat pack, whereas the final product may be as small as an 8-pin dual-in-line package. With all of those extra pins available, virtually any internal signal could be brought out to a debugging pin and connected to a traditional logic analyzer. The trick was to connect all of the extra pins to a connector of some sort to allow the logic analyzer to be easily connected, as the pins on a PQ240 are very small.

We didn't have to decide ahead of time what to connect to the debugging pins. We simply left them unconnected inside the FPGA to be wired in real-time while debugging a specific circuit.

We used a concurrent design methodology in the development of the USB speaker software. Once the hardware specification had been roughed out, the software team began coding routines to verify the operation of the hardware. The software was loaded into the VHDL simulator and testing began before any hardware existed.

The VHDL simulator worked fine when it was used to debug fairly short routines like interrupt servic e routines. However, it proved to be slow and clumsy when debugging larger routines.

Unfortunately, we didn't have a connection from our software debugger to the MTI simulator, so we were not able to simply single-step the processor in our familiar environment and see the result in a simple one-line display. Instead, we had to wade through huge waveform displays and constantly zoom in and out of the areas of interest.

To quickly focus in on software routines we were debugging, we hit upon the idea of setting various flag bits in the V8- µRISC Program Status Register when entering or leaving certain routines. This technique made locating a specific call to a specific USB interrupt service routine easy to find. The same technique also worked well in the FPGA prototype, especially for checking performance. We could easily see which routines were taking the most CPU cycles by simply displaying the various flag bits on an oscilloscope while the system was running.

During software debug in the si mulator, we identified several optimizations that would make the software easier and faster. Those changes primarily centered on where various control and status bits resided and which register they were in. By rearranging a few bits, we improved the performance of the interrupt service routines because we didn't have to mask and test various fields found in different registers.