Hopefully, v3 would implement some sort of ATVG but this is a complex algorithm with several steps, the first of them is to extract the netlist from the "blackbox" of the DUT (Design Under Test). The current version 2.2 is not yet able to do that and the chosen approach is to not analyse the DUT's file themselves, but only use "functional/behaviour" data obtained from 1) running the DUT 2) extracting and injecting information at the inputs/outputs and the gates themselves.

To extract the netlist, I don't intend to use simulator-provided internal feature. I have chosen the following "greybox" method :

• list all the gates, add inputs and outputs
• exclude all the LUT2 and LUT1 gates (inverters, buffers, GND, VCC) because they contribute no useful information
• Clear all the larger LUTs (with 2 and 3 inputs), set LUT2s as pass-through
• For each of the inputs and gates, select 7 of them and assign to their output the value '0', '1', 'W', 'Z', 'L', 'H' or '-' (so we can test 7 gates simultaneously)
• Send "all 'U' " then "all 'X'  " values at the inputs to force the refresh of all the gates => these values will propagate (pass) through the whole design. However, the gates that have a different value will see their value propagated to the inputs of other "sink" gates.
• Scan all the gates and check their histogram to see which value they receive at their output. If one of the values "01WZLH-" is received, add the n° of the current gate to the list of "sinks" of the sending gate (there would be an array to store this info, which is refreshed for every iteration of the algorithm)
• After all the inputs and gates are scanned, each of them should have a list of their sources and sinks gates.

The current code requires many modifications to permit this : for example, the lookup functions in the gates will be deeply altered and the global list of gates will have to hold much more information, in a better structured way. I also want to get rid of the the various architectures of gates and merge some code, which will make the library easier to use and probably even smaller. Hopefully I can find an easy yet efficient way to avoid having the "trace" architecture.

And of course, I must add the ALU8 as a 3rd example :-)

Let's do it...

It's only a preliminary version where there is only a single architecture, more upgrades will follow.