Quick chat with Ravi Subramanian : Keynote speaker DVCon India 2017

Dr. Ravi Subramanian

For many decades, the semiconductor industry followed Moore’s law, transforming what we called as a discrete chip carrying a function on silicon into a small IP inside the SoC on silicon today. As we continue to debate beyond Moore, more than Moore or stagnation of this law and step in the world of IoT, we realize that the system is no more only a single SoC, but instead, it is a conglomeration of multiple tiny & large systems working in tandem producing interesting use cases & enhancing user experience. But are we as the verification engineering workforce ready with the required skills along with the right arsenal of tools and efficient workhorses to ride through this new challenge?

Dr. Ravi Subramanian, Vice president and General manager of Mentor’s IC Verification Solutions Division shares a holistic view on this subject in his opening keynote on Day 2 at DVCon India 2017. The talk titled Innovations in Computing, Networking, and Communications: Driving the Next Big Wave in Verification, dives into convergence of different technologies and its impact on verification. A quick chat with Ravi, revealed the excitement that we all can look forward to in his talk as well as the future that lies ahead for all of us. Read on!!!

Ravi your keynote focusses on drivers to the next big wave in verification. Tell us more about it?

Yes, my talk will focus on the amazing innovations our industry is developing with respect to computing, networking, and communications. These include the changing nature of computing, the dramatic changes in networking and storage, and the disruptive effect of new broadband communications. Yet, the next big wave in design is actually the convergence of these technologies, which is driving today’s internet-of-things and autonomous systems revolution. A common theme across these emerging systems is the need for low power, security, and safety—whether you are talking about devices on the edge or high-availability systems in the cloud. These new challenges have opened innovation opportunities for us to rethink the way we approach verification

IoT is driving the convergence of different technologies. How would it affect the way we verify the systems today?

To answer your question, I first want to step back in time to provide a framework for today’s challenges. In the 1990’s the concept of separation of concerns was introduced into engineering. Essentially, the idea is that verification would become more productive if we focused on verifying orthogonal concerns or requirements of the design separately versus trying to verify multiple concerns combined. For example, during this period of time, we learned that it is more efficient to verify functional concerns and physical concerns in separate simulation runs. This approach to verification worked well up to about 10 years ago. The emergence of mobile devices introduced new low-power requirements that made it difficult to separate concerns. For example, today we see that physical concerns (such as low power management) now can directly affect functional behavior of a device. Hence, these concerns need to be verified together. Bringing together physical, electrical, and functional has become mandatory.

The key point is that convergence of computing, networking, and communication, which is driving IoT, has introduced new layers of verification requirements that did not exist years ago, and the interaction of these requirements has had a profound effect on the way we must verify systems today.

What are the solutions that the EDA industry is driving to enable this next big wave in verification?

One contributing factor to growing verification complexity is the emergence of new layers of verification requirements, as I previously mentioned. For example, beyond the traditional functional domain, we have added clock domains, power domains, mixed-signal domains, security domains, safety requirements, software, and then obviously, overall performance requirements. Hence, we see the next big wave in verification on multiple fronts:

Continuing introductions of focused solutions optimized for specific verification concerns. Examples of these focused solutions include: formal apps focused on  verifying security features within a design or power apps used to provide complete RTL power exploration and accurate gate-level power analysis within emulation.

Emerging system-level analysis solutions, which provide new metrics and insight into the fully integrated SoC. This becomes essential for system-level performance analysis. The IoT SoC, for example, is a different beast than today’s state-of-the art networking SoC.

Greater convergence across multiple verification engines (e.g., simulation, emulation, and FPGA prototyping), which will improve productivity. The new Accellera Portable Stimulus standard will help facilitate this convergence and foster the introduction of new verification solutions.

Q4: Do you see domain specific solutions like automotive or machine learning etc. getting enabled for verification?

Yes, in fact there are multiple opportunities to leverage big data analytics to solve many system-level analysis problems. Machine learning is only one approach used today for big data analytics; however, there are others. Now, concerning domain-specific solutions in the automotive space, formal technology is being leveraged to improve productivity related to safety fault analysis.

Do you expect all workhorses (Simulation, Emulation & Formal) playing a critical role in verifying these new converged system level designs?

Obviously, this depends on the design. A project developing sensors for an IoT edge solution has different verification requirements than a project developing an automotive SoC containing multiple CPU and GPU cores, a coherent fabric, and multiple complex interfaces. Nonetheless, with increased design integration, multiple verification engines are required today that address the growing volume of verification requirements.

This is the 4^th edition of DVCon in India. What are your expectations from the conference?

DVCon, in general, is recognized as the premier conference on the application of languages, tools, methodologies and standards for the design and verification of electronic systems and integrated circuits. And DVCon India is no exception, which has continued to grow in both attendance and exhibitor participation. I expect DVCon 2017 will continue to deliver high-quality technical content and provide valuable networking opportunities for its attendees. It is the premier venue to share state-of-the-art developments and connect the creative minds working on these developments.

Thank you Ravi!

Join us on Day 2 (Sep 15) of DVCon India 2017 at Leela Palace, Bangalore to attend this keynote and other exciting topics.

Disclaimer: “The postings on this blog are my own and not necessarily reflect the views of Aricent”

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.

Over-verification : an intricate puzzle

For verification, it was an eventful week. DVCON 2013 kept everyone busy with record attendance at the sessions and by following the tweets & blogs that resulted from them. The major highlight of this year’s conference was release of the latest update to System Verilog standard, IEEE 1800-2012 and free PDF copies made available, courtesy - Accellera.

 

With verification constantly marching to increase its claim on ASIC design schedule while retaining its position as a major factor for silicon re-spins, verification planning was a hot topic of discussion at DVCON. Some of the interesting points that came out of a panel discussion on verification planning were –

 

- Verification plan is not just a wish list. You have to define how you’re going to get there.

- Problem is not over-planning, but over-verifying designs because there has not been enough planning.

- Biggest objection we hear is we don’t have time to capture a verification plan. But you'll lose more time if you don't.

- What’s useful in verification planning is “ruthless prioritization.” You can never get it all done.

- My biggest challenge is getting marketing input into my verification plan.

- Failure to plan means planning to fail.

 

Last week, I guest blogged on a similar topic based on a recent survey conducted by Catherine & Neil. Clearly, the issue of poor planning gets highlighted in all areas of product development.

 

Traditionally, the verification plans were just a list of features to be verified, addressing ‘what to verify’. With the emergence of CRV, the plans started including the second aspect i.e. ‘how to verify’. Further, to bring focus to this never ending verification problem, CDV was adopted. The verification plans now started including target numbers in terms of coverage (code, functional and assertions) to define ‘when are we done’. With a given set of resources, when the ASIC design schedule is imposed on the verification plan, meeting the goals is a challenge. There arises a need to prioritize verification in terms of the features. Remember, Any code that is not verified will not work!

 

To enable this “ruthless prioritization”, collaboration is required among marketing, software and hardware groups to align to the design objectives. Everyone needs to understand the potential end applications and preferential ways in the design to achieve them. In case of IPs, this could mean that the initial releases target a limited set of applications based on the customers on board. Once that is achieved, ‘over-verifying’ can take over to further close on the grey areas. In case of SoC, it is a tough call. While design cost continues to increase with diminishing dimensions, the break even may not happen with limited applications (as a result of limited verification) of the SoC. The problem gets aggravated further with the specifications changing on the fly. A platform based approach could be a potential solution where variants of SoC are churned out frequently, but again defining the platform and prioritizing the features boils down to the same problem. A tough nut to crack!

 

The whole point of over-verifying comes to the fore front because verification is the long pole in the schedule. What if the designs could be ‘over verified’ within the timelines? What does it take to achieve that? Are tools like intelligent test benches, formal verification, hardware acceleration or cloud computing a solution? If yes, what is the associated cost and how does it affect?

 

There is no easy answer to any of these questions. In words of Albert Einstein, “The world we have created is a product of our thinking. It cannot be changed without changing our thinking.”

 

Probably when an answer comes out, we will be on the road of commoditizing the hardware. Till then 'over-verification' is what we have to live with!

Constrained Random Verification : A case study

Continuing the discussion further on CRV, here is a case study where a performance intense core was verified from scratch.

GIVEN

- Architecture documents for each block and integrated core.

- Reference model for each block developed for architecture validation and early software development.

- Periodic deliveries of core tests from architecture validation team, reusable at block and core level.

- Enough compute cycles, tool licenses and access to hardware accelerator to speed up verification at core level.

- Timeline for Architecture to RTL freeze = 13 months.

APPROACH

Develop block level test benches targeting CRV and capable of reusing system level tests to ensure staged bring up of functionalities in parallel. Top level test bench would reuse monitors and assertions from block level and simulate system level tests (no CRV) only. Sign off criteria would be 100% functional coverage, Code coverage (Line, expression & FSM), assertion coverage at block level and toggle coverage at core level.

Why limit CRV at block level –

- Test simulation time at core level was expected to be 12-48 hours, throttling iterations and affecting schedule.

- Low probability of finding an RTL bug using CRV with focus on integration verification.

- Test cases coming from architecture validation team would cover most of the use case scenarios.

- Bring up of constrained random TB for core would require staged approach i.e. append 1 block at a time and stabilize that. Verification closure in given time was unpredictable.

EXECUTION

The estimated effort was 200 man months and the team started off with 1 engineer per block taking CDV approach. After test plan, block level test benches were developed using standard methodology and code shared for similar functionalities. The test benches became functional using system level tests executing at block level. While RTL debugging started, coverage models were developed to realize the test plan and hooked onto the TB. Next the CRV support was added to the test bench. The random tests were initially directed towards areas yet to be explored by system tests to exercise DUT from all fronts. When the system tests stagnated for a data path within the block, the random tests continued to weed out bugs and hit scenarios for coverage closure. By the time system tests started passing for individual blocks, the team was ready with the core level TB. Every engineer finishing block level started contributing to top level. Tests at core level consumed a lot of simulation cycles (i.e. idle time for engineers) so a couple of engineers focused on CR TB for adjacent blocks (choking point from performance perspective) to regress the RTL further. No specific coverage goals were planned at this level and the emphasis was to hit random scenarios. Finally the team was able to deliver quality RTL with acceptable slippage in schedule.

CONCLUSIONS

Following CDV and standard methodology for CRV helped in defining, tracking and achieving goals in an organized manner. Maintenance and rework claimed limited overhead. Reusing components from block to top level was smooth with minimum efforts.

With CRV TB, the bug rate increased drastically, averaging to 7 bugs per week per block for at least 6 weeks. The scenario generation increased exponentially while tests delivered by architecture validation team continued to be incrementing linearly. The team was able to uncover hidden bugs and hit corner cases difficult to cover otherwise. Performance bottleneck scenario generation was easily achievable through CRV.

The CRV TB for adjacent blocks revealed interesting outcome. Converging on the valid constraints was challenging. The set of valid constraints at block level required additional constraints guided by introduction of a new block in the DUT data path. This TB was able to uncover 3 bugs, 2 with software work around and 1 critical where the two blocks would hang in a particular scenario. The latter was difficult to catch through system tests.

Lesson learnt – If you are unable to introduce CRV at top level, try to deploy it to the level possible!

Constrained Random Verification : + and -

In the last decade, adherence to Moore’s law demanded ‘divide and conquer approach’ for developing SoC/ASIC. The design cycle now requires develop/procure IPs; build sub systems using them and integrate these sub systems further to realize the final product. Some IPs (Networking protocols, Graphics, Video, DSP… etc) are complex enough that further division into blocks during design and verification is unavoidable. Amidst all this, verification still is the biggest challenge in meeting schedules and taping out bug-free products. The ever increasing design complexity problem has enabled rapid development in ASIC verification. From traditional directed verification approach to Constrained Random Verification (CRV), it has been a long way. CRV brought a paradigm shift in the way we verify our designs and enabled development of Coverage Driven Verification (CDV) and Standard methodologies (eRM, RVM, AVM, VMM, OVM & UVM).

ADVANTAGES

+ Enables the test bench to hit corner cases & hidden (unplanned) bugs

+ When coupled with CDV leads to faster convergence of verification schedule  

+ Number of test cases to be developed / maintained is fewer as compared to directed test

+ Updating verification environment for changes in specifications during the design cycle is better organized

+ Methodical approach during development enables reusability from module to higher levels

+ Improves Portability across projects

+ Test bench reviews are more structured and probability of finding issues increases

+ Following a standard methodology helps in knowledge transfer across engineers & teams

+ Increases compute resource & license utilization

LIMITATIONS

- Requires a reference/Golden model to predict the output

- Requires lot of planning and structured code development (Methodology is key)

- In absence of CDV it would hard to define ‘are we done yet’

- During TB development, RTL bug rate is 0 and initially TB bug rate may be > RTL bug rate

- Converging on valid constraints when moving from IP to higher level involves iterations

- With increased design scope debugging random scenarios is challenging

- Limited randomness possible while verifying at SoC level with processor(s) in place.

- Gate level simulations require a set of directed test cases where CRV doesn’t contribute much

- In absence of adequate licenses and compute resources it stagnates to deliver desired results

Undoubtedly CRV has been instrumental in improving the quality of verification and getting organized verification closure. Most of the above limitations can be nullified with proper planning during the initial phase of any project. For IP level, CRV is a de-facto standard. However, as we move one level up, the limitations start influencing. Teams are forced to think if CRV will be utilized to its true potential? Should we follow CRV for sub-system and top level? What are the bottlenecks in extending CRV to increased scope of the design & is it worth the investment?

Coming next is a quick case study. Stay tuned…

EDA 360 : Realizing the Realizations

EDA360 proposes a marriage between hardware and software. Each of them evolved independently and on integration, the final product has been “good enough” but not OPTIMAL. Either the software is unaware of the features in hardware or the hardware is incognizant with the requirements of software. Furthermore, when there is an issue with the system operation, ownership of debugging is a big question mark. EDA360 suggests correction at all levels through 3 realizations.

Silicon Realization – Associated with Creators and Integrators (serving as Creators also), it aims to design (an IP, a sub-system or a chip) for high performance, low power and small form factor. With increasing design complexity, matters related to low power, mixed signal design, 3D IC, DFM and yield are worrying the technocrats more than ever. Within the hardware arena, the tool evolution for functional, physical and electrical domains happened in silos and this constantly hampers efficiency, productivity and predictability. Amidst these technical challenges, pressure of time to market leaves no room for error. To achieve the goal of 3Ps, design teams need to control complexity at a higher abstraction level. This means that all variables of the design process should be accessible i.e. controllable and observable at a higher layer. There is a need for an integrated flow along with unified representation of intent to drive the design from this abstract layer to silicon such that there is interoperability on functional, physical and electrical parameters at each level.

SOC Realization – Associated with Integrators it extends expectations towards Creators. The traditional approach to SOC development is serial i.e. SOC à [OS + SW] à APPS. Each of these steps have least interaction and knowledge sharing, thereby leading to poor Productivity i.e. sub optimal hardware usage and increased failures in the end product. This adds to the cost & delay affecting Predictability and Profitability. Moreover, disjoint teams result into ownership issue (HW or SW problem) if the end product doesn’t behave as expected. SOC realization proposes a potential solution to such problems by treating SOC as a HW that is always accompanied with device drivers. This can be achieved by deploying a top down approach where SOC design and related (embedded) SW development happen in parallel. TLM and virtual prototyping aid in testing these SW layers well in advance before the silicon comes back. Extrapolating this approach sets expectations for IP developers to package the whole stack i.e. TLM, RTL, Netlist, design constraints, VIP and device drivers as part of IP deliverable.

System Realization – It is associated with Integrators. In the conventional flow [HW à SW à APPS], Productivity suffers as, HW is either over designed to support unforeseen applications or under designed limiting application support. This bottom up approach involves minimal planning and no what if analysis leading to poor selection of components (HW, OS, and Drivers etc) for the system. HW SW integration and APPS development happen late and with little knowledge of each other, contributing to inefficiencies and schedule delay [re-verification and ECOs] thereby affecting Profitability. Silicon Realization suggests a top down approach where applications drive the system requirements to overcome such issues and add differentiation as well as competitiveness to the end product. Chip planning tools assist in what if analysis with available set of components for a given architecture to improve predictability. TLM, Virtual prototyping and Emulation tools help with early software development and testing. Latest development in verification when extended at multiple levels provides a defined approach for embedded SW verification and bringing up a controllable & observable dashboard to manage the complete system development lifecycle.

The changing market dynamics has ignited the debate of ‘what should be’ from ‘what is’ available and if it demands a complete change in the way we design our products we better do it now before the next product from competition kicks our product out from the market.      

Related posts -
EDA 360 : Realizing what it is?
EDA360 Realizations : Verification perspective

EDA 360 : Realizing what it is?

A vision paper released by Cadence in early 2010 created a BUZZ in the EDA community. The hot topic of this year’s CDNLive 2010 is EDA360. Here is a summary on this topic in a 3 part series which concludes with what EDA360 brings to our plate as a verification engineer.

Cadence has a history of creating a wave (with whatever it does) so much that it kind of enters into the DNA of the Cadence guys and the people associated. In past, when Cadence released Low Power CPF solution, my team was invited for a technical brief on the solution at Cadence premises. By that time we had heard a lot about CPF from the Sales, AEs and friends working for Cadence but we were amazed when, while we were completing the formalities to enter their building, the security guard asked if we were there to discuss Low power! I am sure this time if someone visits he would be asking for EDA360 J

WHAT IS EDA360?

For many years semiconductor industry has been religiously following Moore’s Law.  With few defined nodes to shrink size, exponential increase in cost of silicon at advance nodes, saturation in SOC architecture for a given application, time to market challenges and shriveling market window for any product, there is a need to CHANGE the way every entity associated with this industry has been operating.  With software claiming majority of product cost, the innovation and differentiation revolves more around end user applications (apps). This demands a SHIFT in the ‘traditional approach’ of developing HW, OS, SW and APPS serially, to an ‘application driven model’ where, definition of a complete platform enables HW & SW development in parallel. Recent success of iPhone (Hardware dependent platform) and Android (Hardware independent platform) over conventional players demonstrates the changing dynamics of the market. This calls for a HOLISTIC ADJUSTMENT among the partners in this ecosystem.

EDA360 is a potential answer to this CHANGE, this SHIFT and this HOLISTIC ADJUSTMENT. It addresses the need for all stakeholders in the ecosystem with the goal of improving the 3Ps (Productivity, Predictability and Profitability) for the 4^th P i.e. the Product. It is an ambitious attempt to connect the product development chain by understanding the customer’s customer (the end customer). Focusing on the ‘consumer’, EDA360 preaches a top down i.e. application driven approach for product development by highlighting the grey areas in the present model and how the new model can help weed out the inefficiencies of the ecosystem thereby improving the 3Ps.

Who does what?

It starts with re-classification of the developers into –

1.  Creators – Organizations that will keep innovating silicon with the goal for better performance, low power and small die size. These teams would be constantly feeding silicon capacity and following Moore’s law. With minimal contribution towards end product differentiation, to be productive & profitable only a handful of such companies can survive.

2.  Integrators – Organizations that will optimally integrate the products from creators to actualize the end product. They would stick to mature process nodes and define application focused platforms (software stack) to serve the application needs with the goal to meet quality, cost and time to market. 

How it will be done?

To achieve the end goal, EDA360 brings forward 3 important capabilities –

-          System Realization

-          SOC Realization

-          Silicon Realization

Semiconductor industry is at a juncture where certain critical decisions become inevitable. As Charles Darwin pointed out in the Theory of Evolution – “Beneficial genetic mutations are part of random mutations occurring within an organism and are preserved because they aid survival. These mutations are passed on to the next generation where an accumulated effect results in an entirely different organism adapted to the changes in environment”. Hopefully EDA360 rolls out in a series of such mutations bringing out the much desired and demanded change essential for evolution of our industry.

Continue reading -
EDA360 : Realizing the Realizations
EDA360 Realizations : Verification perspective