Get email delivery of the Cadence blog featured here
You may be a software engineer and not even know it. If you develop IC verification environments, the way you write and optimize code has a tremendous impact on simulation performance. A recently archived Cadence webinar provided a number of practical tips to help you analyze and optimize Universal Verification Methodology (UVM) environments to boost simulation performance and reduce memory usage.
The webinar is titled "Excellerating UVM." As Adam Sherer, product management director at Cadence, explained, "excelleration" combines the words "excellence" and "acceleration." However, this webinar has nothing to do with hardware acceleration and everything to do with best practices for developing SystemVerilog UVM environments. It also provides a sneak peak of an advanced profiling capability that will be part of an upcoming Cadence Incisive simulation release.
When evaluating performance needs, Sherer said, it's important to look at the entire verification flow. With IP block verification, compilation and elaboration is relatively fast, and time will be spent analyzing, debugging, and fixing bugs. When verification moves to subsystems and SoCs, the verification environment gets more complex, and compilation and elaboration become more of a bottleneck. It's important to optimize tests across the entire verification cycle.
Sherer asserted that UVM is a software engineering project. "In the SystemVerilog space we're dealing with software engineering. There's no way to avoid that," he said. This is because poor coding styles will lead to poor simulation execution, and good coding practices will enhance performance. Sherer suggested that IC verification engineers should use profiling to analyze and boost performance, just as software engineers do. He noted how he once reduced simulation time by 20% just by in-lining code, a common software development practice.
5 Tips for Better Simulation Performance
Sherer provided these tips for optimizing performance and memory usage:
1. Static vs Dynamic Classes
SystemVerilog has garbage collection, which is good. But if you use it repeatedly, memory can become fragmented. This can happen if classes are repeatedly created and destroyed. One solution is to statically allocate classes. Another is to create a pool of classes and instead of enabling it for garbage collection, park it in an array.
2. Know the Class Hierarchy
If you're reusing verification IP from outside your design group, and classes are not well defined, it can turn into a performance nightmare. Methods and data in base classes exist in all derived classes, and methods you use in derived classes can have a dramatic effect on performance. The solution is to demand documentation - and supply it.
3. Track Class and Data Handles
Garbage collection in SystemVerilog works only if properly managed. The number of references to the class handle should fall to zero. Poor handle control is the leading cause of memory leaks, especially in dynamic and associative arrays. Solution: Add checks to code to detect overflows from these arrays, and be wary of global data, especially as multiple threads operate on a single data structure.
4. Thread Pool vs. Create/Destroy
Execution threads can experience handle issues and memory fragmentation, just like data and classes. Solution: follow similar techniques to #3 above when implementing very high thread-count environments.
5. Unforeseen Library Overhead
It's important to understand how the UVM library works, and to keep an eye on library implementation as the verification environment scales up. Otherwise the environment may turn out to be inefficient - for example, a testbench channel may be sending many tiny bits of data. The solution is to always implement functional code first. If performance issues arise, profile and consider alternate algorithms that better utilize library interfaces.
Chinmay Banerjee, principal solutions engineer at Cadence, offered an overview and demonstration of the upcoming advanced profiler capability. He noted that Incisive already has a simple built-in profiler, but the information it generates is limited because it needs more instrumentation. In the past, it has primarily been used to generate reports to Cadence R&D so engineers can make the tool run faster.
But now, Banerjee said, verification environments are so complex that users are concerned about optimizing their code to get better performance. "The idea of the advanced profiler is to make it more user friendly so users can figure out and demonstrate if there is an issue in the code, or if there is performance that could be improved in the simulator itself," he said.
Banerjee walked through the new features provided by the profiler, including a high-level dashboard, instance-based profiling, a closer tie with the user's HDL code, and a call graph for UVM that can be used to debug functions. The demo showed how users can pinpoint blocks of code that are taking up (in one example) 60% of the simulation time.
In conclusion, Sherer noted that two functionally equivalent algorithms can have very different performance characteristics. His advice for developing optimal UVM environments:
To listen to this informative one-hour webinar, click here (quick and free registration required if you're not a Cadence Community member).