Dynamic Mutation Schemata

We propose an extension to the original mutation schemata [63] which has been introduced in the background chapter. The resulting process is called dynamic mutation

schemata.

For the convenience of presentation, we first introduce several notations for basic HDL simulation and mutation schemata, as elementary constructs. We then define the dynamic mutation schemata process based on these notations.

Notations for Original Mutation Schemata

For a HDL design under verification 𝐷 to be simulated, we first use:

 𝐷0⇐ 𝑆𝑖𝑚𝐼𝑁𝐼𝑇(𝐷) to denote the execution of a HDL simulation initialization phase

for design 𝐷 , with the result notated as 𝐷0, i.e. the whole state of 𝐷 after

initialization.

 𝐷𝑡+1⇐ 𝑆𝑖𝑚(𝐷𝑡) , where 𝑡 = 0,1,2,3, … is used to represent the execution of one

HDL simulation cycle at 𝑡 + 1, which changes the state of 𝐷 fron 𝐷𝑡 to 𝐷𝑡+1.

Note that 𝑆𝑖𝑚𝐼𝑁𝐼𝑇 and 𝑆𝑖𝑚 represent a simulation with specific tests, without the tests

attached to the notation.

Recall that in mutation schemata, all mutants are encoded into one meta-mutant, each with a unique mutant ID. This ID should be designated to select the corresponding mutant for simulation. We use:

 𝑀𝑀 to denote the meta-mutant and 𝑀𝑀𝑘 to represent mutant 𝑘 by assigning the

mutant ID for 𝑀𝑀 to be 𝑘 ∈ [0, #_𝑜𝑓_𝑚𝑢𝑡𝑎𝑛𝑡𝑠]. During simulation of 𝑀𝑀𝑘, only

the mutated statement with ID 𝑘 is used, with all the other mutations unmasked and the original statements executed.

 When mutant ID 𝑘 is assigned 0, 𝑀𝑀0 represents the meta-mutant with all

mutation masked. Simulation of 𝑀𝑀0 has the same trace as the original design 𝐷.

 𝑀𝑀𝑘,0⇐ 𝑆𝑖𝑚𝐼𝑁𝐼𝑇(𝑀𝑀𝑘) and 𝑀𝑀𝑘,𝑡+1⇐ 𝑆𝑖𝑚(𝑀𝑀𝑘,𝑡) according to the notation

above for HDL simulation, with 𝑀𝑀𝑘 as the design.

Extension as Dynamic Mutation Schemata

We propose an extension to this original mutation schemata, as shown by Figure 4.6. We call it dynamic mutation schemata, since in the mutation analysis process, the meta- mutant is continuously simulated as a main thread and the simulations of individual mutants are dynamically forked and ended, if they are activated during meta-mutant simulation.

At the beginning, we have only 𝑀𝑀0 launched for simulation, with tests consistently

generated as input from our random test generator. After initialization, 𝑀𝑀0 is simulated

at each cycle. In the illustration of Figure 4.6, we assume that the design is synchronized at each clock rising edge.

Note that during 𝑆𝑖𝑚(𝑀𝑀0,𝑡), we are able to determine for each mutant whether it was

activated, and by which test it was activated. A list 𝐿𝑖𝑠𝑡𝑎𝑐𝑡𝑖𝑣𝑎𝑡𝑒𝑑 can be recorded as

𝐿𝑖𝑠𝑡𝑎𝑐𝑡𝑖𝑣𝑎𝑡𝑒𝑑 = (⋯ , (𝑀𝑀𝑖, 𝑡𝑒𝑠𝑡𝑀𝑀_𝑖), ⋯ )

where 𝑡𝑒𝑠𝑡𝑀𝑀𝑖 represents the test that activated mutant 𝑀𝑀𝑖. This should be possible, if

Figure 4.6 Dynamic mutation schemata for HDL mutation analysis.

Dynamic Mutation Schemata:

①

At each cycle ②

during which we obtain

(⑩ adapt test generation with ) For each running forked mutant simulation:

⑥

⑦compare ,

⑧if no deviation found, delete and unmask in ⑨if deviation at design output, delete as it is killed For each activated in

③update ④

⑤mask in as separate-running and no-check-for-activation

1

, during which and were activated by and , respectively 2 4 3 8 5 9 6 c t 7

during the meta-mutant simulation, i) we calculate a mutated statement in parallel to the original one, for a comparison to see whether the mutant is activated ii) for each design sub-unit, we maintain a record which test is currently resident at this unit. For example for a microprocessor design simulation, in each pipeline unit there should be a corresponding instruction that is currently executed by this unit. We assume that such a record can be maintained during simulation, for any pipelined design. Then, when a mutant is activated during meta-mutant simulation, we know the test that is responsible for the design unit containing this mutant.

For each activated 𝑀𝑀𝑖 from 𝐿𝑖𝑠𝑡𝑎𝑐𝑡𝑖𝑣𝑎𝑡𝑒𝑑, we first update the record entry of that

mutant-activating test: 𝑁𝑎𝑐𝑡𝑖𝑣𝑎𝑡𝑖𝑜𝑛 in (𝑡𝑒𝑠𝑡𝑀𝑀𝑖,, 𝑁𝑎𝑐𝑡𝑖𝑣𝑎𝑡𝑖𝑜𝑛) is increased by 1.

Then, we try to fork a continuing simulation for 𝑀𝑀𝑖, from the current meta-mutant

simulation. For this, we further assume the availability of a fork functionality: 𝑀𝑀𝑖,𝑡⇐

𝐹𝑜𝑟𝑘(𝑀𝑀0,𝑡, 𝑖), which first creates a copy of 𝑀𝑀0,𝑡 and then change the mutant ID of this

copy from 0 to 𝑖. Such a fork is possible, since mutant 𝑖 has never been activated until 𝑡 and, therefore, 𝑀𝑀0,𝑡 and 𝑀𝑀𝑖,𝑡 should represent the same design state in such a case.

The activated and forked mutants are masked in the meta-mutant simulation, since they are now simulated in separate threads and no longer required to be checked for activation. Each such forked mutant simulation thread, say 𝑀𝑀𝑗, is simulated at every clock cycle:

𝑀𝑀𝑗,𝑡+1⇐ 𝑆𝑖𝑚(𝑀𝑗,𝑡). The result 𝑀𝑀𝑗,𝑡+1 is compared to 𝑀𝑀0,𝑡+1 from meta-mutant

simulation. There are just two outcomes from this comparison:

 If no deviation is found between them, it means that the simulation of mutant 𝑀𝑀𝑗

has converged back to the meta-mutant simulation. That thread for simulating 𝑀𝑀𝑗 can be aborted. We unmask it in 𝑀𝑀0 to resume the activation-checking for

𝑀𝑀𝑗.

 If any deviation appears at design output, it means the activation has been successfully propagated and, by definition of mutation analysis, mutant 𝑀𝑀𝑗 is

killed.

The main advantage of this dynamic mutation schemata is the saving of simulation time for HDL mutation analysis. Individual mutants are simulated in a dynamic, just-in-time manner, based on meta-mutant simulation.

At the end, we are able to compile the input for the adaptation heuristic: (𝑡𝑒𝑠𝑡, 𝑁𝑎𝑐𝑡𝑖𝑣𝑎𝑡𝑖𝑜𝑛) for each 𝑡𝑒𝑠𝑡, which are consistently updated during our dynamic

mutation schemata. Note that we should trigger the adaptation heuristic only when a 𝑡𝑒𝑠𝑡 will no longer receive any activation update.