EDA Hates C++. Wait, What – Back Up!

Why is Accellera supporting the use of an industry standard language in the development of the Portable Stimulus Standard?

Many of you remember the wave of anticipation when SystemC was created. A new language at a higher level of abstraction compared to Verilog and VHDL that would enable faster simulation earlier in the design flow and usher in the next generation of EDA tools based on transaction-level programming. In addition, the language was open source so a whole new level of innovation would become possible and enable start-ups to add value along with products from the major EDA companies.

Unfortunately, for all of the promise, very little actually happened. The problem was that it was based on the most popular programming language (C++) and the class library necessary to turn that language into a fully functioning simulator was given away for free. Since the C++ compiler is free on most machines used within the industry, the total cost for the simulator is zero. Simulation is one of the bread-and-butter products for EDA companies and that source of revenue had just been taken away from them.

No wonder that few of them were willing to invest a lot in it, or provide the other tools necessary, such as debug, which are not revenue generating in the same manner. While some synthesis tools use SystemC as an input language, they can only tackle a limited number of parts of an SoC. In addition, some companies are finding value in virtual prototypes based on SystemC.

With this as a backdrop, you may not be surprised to hear about one of the sticking points within the Accellera Portable Stimulus Working Group. Some EDA companies wanted to create a new proprietary language, but Breker, in response to customer’s encouragement, demonstrated that everything could be done in C++. The committee decided that both would be supported and have common semantics. Why ever would they do that again and kill another source of revenue for EDA? Had we not learned our lesson from the first time?

The answer is actually very simple. While the language would be standard C++ and the class library API could be made available as an open source header file, it does not actually compile into anything that can be executed. It is not a program per se. It is a specification of verification intent from which a scenario can be generated. It is thus an input language to a tool and the capabilities of the tool are not being specified by the committee. That means that EDA companies will have to compete on the number of innovations they embed into their tool suite. The input language only becomes the means by which that verification intent is defined and is portable between all of the vendors.

In my previous blog, we talked about some of the stakeholders in PSS.  In this blog we will concentrate on what such a tool would do. The input description defines the control and data flows for all usage scenarios supported by the SoC. When the tool is invoked it is supplied with additional constraints about the type of scenario you want to generate. This might be as simple as having a DMA do a memory to memory data move, or as complex as having a processor create a data structure that is encrypted by a crypto block and then sent to a modem.

The tool then has the task of generating a self-checking test scenario. This includes finding a random, but legal, path through the graph to satisfy the constraints provided. This defines the scenario that will be run. It may then generate software that will be compiled and executed on the processor cores contained within the SoC. In addition, there may be events that need to be injected into the SoC and it may be necessary to time these with things happening from within the SoC. This requires a testbench to be constructed that is capable of doing these things.

When completed, all of the pieces necessary to execute that test are in place including the results checking. At the completion of the test, the graph can be annotated to indicate which aspects of the system have been executed and this information may then be used to guide the generation of future test scenarios.

There is plenty of opportunity for innovation within such a tool. For example, a testcase targeting an emulator will be significantly different from one intended for a simulator and again there would be differences based on whether the simulator was at the register transfer level or transaction level. Another layer of complexity is also possible. A simply example may ask for a simple scenario that resulted in an image being displayed, but many SoCs are capable of running multiple scenarios at the same time. How can a test scenario be created that stresses the design to its limits? How do you schedule operations to ensure that the right things do actually occur? How do you create tests that target the parts of the design that you are most worried about?

These are tool questions and the flexibility and quality of the results generated will be how a user will decide if he wants to purchase a tool from vendor A or B. And this is where the innovation will happen. There may be other tools that help you to visualize the specification, to interface with tools that define register definitions, to collate and display system-level coverage information. The list is almost endless.

While the Accellera committee is working on the definition of the language, the most important thing is to define it in a way that does not limit what the tools are capable of doing. That is a very real danger with the specification of a proprietary language that has never been implemented and tested. Thankfully, having a language, in this case C++, as an alternative, it becomes possible to test the semantics of the proposed language using something the industry has a lot of experience with.

Help us to define this next generation of verification methodology by making sure we and the other EDA vendors are aware of all of your needs for such a solution. We are always interested in hearing your views either directly or as comments on this blog. Together we can make this happen.

Tags: Accellera, Breker, C++, emulation, path constraints, portable stimulus, Results Checking, scenario model, Self-checking test scenario, SystemC, Verilog, VHDL, virtual prototype

Category: Knowledge Depot

This entry was posted on Friday, November 4th, 2016 at 11:28 am. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.