I just uploaded A3Ptiles_v2.3_20191124.tgz but this is only an interim version.

The good part : I added a more complex circuit to test, the ALU8 has 83 gates, it is more rich and interesting than the INC8 unit (only 13 gates).

The bad part : I encounter cases that I didn't expect. By design, some gate configurations do not exist in the ALU8 and this creates a new situation. I need a way to explicitly tell the simulator that these cases don't occur, or modify the design to take these cases into account.

With this new situation, the system I created for INC8 (with a simple bash script) will not work at all because some cases will not be testable...

Anyway, the tool already proves its worth, because I focus on logic flaws I didn't see coming. The histogram is not just a gadget :-)

20191126 :

I tried one method to reduce the problem : I substitute the offending gates with a composite gate.

Most of the problems appear with AO1 : so I replaced them all (in the ALU8) with :

-- AO1 => Y := (A and B) or C;
architecture combi of ao1_combi is
  signal t : std_logic;
begin
 e_a: entity AND2 port map(A=>A, B=>B, Y=>t);
 e_o: entity OR2  port map(A=>C, B=>t, Y=>Y);
end combi;

It seems to solve most of the problems and the exhaustive fault injector can deal with fewer problems.

However some problems will always remains, "by design", the best example is with testbenches that only test a subset of the signals and decode into mutually-exclusive signals.

So I must add a mechanism to instruct the gate that some states are illegal...

What is the best way to transmit the information about the gates ?

• The easiest method is with a port. A std_logic_vector or string is an "optional" port, which can be left "open".
• A generic is another easy way to inject additional information with "default" value when not used.

Both of these methods create one problem : backwards compatibility is not preserved and they require the use of "if generate"s constructs to let the netlist source code run with the original simulator... But is it a real problem ?

Another method would be to use an external file with a list of gates-inputs to ignore. It's much more complicated though but opens the way to automatically generate the list from the histogram.

It seems that both methods are complementary so I'll have to implement them both...

I have chosen the generics mechanism to provide an inline "exclusion list", with an unbounded std_logic_vector as parameter. Every 'X' becomes an entry to exclude. The list can be empty, of course. In the first simple test, here is one example:

x5: entity xor3  generic map(exclude=> "X-X-X-X-")
              port map(A => D, B=>G, C=>H, Y=>Y );

Backwards compatibility is broken but it could be solved with a "if-generate" if ever needed.

Now I work on making sure everything works well like before.