Source: EEWeb
By Lauro Rizzatti | Posted: May 15, 2018
As one panelist stated: “Shift left? Yes, we are doing it. Yes, it’s been incredibly effective. Yes, it’s been incredibly painful.”
A prominent theme at DVCon in February was the broad adoption of the “shift-left” methodology to accelerate embedded software development. (Note: In this context, the term “shift left” refers to an approach to software and system testing in which testing is performed earlier in the lifecycle; i.e., moved left on the project timeline.)
Several speakers in keynotes, sponsored lunches, and panels discussed hybrid emulation and its effectiveness to accelerate the shift-left software testing methodology. Among them was one speaker who gave a clear definition of hybrid emulation: “Hybrid technology consists of cropping the processor from the design and running it in virtual mode on the workstation while keeping all the remaining design hardware in the emulator.”
According to the speaker, software developers don’t like waiting to debug their code, and a hybrid solution allows them to debug faster. The shift toward making things more software focused has changed how hardware design is done. Much of this is already in place today and the trend will continue in the upcoming future.
Many of the speakers raved about the virtues of virtual platforms. The advantage of this method is that virtual models are generally available early in the verification cycle. A designer creates a hybrid emulation model taking register transfer level (RTL) code and integrating it with the virtual platform with no other dependencies and no need to integrate it with a system-on-chip (SoC) model.
As a result, the designer is shifted left by weeks or months. Because the intellectual property (IP) block is brought up in this hybrid model, the designer knows what is required, what workarounds might be needed, and what register settings might be necessary to make it work inside a SoC. All of this information can be sent over to the team building a SoC model for completeness and other purposes.
Another side benefit is that hybrid emulation frees emulation capacity. With a hybrid emulation approach, a designer can model RTL blocks as virtual models and remove significant chunks of the design from the emulator, thereby freeing-up capacity for other users.
Another speaker said that, while it took several weeks to implement, one company was able to shift left by about 10 weeks for the first model availability before the SoC model. And, when using the hybrid model, the Windows kernel driver was brought up one week earlier than anticipated.
Seconding this speaker was another from the same company who claimed the company performed emulation, hybrid emulation, and virtual platform work as it tried to validate the embedded software as early as possible to get the product out as fast as possible. A “must” in order to be competitive, he added.
He also stated that, for system-level work, emulation is too slow. The alternative is hybrid emulation done as early as possible starting at the IP level, getting the system software working there before it’s delivered to the SoC team for integration.
During one panel, all participants agreed that emulation today is mandatory and taking a larger and larger role. The representative of a large IP company claimed it performs emulation of single components and aggregating them into larger systems at the system level. The company emulates either entirely RTL-based IP inside of an emulator and performs a good amount of hybrid emulation combining fast models together with emulation to simulate more and more of the system.
He continued his point by explaining that software is the big unknown, and there’s only so much software a designer can run before an IP block ships to partners to design their systems. His advice is to come up with a way to get more software in the picture and do what it takes to validate it from a high-level system perspective. That’s an important role that emulation can play because it’s the only technology capable of scaling up to that size with the advances that the electronic design automation (EDA) companies are making.
Riding the hybrid emulation bandwagon does not come free, a panelist pointed out. He stated that moving toward a world where using hybrid technology combining software and hardware is posing a problem because hardware designers cannot do their designs in isolation. Hardware designers and software developers have to work closely to model their designs in software to make sure they are accurate and compatible. The world where hardware is in one place and software is in another place is gone. Today, there is much tighter integration between hardware and software.
Expressing a somewhat different angle was another panelist who reported that big designs are chopped into pieces using a knife to give them clean interfaces. From a hardware designer perspective, the biggest contribution is clean boundaries between system, subsystems, and IP. Furthermore, clean interfaces used for breaking systems up into smaller chunks make for easier integration.
Hybrid emulation is becoming a critical component of the shift left movement. One panelist stated: “Shift left? Yes, we are doing it. Yes, it’s been incredibly effective. Yes, it’s been incredibly painful.”
Technical challenges, for certain, he noted, but the hardest part is the cultural aspect. Dragging teams who are used to doing things in pre-silicon environments that are slow, along with software teams who just want to run at light-speed all the time, into shift left is a daunting task. “Trying to culturally make them accept these kinds of slow domains is challenging. Verification engineers think they are thousands of times faster, but shift left movers think they are just incredibly slow and this is probably one of the biggest issues.”
“Shift left has been successful,” asserted another speaker. “The challenge with looking left from engineers on the right is to get them on board with the shift left idea. From their perspective, things are slow. When they are told to shift left, they are asked to stretch left because what takes two hours to do in the environment they are used to could take two weeks in shift left. They will be doing it two quarters, three quarters earlier but it’ll take longer. This means more time needs to be allocated to accomplish the feat.”
Despite the proven success of the shift-left adoption, there is a resistance to adopt it. When pulling things left starts, teams used to working on real silicon are now working in a slow pre-silicon environment. The problem is the cycle for those teams and how they work is out of sync.
One panelist proposed a solution to ease the path to adoption: When starting the shift-left strategy, the only way to succeed is to put everyone on one team. With new tools, a team can be built with that focus. If the culture changes at the same time as introducing a different methodology, it is hard to succeed with so many changes.
Along the same lines, another panelist had a final point, “It’s not a matter of when in the design cycle there’s a decision to start doing shift left. It should be a push as much as possible, as early as possible, and the earlier real-world cycles are running against real designs, the better the end cycle will be. Getting the resources lined up to properly to do that is always a big challenge, but as soon as the resources are allocated, get started.”