Close

What about coverage ?

A project log for VHDL library for gate-level verification

Collection of ASIC cells and ProASIC3 "tiles" in VHDL so I can design and verify optimised code without the proprietary libraries

yann-guidon-ygdesYann Guidon / YGDES 06/11/2019 at 22:060 Comments

As this library exceeds the initial limited scope, new perspectives emerge. It's good to have a library that replicates the historical Actel gates, it's awesome to inject faults, but now, what about we collect stats about the gates activities ?

Actel/MicroSemi/Microchip already does something similar during simulation to estimate power consumption but my idea is different : IF I'm going to alter a logic gate by 1 bit, then I need to know if this input combination really has a use. IF I can detect that an input combination is not used in practice, it could help simplify the gate for example. And it would also mean that it's useless to alter this bit.

So it's a "coverage" test, that gathers a histogram of the meaningful input combinations and helps direct test vectors toward rarely-seen cases (while the common cases are usually degenerate and are often covered "along" when the rare cases are tested)


Testing coverage requires a good testbench that stimulates all the inputs and intermediate signals.

Then, the testbench runs with all the gates tooled with a histogram (that could saturate at 255 or 64Ki). The trick is to sample these input values when the clock is about to change because the delta cycles will add transients with meaningless values. It makes the implementation harder because we don't want to add an additional clock input to each gate... but VHDL or VHPI can do wonders.

At each sampling point, the inputs of each gate are collected into a number (0 to 7) that serves as an index into the histogram, where one bin is incremented.

After the run, the histogram is collected and sorted, lowest bins first : these are the ones that the test vectors must "hit" with one test vector. If possible the test vector also hits more "low bins" to increase efficiency and reduce the number of test vectors (and testing time).

How a test vector can be created from a given target configuration is not yet easy or examined...

...

The list of vectors can then be used to enhance the testbench (or make another, hopefully shorter). Null bins are not used and thus are not tested because they would create a "false fail" condition. However the null bins are useful to detect design defects.

Discussions