(This is a guest post for PuneTech by Arati Halbe, who has close to 9 years experience in ASIC front end design and verification. Post silicon validation and FPGA prototyping is her recent area of interest and expertise. Arati has worked with Wipro Technologies and Conexant Systems. Arati did her B.E. from University of Pune and M.Tech from CEDT, Indian Institute of Science, Bangalore. See Arati’s linked-in profile for more details.)

As the complexity of Integrated Circuits (specifically ASIC and SoC) increases, and as their sizes keep reducing, the task of testing the chip gets more and more challenging. Engineers need to come up with better and different methodologies to ensure what goes to the factory for manufacturing is actually what they intended to deliver. Verification occurs at various stages in the ASIC development cycle. How much is enough at each stage is a problem that needs to be addressed on a case to case basis. A sound knowledge of various techniques and awareness of capabilities and limitations of each technique goes a long way in making decisions about when, where and what.

Keeping this in mind, PuneChips had verification expert Jagdish Doma talk about “ASIC verification: Trends and Challenges” on 20^th August 2009. Though impacted by the H1N1 scare we had a small but diverse audience. Jagdish discussed in detail the strengths and limitations of the various techniques, viz: ESL, Formal verification, Dynamic simulation, FPGA prototyping and Emulation.

ESL or Electronic System Level testing is the newest trend. Supporters of ESL claim that it is a highly powerful system level modeling tool. It enables fast software bring-up if combined with an emulation/FPGA prototyping platform. ESL has been used successfully to validate systems for mobile applications where only one peripheral/application is active on the processor bus. ESL does not seem suitable for systems where multiple processes and interfaces are active simultaneously, like for example in a networking system.

Formal verification, a static verification technique which is mainly assertion based, is useful to check control paths. It cannot be used to verify datapaths. Dynamic simulation is a very effective way of verifying functionality of every block in the ASIC including the datapath. Gate level simulations performed after the back annotated placement and routing data is available are used to identify timing related issues or omissions/errors in stating multi-cycle paths.

The need to find hardware bugs as early as possible in the ASIC lifecycle drives the emulation and/or FPGA prototyping effort. Both these techniques enable the testing of scenarios which are generally not possible to test in dynamic functional verification, well before the actual silicon comes back from the fab. Emulation or prototyping also accelerate fast software ramp up and the software team can get a development platform ready well before the actual chip is available. Emulation involves running test cases on hardware accelerated platforms like Palladium from Cadence and Veloce from Mentor. For FPGA prototyping, Single or multiple FPGAs are used to build a PCB system targeted for the testing of the ASIC/SoC. The ASIC code is then fully or partially programmed on the FPGA/s and functionality can thus be tested.

Scenarios with much longer simulation times than what normal functional simulation allows can be run on the emulation platforms. All the internal signals are available for viewing and debug, just like in functional simulation. The FPGA prototype platform does enable longer test time, but the debugging available is limited. The hardware accelerators are costly, and investing in them makes sense if a company has lot of ASIC programs running simultaneously. For companies which have similar chips planned back to back, investing in a home grown FPGA based emulation/prototyping platform makes sense. Another advantage FPGA prototyping is that the RTL goes through a complete synthesis and place and route cycle and testing is done on a circuit which is as close to the real ASIC as possible.

To ensure that a bug free product reaches the customer is a complex activity and poses multiple challenges. Coverage, legacy code, repeatability are issues that need to be tackled. Ensuring that the coverage is at an acceptable level is important. Code coverage is run to find out if all the possibilities of a written code are exercised in a test suite. Simulators from cadence (ius), synopsys(vcs) and mentor (modelsim) have their own code coverage analyzers. Functional coverage means to find out if each feature listed in the specification for an ASIC/SoC is verified. It is essential that the functional specification document has an individual numbered paragraph for each feature so that traceability is easier. Functional coverage is an activity that needs planning, reviews and careful test case designing. Methodologies like eRM (e reuse methodology – Specman based) and OVM (open verification methodology – System verilog based) do assist checking functional coverage, but the inputs provided need careful specification and reviews.

Reviews, not just for coverage, but at every stage in the ASIC cycle are extremely important. One of the challenges encountered while designing an ASIC is that the hardware team interprets a certain behavior from software and the software expects that certain things are taken care of in hardware. It is very important to involve members from design team, verification team, architecture team, software & firmware team for verification review.

It takes a good amount of effort to come up with a verification environment, and it is very common for a team to use what has worked before when schedules are demanding. Legacy environment saves lot of time, but it also handicaps the team. Talking about saving time, efficiency goes a long way in shrinking the schedules. The initial time and effort investment in automation of repetitive tasks save lot of time in future. Use of re-usable methodologies will definitely save time and effort.

Finally, while choosing the verification flow for a certain ASIC, team needs to look at what is available in terms of resources as well as time, understand the end user requirement, and make a decision on which technique to employ at what stage.