Sunday, June 29, 2014

Shift left and Reuse in verification

SNUG India 2014 was a jam packed event! All sessions including the keynotes, papers, tutorials and the design expo were full with engineers pouring in huge numbers. Follow up questions during the presentations and curiosity of the engineers during the expo to understand the solutions from partners were clear indicators of the value these conferences bring in apart from the freebies :) 

Papers on the first day of Verification track focused on the 'Shift Left' approach viz confirming that the design is an exact representation of the spec by uncovering the issues early in the design cycle. The first 3 papers discussed involvement of acceleration/prototyping to enable early SW development and validation of the design in parallel to verification. The 4th paper talked about how the X’s of GLS can be stimulated at RTL to save time & avoid ECOs. While shifting left helps in achieving the goals faster, it is equally important to deploy tools & flows improving 'Reuse'. This was the gist of papers presented on the second day where users shared their experience with enhanced scalability and reusability on different aspects of the verification paradigm be it Formal, low power or IP and SoC verification. 

‘Shift left’ & ‘Reuse’ are interesting concepts sure to reap wonders when applied in conjunction! Really? Let’s see.


Reuse in verification is achieved predominantly through VIPs and test scenarios. 

Expectations from the VIP are not only limited to reuse in the context of IP at block or SoC level simulations. There is a need to have VIPs architected in such a way so as to be reused while porting the target design to a prototyping or emulation platform. If it is the system bus, the VIP needs to be partitioned such that the timed portion of the VIP can move into the box while the untimed portion still continues to be on the work station. SCEMI protocol enables the required communication between the host and the target box. If the VIP is a model for a peripheral sitting outside the chip, it can either fully reside inside the box if everything is to be programmed through the corresponding host IP or else have the same partitioning as the system bus VIP. While the benefits of moving to faster platforms are obvious, the challenges to enable this transition are multi-fold. Porting the design to a target box demands a struggle with partitioning amidst the complexity arising due to multiple clock and power domains. Though the industry has evolved to a large extent on these aspects, architecting and developing verification code that is portable between simulation and emulation is still in its infancy. 

VIPs are available off the shelf but a lot of test development today still happens with home grown test plan and test suite with reuse from what is provided as part of the VIP. Given that the ultimate verification goal is to have a functional SoC with minimal probability of a design bug, C based tests play an important role in achieving it. These tests need to be defined & developed in a planned fashion so as to enable reuse at simulation, emulation and even for Si bring up. A well thought about strategy can actually enable the first level of test development right at the IP stage where a model of the processor can be plugged as part of the IP test bench enabling early test development. Once this suite is ready, complex cases can be covered either with a detailed use case test plan and/or deployment of tools that enable test definition and development in an automated manner. With HW SW teams working in silos and probably in different geographies, a comprehensive solution that converges the two is quite difficult to achieve.

To realize the above there is a need to conceive the end picture, enable development of the pieces and finally connecting the dots to bring up multiple platforms early enough in the ASIC design cycle.

No comments:

Post a Comment