Parser Results Don't Match Paper Description

[cynthi8]

Incorrect Neighborhood Count

When the circuit from Fig. 3b is parsed using SFLL_Verilog_to_graph.pl, the feature vector does not match the one shown in DATE 2021.

The parser produces a feature vector with XOR = 6 for node i.	PI	PO	KEY	XOR	XNOR	AND	OR	NAND	NOR	INV	BUF	ADDF	AOI	OAI	MXIT	AO1B	AOI2XB	AO	OA	OAI2XB	in_degree	out_degree	TIELO	TIEHI	RF2R	RF1R	PREICG	POSTICG	M	A	FRICG	MXT	MX	ADDH
0	1	0	6	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	3	1	0	0	0	0	0	0	0	0	0	0	0	0

Neighborhood Count Dependent on Key/Primary Inputs

Furthermore, if the key inputs (k1, k2, k3) are changed to primary inputs, the XOR neighborhood count jumps to 9 for node i.	PI	PO	KEY	XOR	XNOR	AND	OR	NAND	NOR	INV	BUF	ADDF	AOI	OAI	MXIT	AO1B	AOI2XB	AO	OA	OAI2XB	in_degree	out_degree	TIELO	TIEHI	RF2R	RF1R	PREICG	POSTICG	M	A	FRICG	MXT	MX	ADDH
0	1	0	9	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	3	1	0	0	0	0	0	0	0	0	0	0	0	0

Neighborhood vs Input/Output Cone of Dependency

Although no neighborhood examples were provided in the paper, the feature vector is described as

the type and number of gates appearing in the neighborhood of the node (all nodes within two-hops away)

A true 2-hop neighborhood of an XOR node in this graph would include the other XOR nodes and we would expect the XOR count to be 3. However, the feature vector produced has XOR = 1, which is what we would expect if we were only limiting ourselves to the input and output cones.	PI	PO	KEY	XOR	XNOR	AND	OR	NAND	NOR	INV	BUF	ADDF	AOI	OAI	MXIT	AO1B	AOI2XB	AO	OA	OAI2XB	in_degree	out_degree	TIELO	TIEHI	RF2R	RF1R	PREICG	POSTICG	M	A	FRICG	MXT	MX	ADDH
1	1	1	1	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	2	1	0	0	0	0	0	0	0	0	0	0	0	0

This feature vector for an XOR node also shows PO = 1 which is incorrect.

Reproduction Steps:

1. Download graph_example_from_paper.zip

2. unzip ~/Downloads/graph_example_from_paper.zip
   mkdir -p ./Netlist_to_graph/Graphs_datasets/graph_example_from_paper/
   cd ./Netlist_to_graph/Graphs_datasets/graph_example_from_paper/
   perl ../../Parsers/SFLL_Verilog_to_graph.pl -i ../../../graph_example_from_paper > log.txt

3. Open feat.txt

[lilasrahis]

Thank you Erin for pointing this out. There was a typo in the code. The issue has been fixed. Please let me know if you have other observations. Thanks!

[cynthi8]

Thanks!

Is it still intended behavior for the XOR gates to be excluded from each other's neighborhood?

With the latest change, I still see XOR = 1 for the XOR gates - but I would expect this to be 3, as XOR B and XOR C are also within two hops of XOR A.

PI	PO	KEY	XOR	XNOR	AND	OR	NAND	NOR	INV	BUF	ADDF	AOI	OAI	MXIT	AO1B	AOI2XB	AO	OA	OAI2XB	in_degree	out_degree	TIELO	TIEHI	RF2R	RF1R	PREICG	POSTICG	M	A	FRICG	MXT	MX	ADDH
1	0	1	1	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	2	1	0	0	0	0	0	0	0	0	0	0	0	0

Erin

[lilasrahis]

Hi Erin, Correct. The way we have implemented is as follows: Starting at the target node, we get its output. Then, for the outputs, we also check their outputs (2 hops). Then, we look at the inputs of the target node and their inputs as well (2 hops). An example showing this corner case was not included in the paper. We release the codes so that everyone can access the exact implementation.

[lilasrahis]

Hi Erin, I believe that Fig. 5 in the GNNUnlock+ paper shows a similar example. https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9529342