System Design

Building a Multimedia Video Conferencing Chip with a Synthesizable PCI Core

Harris learns that the test environment is almost as important as the core.

by Scott Brandt

The Multimedia Products Group of Harris Semiconductor recently demonstrated a chip set at the Spring Comdex in Atlanta that implements the ITU H.320 Video Teleconferencing Standard. The chip set is designed to work with a host CPU--typically an x86 processor running Windows 95--over the PCI bus with associated software. The chip set and software combination can be used to develop an add-in PCI board for PCs to provide high-quality video conferencing, with up to 30 frames per second of full CIF video resolution and several audio decoding options, including a robust echo cancellation algorithm.

Because one of the key features of this product was to fully support many high- and low-data-rate PCI bus transactions, we were faced with two implementation choices for the circuit that was to manage all of those transactions: design, code, and debug the PCI bus interface from scratch (which meant a steep learning curve and possible delays in the project) or license a synthesizable PCI core and modify it to meet our design needs.

One consideration in making our decision was that most of the members of our newly formed design team lacked recent ASIC design experience, and that was a significant risk factor, especially since the device was expected to be very large and complex. Furthermore, our project schedule assumed success on the first-pass silicon.

Also very important was the fact that at the time none of the designers on our team had much experience in working with PCI. In fact, the sum total of our team's PCI experience came from receiving several copies of the PCI specification from joining the PCI Special Interest Group and from sending a couple of people to the Annabooks PCI course. We realized we needed help not only in the PCI implementation process, but also in making certain our design complied with the PCI 2.1 specification.

After researching our options, we decided to license a Virtual Chips core from Phoenix Technologies. They provided us with the PCI synthesizable core and the 2.1 compliance suite and test environment. One important thing we learned as the circuit design progressed was that the test environment was almost as valuable to our project's success as the PCI core itself.

Gateway processor We implemented the core on a chip called the Audio-Link Processor, the Harris HMP8201, part of a video conferencing chip set that implements the H.320 video conferencing specification for the ISDN telecommunications network. The processor is the gateway for all video and audio data in the system. It also provides control back and forth between the host CPU and all the interfaces that the video teleconferencing board supports--for compressed video data, uncompressed video data, compressed audio data streams, the telecommunications port that goes to the ISDN interface, an I ² C interface--and it serves as the data manager and scheduler for all devices requesting access to the host, other PCI boards, or system memory (see Figure 1).

Beyond those basic functions, the design was ambitious in many other respects. To manage all the video and audio data simultaneously, the bus master arbitration logic included nine bus masters tied to the bus master interface of the PCI core with 4 kbits of decoded target memory space that provided control, status, and data paths as target addresses on the PCI bus. Because of the high number and variable data rates of the bus masters, our system design team had many discussions of theoretical and practical PCI access time latency and prioritization of the various data flows. Even with those ongoing concerns during the circuit development, we were able to adapt the core to meet our specifications, and with the test environment we were able to resolve all the expected timing issues before going to silicon.

Figure 1. The HMP8201 Audio-Link Processor includes multiple bus masters tied to the bus master interface of the PCI core.

Critical aspects Two key aspects of the project were designing and developing the bus master arbitration scheme and making sure that all asynchronous data coming into the device was managed properly, with no lost data transactions. The latter was critical to the overall project because even if all the other functions in the chip set worked, if we couldn't send data back and forth on the PCI bus, the project would be a failure.

Because of the versatility of the test environment, we were able to easily find procedure calls and tasks and modify them to work with our chip interface. We wrote a C program interface that incorporated a majority of our test and verification data. Then we used Unix socket files to support an interface for messages and data to be passed back and forth between C and Verilog during the system simulations (see Figure 2). The C task calls had Verilog tasks supplied by Virtual Chips buried inside them for emulating other targets and masters on the PCI bus. Extending Verilog to allow C test programs, along with our relying on many of the existing Verilog tasks from Virtual Chips, made the simulation and test process work out very well.

The process of integrating the PCI core into our overall design went very smoothly. I attended a two-day class at Phoenix's headquarters in San Jose right after we bought the core to get an overview of the core and the test environment, and I received many useful PCI hints. It also helped a lot going through the code with some of the Phoenix developers and, in informal discussions I had with the applications staff while at their site, I gained an understanding of the process of integrating their core into our design. The sessions also covered details on extending or adding our own masters and targets to the test environment.

We only had to make one major change to our implementation plan early in the project. Initially, we purchased an asynchronous PCI core that included both target and master FIFOs, but as we explored the complexities of our application further, we ended up swapping out that core for one with no FIFOs, which therefore assumed synchronous data transfers. Phoenix Technologies provided us with excellent support when we made the decision to switch to the FIFO-less version; we contacted our account representative and within 48-hours we were running simulations on the new core in our design.

In the code we wrote for the synchronous core, the application-side circuitry manages all data FIFO synchronization and control synchronization back and forth between all the interfaces and the core. This setup was necessary because each of the nine bus masters needed its own custom FIFO for data buffering. In the uncompressed video path, for example, the data rate can be very high in some modes, so we designed in a 256-word-deep FIFO for that path. Many other paths supported substantially lower data rates, requiring FIFOs only 2 to 8 words deep. Phoenix provided Synopsys script templates "as is," and they were used as a baseline for the synthesis scripts that we developed and used to create gate-level netlists of the chip.

Figure 2. In the simulation environment for the HMP8201, the Verilog HostCommands task accepts PCI commands supplied through Unix sockets from test programs written in C.

High gate count One of our big surprises in the implementation phase was the number of gates needed for the PCI portion of the chip. The high gate count happened mainly because the FIFOs we needed grew a lot over the course of the development. Because of PCI latency and system arbitration concerns, we wanted to make sure that no data was lost anywhere in any of the buffered data paths, so that we were probably conservative in sizing the depth of the FIFOs.

When we finished the project, the chip was fairly large by Harris standards. In addition to the PCI interface, the HMP8201 included two Oak DSP cores for audio data processing and some associated compiled RAMs and ROMs to support them. The final device count was 4.2 million transistors, the biggest chip to date that Harris Semiconductor has designed. The entire chip had about 180,000 gate equivalents, with an additional half megabit of total memory space. Of that number, about 75,000 gates made up the PCI core, the FIFOs, and all the logic that we added to manage all of the interfaces. The PCI core itself was about 15,000 gates. The circuit processing was done at a foundry with a 0.5-µm, three-level-metal CMOS process, using a standard-cell library and memory compilers developed at Harris.

For some of the chips in the system chip-set development, we used Ikos's NSIM for simulation acceleration, but the HMP8201 was functionally verified with Cadence Design Systems' Verilog-XL alone and Synopsys 's DesignTime was used for static timing analysis, then we went straight to silicon with no hardware modeling or breadboarding. All the PCI functions worked on the first pass, and all performance measurements were within the windows predicted by our timing analysis. In other words, the end result was that the Audio Link Processor works in the system and we're able to do high-quality video conferencing.

The absolute schedule benefit of using a purchased core is somewhat difficult to estimate. Our experience with PCI was near zero going into the project, so we really have no benchmark to tell us how much longer it would have taken to complete the design without a synthesizable core. Beyond the time savings of starting with a PCI 2.1-compliant RTL description, however, it would have taken us longer still to have started without the Virtual Chips test environment, because we were able to structure our entire chip verification and much of our system verification around it.

Overall, we are very happy with the results of using the core, and we are already using it again to develop a new PCI-based video capture device. *

Scott Brandt is the senior principal engineer in the Multimedia Products Group of Harris Corp.'s Semiconductor Sector (Melbourne, Fla.).

To voice an opinion on this or any Integrated System Design article, please e-mail your message to miker@isdmag.com.

integrated system design  September 1997