Overview
High Definition TV (HDTV) ASICs need to be cost-efficient. They require tight integration of ATV and DTV solutions into an ASIC. Verification challenges include dealing with new interfaces, integrating modified blocks, and the ability to manage the huge set of test suites. Tight schedules and limited engineering and computing resources weigh heavily on these projects and they also need to be addressed.

Previous approaches simply relied on adding more engineering and computing resources which is not practical. Teams need to look at verification strategy, tools and methodology and how they better integrate across the enterprise. Let's take a closer look at our design illustrated below (figure 1).

The Genesis PrVIEW HD 300 Series IC (FLI103xx) is a single-chip TV solution for products requiring superior video quality in the analog and/or digital TV for ATSC, DVB, NTSC, OpenCable and PAL markets. This solution includes a single channel HD MPEG2 decoder, flexible analog front end with an integrated Faroudja' 3D Video Decoder, high performance industry standard 32-bit MIPS 4Kec processor (250 MIPS), multi-standard analog audio decoder, digital audio decoder and post processor, three programmable multimedia processing engines (MPE), advanced 2D graphics engine, integrated HDMI/DVI receivers with HDCP support, unified DDR memory controller and a very flexible and unique Video eXpansion Interface (VXI) providing glueless connectivity to Genesis video co-processors, or a customer's proprietary video processing chip.

The solution includes next generation Faroudja DCDi Cinema' video format conversion, video enhancement and noise reduction. The level of video quality that could previously only be seen on an exclusive Faroudja Home Theater System is now available in a single-chip solution. The interfaces of the single chip ATV-DTV are also shown in Figure 1.

Verification Challenges were Many
Challenges we were up against included adding new internal buses, changes in various areas, module-level verification aspects, data paths, and the integration of verification management. Let's take a closer look:

1. Addition of new internal buses
   ATV/DTV design integration resulted in a shared memory controller. The memory controller needed to serve two clients which demanded higher bandwidth compared to the previous designs. This required the creation of a new low speed register configuration bus to offload traffic from the main system bus. Introduction of the low-speed bus (which connects to almost every block) required re-verification/regression of those blocks and changing the configuration sequences. The new bus-architecture also required re-arrangement of the address map and hence re-verification of address decoding logic.
2. Architectural changes in various areas
   The color coded diagram Figure 2 shows the modifications to the architecture.
   
   
   Figure 2 Architectural Changes
   
   

   The new features driven by customer demand included adding the ability to connect a USB device to view pictures from cameras on the TV screen. The USB connection was also needed for firmware upgrades and to provide an interface for On-Screen-Display (OSD). Also added were high quality audio with multiple channel audio inputs and outputs which resulted in the integration of the whole audio sub-system from the different design. These changes lead to the addition, deletion and modification of blocks which in turn affected various verification tasks. It was crucial to maintain the integrity of the old design while verifying new features incrementally.

3. Module-level verification
   Although this project was primarily an integration of two existing products, some new modules added to the design needed to be verified in the context of the current design. The various modes of modules needed to be validated by stand-alone module qualification verification as well as by integration testing. New modules added to this design included an Audio sub-system and a USB-AHB bridge. Since most old modules were changed, the newer versions of these modules needed to be verified. For example, the control processor CPU and video decoder cores were replaced with new and advanced versions.
4. Data paths and integration verification
   When two systems are integrated, integration verification is critical. The verification environment should re-use the components built around the sub-systems. If these two sub-systems come from two different verification worlds, re-use for chip-level verification becomes challenging. It is also required to identify what gets verified at the chip-level and what gets verified at levels lower in the hierarchy. The key technique is to abstract away from the full detail of the design, just retaining sufficient features to prove that there are no inter-subsystem interconnection issues. For example, for the feature set relating to playing digital video, top-level verification was used for playing digital video from different sources (e.g. MPEG, HDMI), while block-level verification focused on error-handling in all different modes from a specific source.
5. Management of verification process and data
   The cost of missing schedule deadlines can force teams to terminate the verification effort prematurely. Thus, ASIC design quality can become a function of verification schedule, making it critical to track at a detailed level which features are verified and which remain unverified, to make good tradeoffs between quality and schedule.
   
   The large number of DUVs and a verification team distributed between Silicon Valley, Toronto, and India necessitated standardizing our regression infrastructure. Scripts and progress-tracking schemes across the project, equipping every engineer with the ability to launch track and analyze their own regressions, while providing the verification lead with the capability to assess the progress of each of the verification sub-projects became more critical than ever.

How We Developed our Verification Strategy
From the perspective of a verification lead, a sound strategy needs to be formulated before teams in multiple sites begin work on a project of this magnitude. Here I describe the process we followed to devise a strategy that quantified the problem at a high-level.

1. Scope the problem
   Based on the architectural changes, a delete/add/modify/no-change (X/A/M/NC) matrix was identified. Table 1 shows an example of the analysis. Identification of the number of DUVs was done as the next step to identify what needs to be verified and in which hierarchy (block-sub-system/chip-level).
   
   
   Table 1: Verification resource mapped to blocks
   
   This matrix helped us to assess the verification work involved. There were options such as assigning one dedicated resource to the block which went through modifications. There were generic changes. For example, the "new bus" changed the interface to all blocks. 24 DUVs were identified for modifications in order to integrate into the new architecture.
2. Resource allocation
   Exhaustive block-level verification was required to thoroughly verify all blocks which were added or went through major modifications. The block owner would create the block-level verification environment, interface verification components, monitors and scoreboard, etc. The block owner would also write the verification plan and define coverage necessary to measure compliance to the plan and execute it to verify the planned features.

The chip was divided into two major sub-systems. One owner for each sub-system ensured that all changes in that level were intact, and the sub-system verification plan was tracked to closure. The Chip-level/System-level owner focused on the integration of the sub-system and verified the interconnectivity and data paths derived from user scenarios. Each block owner owned one of the relevant data paths at the chip-level.

The compute-farm used for simulations included a cluster with 12 machines at one location and another cluster with 10 machines at different location. Cadence's vManager and Platform Computing's LSF were used to dispatch the regression jobs.

There were two major usage scenarios for simulation licenses: at least one per engineer during development, and sufficient licenses to get the regression throughput in the later stages (peak load). To manage regressions, there was one vManager license per site. When several engineers needed to debug concurrently, licenses became a bottleneck and one vManager license per engineer was obtained.

Highlights of Verification Planning and Management
The high-level strategy provided a general game-plan for verification activity. The need to manage a large set of functional requirements verified using more than 20 environments, across multiple sites and tracked using coverage-driven verification methodology led the team to adopt vManager, a tool from Cadence that automates and assists processes in functional verification.

Below we take a closer look at how vManager was used successfully on our project:

1. Executable verification plan
   A verification plan was created for each of the DUVs. The primary purpose of this plan was to identify all features that needed to be verified. This assisted us in resource allocation and in tracking verification progress using vManager. The plan used in the verification process is termed "executable" because although it is written in natural language using a word-processor, the use of special paragraph formats and export as XML allowed reading of the plan into vManager, and annotation of coverage metrics to each feature, providing a hierarchical feature-based view of progress as measured by coverage collected in simulations. The use of natural language to create the plan allows stakeholders from disciplines outside verification (architects, designers and software engineers) to participate in the planning process.
2. Regression management and progress tracking
   The integration of two designs into a single chip brought with it a lot of tests from the previous development that all needed to work in a new, bigger design. Regression of these tests was our starting point. As the project progressed, a regression was run regularly to ensure that the X/A/M/NC features were not breaking the un-modified portion of the design. One of the overall progress indicators was the passing percentage of the regression.

Because of the previous designs inherited and the addition of new tests at the block-level, sub-system level and chip-level, the regression size became big. The peak time regression size was 1200 tests, each test running for an average for a half hour. To measure the overall progress, we carefully tracked functional coverage and code coverage in the verification plan. The goal was to achieve 100% of functional coverage and code coverage, and exceptions had to be documented.

The main benefits we gained from the verification management methodology were:

• Engineers were able to launch and analyze their own regression without having to create and maintain custom scripts
• A standard view of simulation failures from each DUV was available to allow quick analysis to determine how many unique failure signatures were observed, and to select a simulation for debug
• Progress reports which summarized coverage results from simulations by DUV feature were available to track progress based on an initial verification plan, and to identify uncovered areas

Verification plans created in the planning process facilitated the tracking of progress at a very detailed level while organizing the results by feature to assess progress at a higher level of abstraction. This was achieved by annotating coverage metrics to each feature in the verification plan document, and using vManager to create feature-based views of the coverage for analysis and reporting. The snapshot of the example vPlan is shown in Figure 3

The team lead played the progress tracking role using different stats, the most basic one being when all the regression suites were committed and included a sanity test case. Managers received a summary report to assess which part of the chip required immediate attention, and where to divert resources. The results shared on the intranet in a standard format enabled everyone in different geographies to be in sync, and have quick and easy access to results. On one occasion, for instance, management noted the absence of block-level results for a specific block, and acceptable progress on another, and diverted resources to focus on the block with less progress. The interactive analysis of results allowed specific test cases to be reproduced quickly along with waveform dumps, thus reducing the regression closure effort and time.

Finally, the answer to the question "Is the project finished yet?" was more reliable and was obtained without requiring excessive effort by each engineer and the project lead whenever an assessment of progress needed to be made.

The Bottom Line
The verification was completed on schedule! Tables 2, 3 and 4 summarize key attributes of the DUV which affected verification complexity, along with the results. The numbers are compared with those of the previous project completed a year earlier. The verification strategy, tools and well-defined re-use enabled completion of the verification within the scheduled tape-out date. Tables 3 and 4 also identify Key Enables that contributed significantly to the efficiency.

The verification of our single-chip solution " which was double the size of the previous generation " was completed in approximately half the time with a 50% smaller team.

It was determined that the right balance of strategy, methodology and tools helped address the verification challenges. Assessing verification challenges and developing a strategy was the key first step. A sound verification planning and regression-management methodology, implemented with tools that support an executable verification plan, regression-automation and reporting was a key enabler. Verification environments that address reuse and pay special attention to register verification were also key to the success achieved on the project.

A more complete discussion of this topic can be found in "Metric Driven design Verification: An Engineer's and Executive's Guide to First Pass Success" by Hamilton Carter and Shankar Hemmady, New York, New York, Springer, 2007. ( ISBN 978-0-387-3851-0), www.springer.com/978-0-387-38151-0

About the author
YJ Patil , Genesis Microchip Inc.