Life on the Embedded-EDA Frontier

A month ago, our blog post on The Breker Trekker concerned life on the hardware-software frontier. We discussed the ever-shifting line between hardware and software and how we at Breker seem to be straddling that line as we generate embedded C/C++ test cases for hardware verification. Yesterday we published an article on the ongoing merger between the worlds of embedded systems and EDA. We made a number of observations about how the two industries are drawing closer together.

We didn’t talk about Breker in yesterday’s article, but today we’d like to connect these two threads and talk about how we are now straddling the increasingly fuzzy line between embedded and EDA verification. This is a topic we’ve discussed internally from time to time, and we have taken some steps into the embedded world by exhibiting at ARM TechCon and publishing articles in magazine and on sites geared toward embedded designers and programmers.

When we present our products to a new audience, one very common question is who actually runs our tools. Do we work with system architects, design engineers, testbench verification engineers, embedded programmers, or silicon validation teams? The simple answer is that we have worked with all of these people and more, but a deeper response is that it depends upon the nature of the chip being developed, the stage in the development process, and the goals the customer wants to accomplish.

If we’re running TrekUVM in a purely transactional mode, typically on a design without embedded processors, we generally work with traditional testbench engineers. They know SystemVerilog and the Universal Verification Methodology (UVM) cold, but they’re having trouble hitting their verification coverage goals. UVM constrained-random stimulus generation is like pushing on a rope. Our graph-based scenario models enable generation of test cases that automatically converge on key coverage targets.

When the chip being verified is an SoC with one or more embedded processors, going beyond the UVM is essential. It just doesn’t make sense to try to verify a processor-centric design from the testbench alone. Before Breker came along, engineers had to hand-write tests, usually in C/C++, to run on the processors in simulation. Usually these coders were the members of the verification team, since most of them knew C and were comfortable with object-oriented programming from SystemVerilog.

As SoCs became more complex, especially many-core designs with dozens or even hundreds of processors, we began to see embedded programmers joining the verification effort specifically to hand-write the tests for simulation. It was not uncommon for teams working later in the development process (emulation, FPGA prototyping, and silicon bring-up) to loan some engineers to the verification team for this purpose.  This is one example of how embedded and EDA are merging.

With Breker’s TrekSoC product in the mix, customers can now automatically generate complex test cases that include C/C++ code to run on the embedded processors, transactions to send data to and from the testbench, and a simulation run-time module to tie it all together. We commonly work with embedded programmers since they are already in place. However, we could argue that our high degree of automation also enables verification engineers who are not embedded experts. Our scenario models are written in C/C++, so there’s no new language to learn.

Once we go beyond simulation and simulation acceleration, we usually find that we are working with engineers more from the embedded world than EDA verification. The ultimate goal of emulation, prototyping, and silicon bring-up in the lab is usually to perform hardware-software co-verification by running production software (operating system, drivers, and applications) on the hardware platform. But it is a big step to get this running, and it is notoriously difficult to debug lingering hardware errors triggered by production code.

So the hardware teams almost always have some embedded programmers who hand-write specialized tests, often called diagnostics, to run on the platform. This is very time-consuming, plus it means that these programmers are not working on revenue-generating applications. Our TrekSoC-Si product is the perfect solution here. From the same scenario models used by TrekSoC, we can automatically generate test cases to run on any hardware platform. We still work with a few embedded programmers, but typically 80% of the team can be redirected to more profitable work.

Finally, when silicon arrives from the foundry there is usually a dedicated bring-up team working in the lab. These engineers certainly have embedded knowledge, but often members of the design and verification teams work alongside them to understand, reproduce in simulation, and debug any problems found. Again, the test cases generated by TrekSoC-Si are more thorough and more debuggable than any diagnostics, and a vital step toward getting production software running.

So, we work on most customer projects with one foot in the traditional EDA verification space and the other in the embedded domain. We’re comfortable in both places, working with any mix of engineers. When the time is right for you to take a look at Breker’s solutions, invite members from all your teams. Using the same input models and the same methodology, we generate test cases that bring value to everyone throughout the development process.

Tom A.

The truth is out there … sometimes it’s in a blog.

Tags: Accellera, Breker, device driver, EDA, embedded systems, functional verification, graph, graph-based, hardware, hardware-dependent software, HdS, portable stimulus, PSWG, realistic use case, scenario model, simulation, SoC verification, software, software-driven verification, test generator, use case

This entry was posted on Wednesday, September 2nd, 2015 at 11:27 pm. 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.