Thread data race detection and synchronization for parallel implementation of verification testbenches
A testbench for a design under test (DUT) includes components used to verify functionality of the DUT through simulation of the DUT. The components are grouped into component groups, and the components within an individual component group are executed on a same thread of the simulation. The component groups are also executed on a single thread, which includes logging accesses to memory by different component groups. Based on the logged memory accesses, a processing device identifies whether any component groups create a thread data race. An action is taken in response to identifying thread data races.
1 . A method comprising:
accessing a testbench for a design under test (DUT), the testbench comprising components used to verify functionality of the DUT through simulation of the DUT, wherein the components are grouped into component groups, and the components within an individual component group are executed on a same thread of the simulation;
executing the component groups on a single thread of the simulation, comprising logging accesses to memory by different component groups during the simulation;
identifying, by a processing device, based on the logged memory accesses from the simulation, whether any component groups create a thread data race in the simulation where component groups access same data in the simulation in a conflicting manner; and
taking an action in response to identifying thread data races.
2 . The method of claim 1 further comprising:
after taking the action, executing components from different component groups on different threads.
3 . The method of claim 1 wherein:
executing the component groups on the single thread comprises executing events from the component groups on the single thread; and
the logged memory accesses comprise one or more of: an address of the memory accessed, the component group for the event accessing the memory, and whether the access was a read type or a write type.
4 . The method of claim 1 further comprising:
checking a value of a flag for logging accesses to memory; and
determining whether to activate the logging accesses to the memory based on the value of the flag.
5 . The method of claim 1 wherein identifying whether any component groups create a thread data race accounts for thread locks.
6 . The method of claim 1 wherein executing the component groups on the single thread comprises: static allocation of global variables and static variables.
7 . The method of claim 1 wherein executing the component groups on the single thread comprises: dynamic allocation of class objects, and collecting the logged memory accesses upon release of the class objects.
8 . The method of claim 1 wherein the testbench is a UVM testbench, and the components comprise a plurality of Universal Verification Methodology (UVM) agents, UVM sequencers, UVM drivers and UVM monitors.
9 . The method of claim 8 wherein, as a default, each UVM agent is assigned as a separate component group.
10 . A system comprising a memory storing data and instructions and a processing device coupled with the memory and to execute the instructions; wherein the memory and processing device comprise:
a description of a design under test (DUT);
a testbench comprising components used to verify functionality of the DUT through simulation of the DUT; and
a simulation environment that compiles the testbench and the DUT into executable code and runs the executable code; wherein running the executable code comprises:
an initialization phase that runs the executable code on a single thread of the simulation, logs memory accesses, and identifies thread data races in the simulation from the memory accesses where components access same data in the simulation in a conflicting manner; and
a run phase that runs the executable code on multiple threads.
11 . The system of claim 10 wherein compiling the testbench and the DUT into executable code comprises:
adding instrumentation to the executable code to log the memory accesses.
12 . The system of claim 11 wherein the instrumentation is for memory accesses for static variables global variables, and class objects.
13 . The system of claim 10 wherein the testbench further comprises a component tree that defines a hierarchy of the components in the testbench, and compiling the testbench and the DUT into executable code comprises:
adding instrumentation to the executable code to provide access to metadata sufficient to recreate and make the component tree available during the run phase.
14 . The system of claim 13 wherein the metadata identifies components and their parent.
15 . The system of claim 10 wherein the run phase further comprises:
identifying the component associated with an event to be dispatched;
identifying a component group for the identified component, wherein the components within an individual component group are executed on a same thread but components from different component groups may be executed on different threads;
identifying a thread for the identified component group; and
dispatching the event for execution on the identified thread.
16 . A non-transitory computer readable medium comprising stored instructions, which when executed by a processing device, cause the processing device to:
run executable code for a design under test (DUT) and corresponding testbench on a single thread of a simulation of the DUT, the testbench comprising components grouped into component groups;
log memory accesses from the executable code during the simulation, and identify thread data races where executable code from different component groups access same data in the simulation in a conflicting manner, the thread data races identified from the memory accesses from the simulation; and
automatically take action relating to the identified thread data races.
17 . The non-transitory computer readable medium of claim 16 wherein the executable code comprises a plurality of code modules, and the actions taken include thread locking code modules that generate the identified thread data races.
18 . The non-transitory computer readable medium of claim 16 wherein the executable code comprises a plurality of code modules, and the actions taken include thread locking regions within code modules that generate the identified thread data races.
19 . The non-transitory computer readable medium of claim 16 wherein the actions taken include converting operations relating to the identified thread data races to standardized atomic memory access built-in functions.
20 . The non-transitory computer readable medium of claim 16 wherein the actions taken include generating thread specific objects to resolve the identified thread data races.