Update: some "zombies" have an explicit solution, explained in https://hackaday.io/project/162594-vhdl-library-for-gate-level-verification/log/182670-time-travel-and-zombies
I'm still trying to figure out a good method to solve the final problem of vector generation.
Meanwhile I'm also making v2.6 more solid with a better detection of netlist warts, such as unconnected sinks and sources. I label those faulty gates or ports : "zombies". I don't make much efforts to "clean up" the netlist, instead I'll bail out if the netlist contains zombies. There is no point in trying because the vectors make sense only on a final design, however I try to make the output less cryptic and more useful when the tool is used as a simple netlist checker during design and for regression tests.
Also : the netlist will not "see" GND and VCC gates because they have no input. They don't make sense anyway, though A3P netlist often contain these... I consider these as "NOFIX".
A3Ptiles_v2.6_20191228.tgz has all the good stuff.
More info can be found in the test4_cornercases directory. The weird_unit.vhdl file implements the following circuits:
ff1 and ff2 implement a well-known set/reset flip-flop circuit and the outputs are "sequential" because they depend on the previous state, so they are "zombies". Both NAND2 are correctly flagged.
The mx0 implements a transparent latch. mx0 is correctly flagged, as well as the next gate that depends on the output.
Out(4) is left unconnected.
open1 and open2 are two chained gates with the final output dangling open. This is where things get a bit complex because open2 is correctly flagged as a zombie but not open1. Removing both would affect other parts of the system, such as reducing the depth of the design, which would create an avalanche of other effects...
open3 is correctly flagged as a zombie because both inputs are unconnected.
The end of the report says this:
Latency of the 5 outputs : Output#0 : N/A Output#1 : N/A Output#2 : N/A Output#3 : N/A Output#4 : N/A Found 6 zombie gates or inputs (unconnected or loops) : - Gate #6 : fanout= N/A - :vectgen(plip):wrap@vg_wrapper(weird):open2@and2(trace):lut4 - Gate #1 : fanout=2 - :vectgen(plip):wrap@vg_wrapper(weird):ff1@nand2(trace):lut4 - Gate #2 : fanout=2 - :vectgen(plip):wrap@vg_wrapper(weird):ff2@nand2(trace):lut4 - Gate #3 : fanout=2 - :vectgen(plip):wrap@vg_wrapper(weird):mx0@mx2(trace):lut8 - Gate #4 : fanout=1 - :vectgen(plip):wrap@vg_wrapper(weird):dummy@and2(trace):lut4 - Gate #7 : fanout= N/A - :vectgen(plip):wrap@vg_wrapper(weird):open3@and2(trace):lut4
I chose to flag the errors rather than correct them (by pruning), for these reasons :
- The correction/remedy could make the situation worse if there is a misunderstanding or a bug
- It is not the purpose of the system : I just want to make sure the vectors are generated with a sane dataset.
- It was not planned in advance and this "late feature" is harder to add (it was not straight-forward to implement anyway)
- Feature creep is bad and I want to KISS.
So I hope people can use this tool as a filter, I try to present useful information, so the user can correct their design.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.