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”

Quick chat with Alok Jain : Keynote speaker, DVCon India 2016

Alok Jain

All of us have heard the story of a woodcutter and the importance of the quote “Sharpen your axe”. It applies well to everything we do including verification. Two decades back, the focus of a verification engineer was predominantly on “What to Verify”. As complexity grew “How to Verify” became equally important. To enable this, EDA teams rolled out multiple technologies & methodologies. As we try to assimilate & integrate these flows amidst first time silicon & cost pressure, it is important for us to sharpen our axe through continuous learning, applying the right tool for the right job and applying it effectively.

Alok Jain, Senior Group Director in the Advanced Verification Division at Cadence would be discussing on similar lines as part of his DV track keynote on Day 1 at DVCon India 2016. With 20+ years of industry experience, Alok leads the Advanced Verification Division at Cadence India. Having associated with different technologies around verification in the past 2 decades, Alok candidly shared his views on the challenges beyond complexity that verification teams need to focus on. Here is a curtain raiser for his talk "Verification of complex SoCs" –

Alok your keynote topic focuses on challenges in verification beyond the complexity resulting from Moore’s law. Tell us more about it?

The keynote is going to focus on challenges and potential solution for verification of complex SoCs. Verifying a complex SoC consisting of tens of embedded cores and hundreds of IPs is a major challenge in the industry today. One of the big challenges is performance and capacity. Given the size and complexity of modern SoCs, tests can run for 18-24 hours or even more. One has to figure out how to get the best verification throughput. Another challenge is generation of test benches and tests. The test benches have to be developed in a way which can achieve good performance in both simulation and hardware acceleration. Tests have to be created that stress the SoC under the application use cases, low power scenarios, and multi-core coherency scenarios. The tests have to be re-usable across pre-silicon and post-silicon verification and validation platforms. Yet another challenge is coverage. One has to measure verification coverage across formal, simulation, and acceleration platforms at the SoC level to know when you are done. The final challenge is how to effectively debug across RTL, test bench, and embedded software on multiple verification platforms.

In the last decade, advancements in verification was focused primarily on unifying HVL(s) & methodologies. What changes do you foresee in verification flows ‘Beyond UVM’?

UVM is very well suited for IP, Sub-system and some specific aspects of SoC verification. However, UVM is not the best approach for general SoC verification. UVM is essentially developed for “bottom-up” verification where the focus is on trying to exhaustively verify IP/sub-systems. SoCs require a more “top-down” verification where the focus is on stressing the SoC under important application use cases. There is a need to reuse SoC content across simulation, emulation, FPGA and post-silicon. UVM is optimized for simulation and is too slow and heavy for high speed platforms. Finally, there is a need to drive software stimulus on CPUs in coordination with hardware interfaces. It is difficult in UVM to drive and control software and hardware interfaces. All this is asking us to explore options beyond UVM. The keynote will cover some more insights into options beyond UVM.

The rise of IoT is stretching the design demands to far ends i.e. server class vs edge node devices. How do you see verification flows catering to these demands?

Several of the requirements for IoT verification are similar to the ones for complex SoCs. But then there are some unique additional requirements from the IoT world. The first is simply the cost of verification. For complex SoCs, the cost of verification has been steadily rising. For IoT applications, one has to consider alternative methods and flows that can reduce the cost. One option is to use some form of a correct by construction approach where the design is specifically done in a way to enable a simpler form of verification. Another approach is to put much more emphasis on reuse. This includes horizontal reuse which is portability across multiple platforms and vertical reuse which is reuse from IP to sub-system to SoC. Another requirement is verification throughput for design with considerably more analog, mixed signal and low power content. Finally, one has to devise verification techniques and flows that can cater to the security and safety requirements of modern IoT applications.

Formal took a while to become mainstream. The rise of Apps in Formal seems to have accelerated this adoption. What’s your view on this?

Yes, I do agree that Apps has considerably accelerated the pace of adoption of formal. Traditionally, formal tools have been developed and used by formal PhDs and experts. The main charter and motivation of these experts was to solve the coolest and hardest problems in formal verification. It was only after some time that both sides (developers and users) started realizing that formal can be used in a much more practical and usable way by engineers to solve specific problems. This lead to the development of various formal apps which greatly enabled the mainstream usage of formal.

This is the 3rd edition of DVCon India. What are your expectations from the conference?

I am expecting to attend keynotes, technical papers and panel discussions that give me an understanding of some the latest work in the domain of design and verification of IPs, sub-systems and SoCs. In addition, I am looking forward to the opportunity to network with some of my peers from the industry and academia.

Thank you Alok!

Come join us in this exciting journey to contribute, collaborate, connect & celebrate @ DVCon India 2016!

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

Marlin & Dory way of 'Finding Bugs'

On our return after watching ‘Finding Dory’, my son asked, “Dad, if you were to find Dory would you be able to do that”? I said, “Ofcourse”! Next, came HOW? I reminded him that my job is to Find Bugs and so I know the tricks of the game already. That made him super excited and wanting to know more about it. Given that this time the reference was picked by him, I decided to continue the same to explain him further.

In the movie, Marlin and Nemo were finding Dory inside the Marine Life Institute (MLI), likewise, we find bugs inside the design called as System on Chip (SoC). The SoC has a lot of similarity to MLI in the sense that it is big and complex. As MLI had different sections, our SoC has different blocks where Dory (Bug) can be found. Also it is not only the sections but the inter-connections that are equally important. When we look for Dory (Bug) inside these blocks we call it IP verification and when our focus is on the inter-connections we call it Integration or SoC Verification.

Image Source : http://www.socwall.com/desktop-wallpaper/7462/dory-and-marlin-by-ryone/

We start off our quest using the Marlin way i.e. “Assess the situation, evaluate, and plan it out”. We call it the Directed Verification approach wherein we understand the design, prepare a plan on where and how we would look around for Dory (Bug) and then execute accordingly. During this process we also keep asking (reviews) around (designers & peers) to let us know if we are missing out on anything. So if Dory is somewhere around, there is a chance we may sight her. But since Dory doesn’t think much before acting, that makes her unpredictable. There is always a possibility that we may not find her as per our plan.

My son’s eyeballs zoomed…. THEN?

Then we also do what Marlin & Nemo did i.e. follow “What would Dory do”? My son jumped, "She wouldn’t think twice and be random". Yes! We pick the Dory way and we call it Random Verification. We search randomly everywhere in an unplanned sequence and guess what? The chances that we would find Dory (Bug) increase. To make it more effective, we define weights and constraints to the randomness so as to improve our luck of finding her further. The approach now becomes Constrained Random Verification (CRV).  While following this random pattern we also take a note (coverage) of where all we have visited to avoid repeating same place again and save time. Now we can find her faster. Tracking coverage on top of CRV is called Coverage Driven Verification (CDV). So if we missed finding Dory (Bug) using the Marlin way (Directed verification) we still have an option to find her the Dory way (CRV).

That settled my son for a while till he pointed again saying, “Dad, maybe you should seek help from Bailey, the beluga whale who can find Dory faster than anyone using echo location”. I smirked and told him that we have our Bailey too and we call it Formal Verification. But then, Bailey was dependent on the whale voice between Dory & Destiny, the whale shark without which he couldn’t be of much help. Similarly, in Formal we are dependent on the assertions that connect the tool to the bug in the design. The effectiveness of this approach is purely dependent on the quality of voice (assertions) and the connect (covering all parts of design) between Dory & Destiny. But yes, if that is in place, it is really fast & effective.

Now convinced that his dad would be able to find Dory, my son asked, “So once you have found Dory, what do you do next”?

I laughed and told that we don’t have to find only 1 Dory (Bug). There are many of them and the address and architecture of the institute (new SoC) also keeps changing. So we just keep Finding Dory (Bug)!!!

Disclaimer: "The postings on this blog are my own and not necessarily reflects the views of Aricent"

Moore's law - A journey of 50 years

50 years of innovation! 50 years of quest with complexity! 50 years of Moore's law! Yes, April 19th is an important date for the semiconductor industry. It was on this date in 1965 that a paper was published citing Gordon Moore's observation - the no. of transistors on a given silicon area would double in almost every two years. The observation turned to be a benchmark and later a self fulfilling prophecy that is chanted by everyone whether an aspirant wanting to be a part of this industry or veteran who worked all throughout since the time when the law was still an observation! I myself remember my first interview as a fresh grad where I was asked the definition & implication of this law. It may not be a surprise if there is a survey done on one name that people in this industry have read, heard or uttered the most in their careers and the result would be MOORE unanimously!

The below infographic from Intel would help you appreciate the complexity that we are talking about –



In this pursuit to double the no. of transistors, there were major shifts that the industry experienced. Let's have a look at the notable ones that had a major impact -

Birth of EDA industry – As the numbers grew it was difficult to handle the design process manually and there was a need for automating the pieces. While the initial work in these lines happened in the design houses, it was soon realized that re-inventing the wheel and maintaining proprietary flows without considerable differentiation to end products wasn’t so very wise. This lead to the birth of the design automation industry that today happens to be the lifeline of the SoC design cycle.

Birth of the fabless ecosystem – The initial design houses had the muscle to manufacture the end product while allowing some contract manufacturing for the smaller players. This setup had its own set of issues discouraging startups.  Also, maintaining the existing node while investing in R&D for next gen nodes was unsustainable. It was only in the late 80s when Morris Chang introduced the foundry model that the industry realized fabless was a possibility. Since then, all stakeholders of the ecosystem have collaborated towards realizing the Moore’s law.

Reuse – As the transistors scaled, the turnaround time to design should have increased, but, to keep a check on the same, reusability was adopted. This reuse was introduced at multiple levels. Different consortiums came forward to standardize the design representations & hand offs. Standards helped in promoting reuse across the industry. Next was design reuse in form of IPs. For standard protocols the IPs are reused across companies while for proprietary ones reuse within the organization is highly encouraged. Reuse has played a significant role in continuing the pace that Moore’s law suggests.

Abstraction – When the observation was made, the design were still at transistor level and layouts done manually. Due to the need to sustain the rising complexity, it was realized to move to next level of abstraction i.e. logic gates followed by Register Transfer level where the design is represented in HDLs and synthesized to gates. Today the industry is already talking about a still high level synthesizable language.

Specialization – The initial designs didn’t require a variety of skill set as it is today. Given the evolution of the design cycle and the quantum of responsibility at every stage, there was a need to bring in specialists in each area. This lead to RTL designers, verification engineers, gate level implementation engineers and layout engineers. Today the overall team realizing a design runs into hundreds of engineers with varied skill set for a complex SoC involving EDA, foundry, reuse & abstraction.

Throughout these 50 years, there were many a times when experts challenged the sustainability of Moore’s law. Most of them had a scientific rational endorsing their argument. However, the collective effort of the industry always was able to find out an answer to those challenges – sometimes through science, sometimes through logic and sometimes through sheer conviction!

Long live Moore’s law!

Is Shift Left just a marketing gimmick?

This year DVCON in US was a huge success hosting close to 1200+ visitors busy connecting, sharing & learning! With UVM adoption rate stabilizing, this year the talk of the event was ‘Shift Left’ – a discussion kicked off as a keynote  by Aart J. De Geus, CEO of Synopsys. The reason for the generated interest is because there are gurus preaching it to be the next big thing and then there are pundits predicting it to be a mere marketing buzzword. In reality, both are correct!

The term 'Shift Left' is considerably new and is interesting enough to create a buzz around the industry. Without the buzz there is no awareness and without awareness, no adoption! However, the phenomenon i.e. squeezing the development cycle aka 'Shift left' for faster time to market has been there for more than a decade.

In the 90s, hundreds of team members worked relentlessly to tape out 1 chip in years & were flown to destinations like Hawaii for celebrating it. Today this is no more heard because every organization or for that matter even the captive centres itself are taping out multiple chips per year. The celebration got squeezed to a lunch/dinner - probably indicating a 'Shift Left' in celebrations too :)

Back in the 90s, the product was HE centric and the so called ASIC design cycle was fairly simple owing to its sequential nature where next stage starts once earlier is done. The industry saw this as an opportunity and started working towards tools & flows that can help bring in efficiency by parallelizing the efforts. Introduction to constrained random verification lead the verification efforts to be parallel to RTL thereby stepping left. Early RTL releases to implementation team helped parallelizing the efforts towards floor planning, placement, die size estimation and package design etc. Reuse of IPs, VIPs, flow, methodologies etc gave further push enabling optimized design cycle. These efforts helped in bringing the first level of the now called 'Shift Left' in the design cycle.

In the later part of the last decade, 2 observations were evident to the industry -

1. The product is no longer HW alone and instead a conglomeration of HW & SW with the later adding further delays to the overall product development cycle.

2. Efficiency achieved out of parallelism is limited by the longest pole of the divided tasks. In ASIC design cycle, Verification happens to be gating further squeeze in the cycle.

This became the next focus area and today given that the solutions have reached some level of maturity the buzz word that we call ‘Shift Left’ finally found an identity! The key ideas that enable this shift left include –

- Formal APPS enabling faster targeted verification of defined facets in any design. The static nature of the solution wrapped up in form of APPS has tickled the interest in the design community to contribute to verification productivity by cleaning up the design before mainstream verification starts. This leads to another buzzword DFV - ‘Design for Verification’.

- FPGA prototyping has always been there but each organization was spending time & efforts to define & develop the prototyping board. Today off the shelf solutions give the desired jump start to the prototyping process enabling early SW development once the RTL is mature.

- To improve the speed of verification, hardware accelerators aka emulation platforms were introduced and these solutions opened up gates for early software development even before the RTL freeze milestone.

- Improvement in speed with higher level of abstraction was evident when the industry moved from Gate level to RTL. The next move was planned with transaction level modelling. While high level synthesis is yet to witness mass adoption, its extension resulted in Virtual prototyping platform enabling architecture exploration, HW SW partitioning and early SW development even before the RTL design/integration starts.

In summary, the process of product development cycle is getting refined by the day. The industry is busy weeding out inefficiencies in the flow, automating everything possible to improve predictability and bringing in the required collaboration across the stakeholders for realizing better, faster & cheaper products. Yes, some call it the great SHIFT LEFT!

Designers should not verify their own code! REALLY?

Around 2 decades back, the demands from designs were relatively simple and the focus was on improving performance. Process nodes had longer life, power optimization wasn’t even discussed and time to market pressure was relatively less given that the end products enjoyed long life. In those days, it was the designer who would first design and later verify his own code usually using the same HDL. Over the years, as complexity accelerated, a new breed of engineers entered the scene, the DV engineers! The rational given was that there is a need for an independent pair of eyes to confirm if the design is meeting the intent! Verification was still sequential to the design in early days of directed verification. Soon, there was a need for constrained random verification (CRV) and additional techniques to contain the growing verification challenge. The test bench development now started in parallel to the design, improving the size & need of verification teams further. With non HDLs i.e. HVLs entering the scene the need for DV engineers was inevitable. All these years, the rational of having an additional pair of eyes continued to be heard to an extent that we have started believing that designers should not verify their own code.

In my last post I emphasized the need for collaboration wherein designers and verification engineers need to come together for faster verification closure. Neil Johnson recently concluded in his post on designers verifying their own code. My 2 cents to whether designers should not or shall I say do not verify their own code –

To start with, let’s look at what all involves verification? The figure adjoining is a summary of efforts spent in verification based on the study conducted by Wilson research in 2012 (commissioned by Mentor). Clubbing some of the activities it is clear that ~40% of the time is spent in Test planning, Test bench development and other activities. The rest ~60% of the effort is spent on Debug & creating + running tests. The DUT here can be an IP or SoC. 

When an IP is under development or SoC is getting integrated, the DV engineers would be involved into the 40% of the activities mentioned above. These are the tasks that actually fall in line with the statement of additional pair of eyes validating design intent. They need to understand the architecture of the DUT and come up with a verification plan, develop verification environment and hooks to monitor progress. At this level, the involvement of the design team starts with activities like test plan review, code coverage review, inputs to corner cases and tests of interest. 

So, once the design is alive on the testbench, do the designers just sit & watch the DV team validate the representation of spec developed by them? NO!

Debugging alone is a single major activity that consumes an equal amount or sometimes more efforts from the designers to root cause the bug. Apart from it, there is significant involvement of the design team during IP & SoC verification.

For IPs, CRV is a usual choice. The power of CRV lies in automating the test generation using the testbench. A little additional automation enables the designers to generate constrained tests themselves. Assertions are another very important aspect in IPs. With introduction of assertion synthesis tools, the designers work on segregating the generated points into assertions or coverage. For SoCs, apart from reuse of CRV, directed verification is an obvious choice. Introduction to new tools on graph based verification help designers to try out tests based on the test plan developed by the DV engineer. Apart from this, corner case analysis and usecase waveform reviews are another time consuming contributions put in by designers for verifying the DUT.

Coming back to the rational on having an independent pair of eyes verify the code, the implication was never that the designers shall not verify their own code. Infact there is no way for the DV team to do it in a disjoint fashion. Today the verification engineer himself is designing a highly sophisticated test bench that is actually equivalent to a designer’s code in complexity.  So it would be rather apt to say that it is the two designs striking each other to enable verification under the collaboration between design & verification teams!

What is your take on this? Drop a note below!

The 4th C in Verification

The 3C’s of verification i.e. Constraints, Checkers & Coverage have been playing an important role enabling faster verification closure. With growing complexity and shrinking market windows it is important to introduce the 4^th C that can be a game changer in actually differentiating your product development life cycle. Interestingly the 4^th C is less technical but highly effective in results. It is agnostic to the tool or flow or methodology but if introduced and practiced diligently would surely result in multi-fold returns. Since verification claims almost 70%of the ASIC design cycle, it is evident that timely sign off on DV would be the key to faster time to market of the product. Yes, the 4^th C I am referring to is Collaboration!

UVM demonstrates a perfect example of collaboration within the verification fraternity to converge on a methodology that benefits everyone. Verification today spreads beyond RTL simulations to high level model validation, virtual platform based design validation, analog model validation, static checks, timing simulations, FPGA prototyping/emulation and post silicon validation. What this means is that we need to step out and collaborate with different stakeholders enabling faster closure.

The first & foremost being the architecture team, RTL designers & analog designers who conceive the design and realize it in some or the other form and many a times fall short of accurate documentation. The architecture team can help to a large extent in defining the context under which theverification needs to be carried out thereby narrowing down the scope. With a variety of tools available, the DV teams can work closely with designers to clean the RTL removing obvious issues that otherwise would stall simulation progress. Further, assertion synthesis and coverage closure would help in closing the verification at different levels smoothly. Working with analog designers can help tune the models and their validation process wrt the circuit representation of the design. This enables faster closure of designs that see increased scope of analog on silicon.

Next are the tools that we use. It is important to collaborate with the EDA vendors in not just being the user of the tool but working closely with them in anticipating the challenges expected in the next design and be early adopters of the tools to flush the flows and get ready for the real drill. Similarly, joining hands with the IP & VIP vendors is equally crucial. Setting up right expectations with the IP vendors on the deliverables from verification view point i.e. coverage metrics, test plans, integration guide, integration tests etc. would help in faster closure on SoC verification. Working with VIP vendors to define how best to leverage the VIP components, sequences, tests & coverage etc. at block and SoC level avoids redundant efforts and help in closing verification faster.

The design service providers augment the existing teams bringing the required elasticity to the project needs or take up ownership of derivatives and execute them. These engineers are exposed to a variety of flows and methodologies while contributing to different projects. They can help in introducing efficiency to the existing ways of accomplishing tasks. Auditing existing flows and porting the legacy environment to better ones is another way these groups can contribute effectively if partnered aptly.

Finally the software teams that bring life to the HW we verify. In my last blog I highlighted the need for HW & SW teams to work more closely and how verification teams acts as a bridge between the two. Working closely with the SW teams can improve reusability and eliminate redundancies in the efforts.

Collaboration today is the need of the hour! We need to be open to recognize the efforts put in by different stakeholders from the ecosystem to realize a product. Collaboration improves reuse and avoids a lot of wasted efforts in terms of repeated work or incorrect understanding of intent. Above all, the camaraderie developed as part of this process would ensure that any or all these folks are available at any time to jump in the hour of need to cover for unforeseen effects of Murphy’s law.

Drop in your experiences & views with collaboration in the comments section.

Taking a pulse of what's going on in Verification!

The design complexity today is marching forward at an accelerated speed and its effect on verification is witnessing equal leaps and bounds. The world of verification has grown multi-fold in past 5 years across all fronts covering what all to verify, how to verify and who all required to verify. Today, conferences hosted by EDA partners are not just focusing on a simulator, a language, a methodology or a new tool and instead bringing up discussions on a plethora of topics. It seems to address this growth, Cadence decided to have the 2^nd day of CDNLive India 2014 mostly targeting the DV community hosting multiple tracks on verification. With hundreds of footfalls, a mixed bag of papers on all aspects of verification, an extended exhibitor pavilion for partners along with lunch and tea sessions busy with networking, the event was truly in sync with the theme, connect... share... inspire!

A decade back all such events focussed on sharing the upgrades in tools particularly the simulator. The technology update included introduction to new features, added support for language and improved performance. Today no one talks about the simulator and instead everything around it getting integrated under a hood with features like –

• A broad VIP catalog with added support for easy bring up of test benches for IP/SoC, compliance test suite with ready made coverage/assertions. A new class of accelerated VIPs that interface easily with the emulators giving further boost to the overall productivity.
• Updates to power aware verification involving multiple tools (formal, simulator & emulator) with support for different power formats/versions, auto generation of relevant assertions and different aides to ease debugging these scenarios.
• How to model analog blocks to achieve high performance with electrical accuracy as part of the AMS support. Different languages supporting model development, coverage driven verification to validate these models and reuse of the environment when integrated with digital blocks.
• A portfolio of formal apps that can accomplish the job of static checks related to connectivity, power, registers, X-prop, protocol compliance checks etc.
• Improved support for IPXACT based flows to enable register modelling, register verification and interface connectivity promoting IP reuse with minimum issues.
• Integrated support for coverage collection and merging across different levels (IP, sub system & SoC) of verification involving different tools or flows used to achieve verification closure.
• Verification management featuring executable verification plans, regression management, triaging and analysis with different views based on user’s role in the project.
• Added debug tools and support to view the transactions, filter or play around back and forth with the simulation logs.
• Hardware accelerators with improved capacity, performance and features that enable detailed debugging, power aware support, assertions and coverage.
• Prototyping platforms/emulators and how they enable boot up with android etc. much before the silicon arrives.
• Improved Virtual platforms and models in sync with the above to enable early software development thereby shifting the whole product development cycle to the left.
• Performance analysis of SoC confirming architecture stability or assisting in exploring alternates promptly.

Yes! Verification has evolved into a GODZILLA beyond the control of one HVL, one methodology and one simulator. The rules of the game have changed and the industry is responding faster than ever to this change. Observing all these changes I recollect the topic EDA360 introduced by Cadence to the industry back in 2010. While the terminology might have lost its steam, the essence of the idea seems to have realized quite a lot since then. For those who missed reading about it please refer to the below posts summarizing EDA360. Believe me it’s worth reading!

EDA360 : Realizing what it is?

EDA360 : Realizing the Realizations

EDA360 Realizations : Verification perspective

Do you agree that the current state is in sync with EDA360? Leave a comment!

If you have missed out to any of these events, don’t miss to attend DVCON India 2014 on Sept 25, 26. Registrations now open.

DVCON goes GLOBAL!

Design and Verification Conference popularly known as DVCON is beginning to flex its muscles and move out of Silicon Valley to reach your friendly neighborhood this year. Yes, DVCON will be hosting the conference at Bangalore, India and Munich, Germany in 2014 on top of the already concluded conference at San Jose, California. This blog post is a quick refresher about the event for fellow engineers who have been busy solving the most intricate verification challenges in the trenches unknowingly that a platform does exist to discuss those puzzles and hear out how the community is handling them while sharing their solutions. It’s an avenue promoting collaboration among the design and verification community without a bias for a particular tool, flow or methodology. It’s a forum where everyone, a novice or a guru, a student or a professional, a beginner or an expert come together to discuss the takeaways that can be implemented as soon as they hit their work stations. It’s a place where you learn, discuss, network, collaborate and connect.....and this time it’s HERE (Bangalore & Munich)!

HISTORY of DVCON

It’s been 25 years in the spirit and 10 years to the name for this conference. The origin can be traced back to late 80s when VHDL started picking up; the user community started meeting twice a year under VUG (VHDL users group) leading to a conference by the name VIUF (VHDL International User Forum). Around the same time Verilog too gained user traction leading to IVC (International Verilog Conference) in early 90s. While the two events continued to serve the respective communities, they joined hands in 1997 giving way to IVC/VIUF conference later termed as HDLCon. Finally in 2003, HDLCon became DVCON giving it a legacy of 25 years and a brand that continues to evolve for a decade now. In 2014, it extends the reach to India and Europe.

DVCON India

ISCUG (Indian SystemC User’s Group) has been hosting an event with focus to accelerate adoption of SystemC as an open source standard for ESL design for past 2 years. This platform now morphs into DVCON India, a 2-day conference in Bangalore on Sept 25-26 2014 running Design Verification and ESL track in parallel.  In words of the committee, DVCon India is an attempt to bring a vendor-neutral international Design and Verification conference closer to home for the benefit of the broader engineering community. An excellent platform to share knowledge, experience and best practices covering ESL, Design & Verification for IP and SOC, VIP development and Virtual Prototyping for Embedded Software development and debug. The conference provides multiple opportunities to interact with industry experts delivering keynote speeches, invited talks, tutorials, panel discussions, technical paper presentations, poster sessions and exhibits from ecosystem partners.

Call for abstracts – submission deadline JULY 21^st, 2014.

Registrations soon to be opened.

DVCON Europe

A new chapter for the Design and Verification community in Europe starts at Munich, Germany this year on Oct 14-15, 2014. The focus of the conference would be on Electronic System Level (ESL), Verification & Validation, Analog/Mixed-Signal, IP reuse, Design Automation, and Low Power design and verification. To know more about what you’ll see at the conference hear it in the words of Martin Barnasconi, General Chair DVCON Europe here.

Call for abstracts – submission deadline over.

Registrations – Open.

This new move from Accellera Systems Initiative opens up opportunities for thousands of engineers who have benefited from the proceedings of DVCON for a long time to get involved, contribute and learn for a better tomorrow. As Benjamin Franklin rightly said,

Tell me and I forget.

Teach me and I remember.

Involve me and I learn.

An excellent opportunity for all of us to get involved & learn!

Trishool for verification

It’s the time of the year when I try to correlate Mythology with Verification. Yes, festive season is back in India and this is the time when we celebrate the fact that good prevails over evil. Given the diversity of Indian culture, there are a variety of mythological stories about demigods taking over evil. Well for us in the verification domain, it is the BUG that plays the evil preventing us from achieving first silicon success. While consumerism of electronic devices worked wonders in increasing the size of business, it actually forced the ASIC teams to gear up for developing better products in shrinking schedules. Given that verification is the long pole in achieving this goal, verification teams need a solution that ensures the functionality on chip is intact in a time bound fashion. The rising nature of design complexity has further transformed verification into a diverse problem where a single tool or methodology is unable to solve it. Clearly a multi pronged approach.... a TRISHOOL is required!

 

 

TRISHOOL is a Sanskrit word meaning 'three spears'. The symbol is polyvalent and is wielded by the Hindu God Shiva and Goddess Durga. Even the Greek God of sea – Poseidon and Neptune – the Roman God of the sea, are known to carry it. The three points have various meanings and significance. One of the common explanations being that Lord Shiva uses the Trishool to destroy the three worlds: the physical world, the world of culture drawn from the past and the world of the mind representing the processes of sensing and acting. In physical sense, the three spears would actually be fatal as compared to a single one. 

 

So basically we need a verification strategy equivalent to a Trishool to confirm that the efforts converge in rendering a fatal blow to the hidden bugs. The verification tools available today correlate well with the spears of Trishool and if put together would weed out bugs in a staged manner moving from IP to SoC verification. So which are the 3 main tools that should be part of this strategy to nail down the complex problem we are dealing with today?

 

Constrained RandomVerification (CRV) is the workhorse for IP verification & reuse of the efforts at SoC level makes it as the main spear or the central spear of the verification Trishool strategy. CRV is further complimented by the other two spears on either side i.e. Formal Verification and Graph based Verification. The focus of CRV is more at the IP level wherein the design is stressed under constraints to attack the thought through features (verification plan & coverage) and also hit corner cases or areas not comprehended. As we move from IP to SoC level, we face two major challenges. One is repetitive code typically combinational in nature where Formal techniques can prove the functionality comprehensively and in limited simulation cycles. Second is developing SoC level scenarios that cover all aspects of SoC and not just integration of IPs. The third spear or graph based verification comes to rescue at this level where multi processor integration, use cases, low power scenarios and performance simulations are enabled with much ease. 

 

Hope this festive season while we enjoy the food & sweets, the stories and enacts that we experience around will also given enough food for thought towards a Trishool strategy for verification.

 

Happy Dussehra!!!

 

Related posts -

HANUMAN of verification team!

Mythology & Verification

Essential ingredients for developing VIPs

The last post Verification IP : Build or Buy? initiated some good offline discussions over emails & with verification folks on my visit to customers. Given the interest, here is a quick summary of important items that needs to be taken care of while developing a VIP or evaluating one. Hopefully they will further serve the purpose of helping you decide on Build vs. Buy J.

 

1. First & foremost is the quality of VIP. Engineers would advocate that quality can be confirmed by extensive validation & reviews. However, nothing can beat a well defined & documented process that ensures predictability & repeatability. It has to be a closed loop i.e. defining a process, documenting it & monitoring to ascertain that it is followed. This helps in bringing all team members in sync to carry out a given task, provides clarity to the schedule and acts as a training platform for new team members.

 

2. Next is architecture of the VIP. Architecture means a blue print that conveys what to place where. In absence of a common architecture, different VIPs from the same vendor would assume different forms. This affects user productivity as he/she would need to ramp up separately for each VIP. Integration, debugging & developing additional code would consume extra time & effort. Due to inconsistency across the products, VIP maintenance would be tough for the vendor too. A good architecture is one that leads to automation of skeleton while providing guidelines on making the VIP simulator and HVL+methodology agnostic.

 

3. With the wide adoption of accelerators, the need for having synthesizable transactors is rising. While transactors may not be available with initial releases of the VIP, having a process in place on how to add them when needed without affecting the core architecture of the VIP is crucial. The user level APIs shouldn’t change so that the same set of tests & sequences can be reused for either simulator or accelerator.

 

4. While architecture related stuff is generic, defining the basic transaction element, interface and configuration classes for different components of the VIP is protocol specific. This partitioning is essential for preserving the VIP development schedule & incorporating flexibility in the VIP for future updates based on customer requests or protocol changes.

 

5. Talking about protocol specific components, it is important to model the agents supporting a plug & play architecture. Given the introduction of layered protocols across domains, it is essential to provide flexible APIs at the agent level so as to morph it differently based on the use cases without affecting the core logic.

 

6. Scoreboard, assertions, protocol checkers & coverage model are essential ingredients of any VIP. While they are part of the release, user should be able to enable/disable them. For assertions, this control is required at a finer level. Also, the VIPs should not restrict use of vendor provided classes. The user should be able to override any or all of these classes as per requirement.

 

7. Debugging claims majority of the verification time. The log messages, debug & trace information generated by the VIP should all converge in aiding faster debug and root causing the issue at hand. Again not all information is desired every time. Controls for enabling different levels based on the focus of verification is required.

 

8. Events notify the user on what is happening and can be used to extend the checkers or coverage. While having a lot of events helps, too many of them affect simulator performance. Having control knobs to enable/disable events is desirable.

 

9. Talking about simulator performance, it is important to avoid JUGAAD (work around) in the code. There are tools available that can comment on code reusability & performance. Incorporating such tools as part of the development process is a key to clean code.

 

10. As in design, the VIP should be able to gracefully handle reset at any point during operation. It also needs to support error injection capabilities.

 

11. Finally, a detailed protocol compliance test suite with coverage model needs to accompany the VIP delivery.

 

These are essential ingredients. Fancy toppings are still possible to differentiate the VIP from alternate solutions though.

 

Looking for more comments & further discussions ....

 

Relevant posts -

Verification IP : Changing landscape - Part 1

Verification IP : Changing landscape - Part 2

Choosing the right VIP

 

Verification IP : Build or Buy?

Consumerism of electronic products is driving the SoC companies to tape out multiple variants of products every year. Demand for faster, low power, more functionality and interoperability is forcing the industry to come up with standard solutions for different interfaces on the SoC. In past couple of years, tens of new protocols have shown up on silicon and equal no. of protocols has been revised spreading their description to thousands of pages. Reusability is the key to conquer this level of complexity both for design and verification. The licensing models for IPs & VIPs vary and many design houses still are in the dilemma on ‘Make vs Buy’ for verification.

 

Why BUILD?

 

Points that run in favour of developing in-house VIP solutions include –

 

- Cost of licensing the VIP that front loads the overall design cost for a given project.

- Availability of VIP for a given HVL, methodology & simulator.

- Encrypted VIP code aggravates the debug cycle delaying already aggressive schedules.

- VIP & simulator from different vendors lead to further delay in root causing issues.

- Verification environment developed with a VIP ties you to a vendor.

- DUT specific customizations need to be developed around the VIP. Absence of adequate configurability in available solutions poses a high risk to verification.

 

Why BUY?

 

While obvious, reasons why to procure the VIP include –

 

- Reusability advocates focusing on features that differentiate the final product and leave the innovation on standard solutions to relevant experts.

- Developing a VIP comes with a cost. A team needs to be identified, built and maintained all throughout with a risk that attrition would lead to risk at critical times.

- Time to market is important. Developing/upgrading in house VIP may delay the product itself.

- For new protocols or upgrades to existing ones, there would be a ramp up associated with protocol knowledge and this increases the risk with internally developed solutions.

- Probability of finding a bug and the end product being interoperable is high with third party solutions that have experienced different designs.

- Architecting a VIP is easier said than done. Absence of an architecture & process leads to multiple issues.

- In house solutions may not be reusable across product lines (different applications) or projects due to missing configurability at all levels.  Remember verification is all about JUGAAD and such philosophy doesn’t work with VIP development.

- With increasing adoption of hardware acceleration/emulation for SoC verification, there is need to develop transactors to reuse VIP leading to additional effort which otherwise would be done by vendor.

- Poorly developed VIP can affect the simulator/accelerator performance badly in general and at SoC level in particular. This in turn would affect the productivity of the team. To be competitive, vendors would focus on this aspect which is otherwise missing with internal solutions.

- External solutions come with example cases and ready to use env giving a jumpstart to verification. For in-house solutions the verification team may end up experimenting to bring up the environment adding to delays.

 

Clearly the points in favour of BUY outweigh the BUILD ones. Infact the ecosystem around VIP is evolving where solutions are available to the issues favouring MAKE too. With standard HVLs and methodologies like UVM, simulator agnostic VIP is relatively easy to find. Multiple VIP vendors and design service providers with a VIP architecture platform are getting into co-development of VIPs to solve the problem of specific language, methodology, encryption and availability of transactors for acceleration. Customization of VIPs to address DUT specific features or enable transition from one vendor solution to another is also on the rise through such engagements.

 

With this, the debate within the organization needs to move from BUILD vs BUY to defining the selection criteria for COLLABORATION with vendors who can deliver the required solution with quality at desired time.

 

In case you still are planning to build one, drop your comments on why?

 

Relevant posts -

Verification IP : Changing landscape - Part 1

Verification IP : Changing landscape - Part 2

Choosing the right VIP