How Debug Breakthroughs are Enabled by In-Circuit Acceleration

We in product management are often accused of jumping the gun and announcing products too fast. Users are looking at press releases and are wondering "sounds great, but does it really work?" Cadence announced earlier this week new in-circuit acceleration capabilities to our System Development Suite, for which my team owns the product management. We are happy to report that we are actually announcing those capabilities late - they are in customer hands and well into adoption! Our customers will also talk about their use-models at the upcoming Design Automation Conference in San Francisco during a special breakfast for which you can sign up here.

So what is in-circuit acceleration?

In-circuit acceleration offers the best of simulation-acceleration and in-circuit emulation. Simulation acceleration is traditionally used earlier in the design flow, at a time when the test bench is available, RTL is synthesizable and can be mapped and executed in hardware like our Palladium XP Verification Computing Platform (PXP). We have seen acceleration speeds ranging from 10X to a maximum of 1,000X for such an accelerated design. Despite dedicated simulation acceleration channels between PXP and the hosts, the test bench and communication back and forth really determines the overall speed. Later in the design cycle, in-circuit emulation finds its application. The chip under development  is mapped into PXP and connected with rate adapters to external mother boards, USB and PCI interfaces. It is stimulated either by synthesizable test benches or by executing real application loads, like booting an Android or Linux operating system.

Traditionally, both environments had to be maintained separately. Design teams were forced to create and maintain both environments, spend unnecessary time and effort to reproduce bugs, or remodel all system components targeted for one environment - tasks which are not time effective and make sub-optimal use of the existing IP assets. In-circuit acceleration resolves those issues and enables teams for simulation acceleration and emulation to deploy a common unified verification environment. The technology under the hood enables both environments to live in parallel in PXP and allows users to assign the different components of their design to the two environments. In addition - and that's the crucial piece - users can establish connections between the two environments to move data back and forth.

With both environments living in parallel and being constrained by their own worlds, interesting new possibilities emerge, ranging from just combining different IP assets to building the design under development to allowing advanced instrumentation at full in-circuit emulation speeds.

The latter use model of instrumentation enabled by in-circuit acceleration has already been reported on by Alex Starr from AMD during the March 2012 CDNLive! in San Jose. The presentation was called "Enabling a new paradigm of system-level debug productivity while maintaining full in-circuit emulation performance."  Alex reported that emulation has been used to reduce time to market for their products for more than six years. It improves design health and post silicon infrastructure readiness, and enables software development.

The problem Alex then described is related to debug capabilities and complexity of designs. He mentioned that debugging designs on hardware emulators today is a challenge when compared with software simulation capabilities, and it becomes more and more challenging as design complexity increases. Large workloads, such as OS boots, driver testing, and application code make the problem even harder. The problem for debug now becomes like a needle in a haystack! Where and when does the user create waves? The faster the emulation technology becomes, the worse the problem becomes as the haystack only becomes bigger, and as a result users are demanding more debug visibility.

To emphasize the problem he is facing, Alex described the traditional emulation debug cycle in his world at AMD. During the debug of large workloads, users initially might have collected a set of data to analyze, but may have missed the failure point. Now they have to schedule their multi-hour job again and collect a new set of data, of course once they figured out how to trigger at the right time and place. The next available time on the emulator may be some time away, and with a wrong trigger point the next round would potentially not be more successful in getting the right data.

From here Alex essentially defined the requirements of a solution for which in-circuit acceleration fits well. The solution needs to be able to abstract data to be relevant for end user debug, and needs to function with dynamic targets the hardware is interfacing to - and the design clock cannot stop. The solution needs to maintain existing in-circuit emulation speeds, and allow capture of the relevant design nodes of significance needed for system-level debug.

Alex then described how his team built based on in-circuit acceleration a synthesizable transaction streamer connecting the data which are collected at full speed in the in-circuit emulation domain to the simulation acceleration environment. From there a dedicated simulation-acceleration channel presents data to the host for lossless monitoring and visualization. He referred to the capability AMD built using in-circuit acceleration as Virtual Logic Analyzer, effectively increasing debug visibility to the capabilities provided in classic simulation acceleration, while maintaining the speed of classic in-circuit emulation. The principle of the configuration is shown in this picture here:

So where does this take Cadence and the System Development Suite? Introduced last year as a set of connected platforms, the System Development Suite is evolving. We eventually want it to become a fully heterogeneous open, connected and scalable system-level development environment. With in-circuit acceleration we have taken a significant step to get closer to that vision. We have effectively made the Incisive Functional Verification Platform and the Verification Computing Platform Palladium XP a heterogeneous set of engines in which users can choose where to map instrumentation, high-level models, RTL, silicon targets and rate adapters which connect to the outside world.

The resulting new use models based on in-circuit acceleration are much broader than the debug centric example above. And best of all - we already have users using our technology successfully at the time as we are announcing it.

The presentation for the CDNLive! AMD paper is available to Cadence Community members here. In addition, customers will also talk about their use-models for in-circuit acceleration at the upcoming Design Automation Conference in San Francisco during a special breakfast for which you can sign up here.

Frank Schirrmeister