Platform-based design still getting the kinks out

"Since this was the first instance of the architecture, we did some fine-tuning," said Augusto de Oliveira, chief architect of digital consumer systems at Philips. "We did some tweaks of the chip architecture to help with physical implementation, and also to improve or add perfo rmance, memory bandwidth and clock cycles."

As a result, Oliveira said, platform-based design did not result in a huge time savings for the pnx8500 media-processing device, although having guidelines for IP creation and interconnection certainly helped. But for future chips based on the DVP, Oliveira thinks Philips will see a 50 percent reduction in both time and design team size.

Some 60 engineers worked from 1999 to 2001 to design both the underlying DVP and the 8 million-gate pnx8500. They will receive the EDA Consortium's Design Achievement Award next week at the 39th Design Automation Conference in New Orleans.

According to Hans Spanjaart, Philips' director of VLSI engineering for digital consumer systems, the sheer size of the pnx8500 — some 32 million transistors — posed a huge challenge for electronic design automation tools. While the team successfully used some commercial products, Oliveira noted, Philips relied on its own floor-planning and test tools because the team couldn't find suitable commercial alternatives.

The pnx8500 Home Entertainment Engine receives, decrypts, decodes, converts and displays multiple video streams with different data formats. It has 70 clock domains and an operating speed of 200 MHz. It packs both MIPS and Trimedia CPU cores, an array of peripheral devices and seven analog phase-locked loops. The design was manufactured by Taiwan Semiconductor Manufacturing Co. in 0.18-micron technology, and the chip is in production today.

Embedded software was also a considerable effort, said Oliveira, adding that the total Nexperia DVP team — including hardware, software and systems people — numbered close to 300.

"More and more functionality is implemented in software, and design reuse is helping, but we still have long lead times there," he said.

The Nexperia platform predefined the processor selection. However, Oliveira said, designers can choose the most appropriate MIPS core for any given design, and for t he pnx8500, the Philips team picked a 32-bit, 150-MHz processor. The design uses a 200-MHz Trimedia digital signal processor.

Decoupled core

The platform also defines a "Level 2" interface for each IP core that decouples the core from the specifics of the bus. That turned out to be a good thing, because there were several iterations on the bus architecture. Originally, Oliveira explained, the Nexperia DVP team chose the PI bus, which was created by a European consortium. But it ran into problems achieving top-level timing closure for the pnx8500, and turned to another approach as a result.

"We discontinued the use of the PI bus and are using a combination of a synchronous and asynchronous bus to create what some of our people describe as 'islands of synchronicity,' " Oliveira said. "It causes our bus to run faster and is also going to dramatically improve our ability to do timing closure."

Philips' Spanjaart estimated that perhaps half of the 8 million gates in the pnx8500 were reused and half were designed new. IP blocks created for this chip included a memory-based scalar block and an image composition processor.

Even with the underlying platform, it wasn't an easy design project, Spanjaart said. "The design was about 32 million transistors, and it was a challenge to run on the existing tools at that time," he said. "We also had a complicated design with two different processors, over 20 IP blocks and many, many clock domains." Another complication, he noted, was the presence of analog modules on the chip.

The team used many conventional EDA tools, including Cadence Design Systems Inc.'s NC-Verilog simulator, Synopsys Inc.'s Design Compiler synthesizer, Quickturn and Ikos Systems Inc. emulators, Verplex Systems Inc.'s equivalency checker and Avanti Corp.'s placement and routing tools. A large compute farm helped with verification, Spanjaart said.

Insufficient third-party tools

But for floor planning, the team had to develop its own tools, Oliveira said. "We're currently looking into third-party tools, but at the time, they weren't available or sufficiently well-suited for the requirements here." Philips' in-house tool, he noted, has the ability to assemble blocks into "chiplets" that represent a portion of the overall design.

Late in the design cycle, the team acquired Silicon Perspectives Corp.'s First Encounter tool and used it for timing-driven placement rather than early floor planning, Oliveira said.

Philips also has an in-house tool that provides graphical control over synthesis, and uses its own design-for-test tools, Oliveira noted. These tools support scan design, built-in self-test, vector generation and links to testers.

Looking ahead, Oliveira said, the Nexperia team would like better tooling for system design, along with verification tools that can generate I/O patterns to model IP block interactions. But what Oliveira would really like to see from the EDA community is interoperability. "Fo r state-of-the-art design, we can't expect state-of-the-art tools to all be from one vendor," he said.

The EDA Consortium Design Achievement Award will be given at a luncheon next Monday (June 10) at the Design Automation Conference. A detailed interview with Oliveira and Spanjaart is online at www. EEdesign.com.