kimiatkh
commented
3 weeks ago Hi @vaughnbetz ,
This was the ABC-related issue I was facing in multi-clock circuit processing. To avoid cross clocking optimization, VTR preprocesses the input netlist, hiding all clock domains except for one at each iteration by turning all the latches of all other clocks into black boxes. If we have a case where the output of the register is directly driving an output port, when the latch turns into the black box and goes through the ABC run, the output port gets removed from the netlist. If all the outputs are registered, in fact, no outputs are left by the time all the passes are done. Above is the description of the issue. I was not sure, however, who are the related people to include on this issue. Could you please include the people who might be able to help with this?
Thanks,
Problem Description
This issue is to report a problem in the ABC tool's output generation of BLIF files. Attached are the input BLIF file that produces the problematic output and the output BLIF file generated by ABC. output.blif.txt input.blif.txt
Command Used
The command executed was:
~/vtr-verilog-to-routing/abc/abc -c "read input.blif; strash; ifraig -v; scorr -v; dc2 -v; dch -f; if -K 6 -v; mfs2 -v; write_hie input.blif output.blif;"This was tried on the latest version of VPR.
Issue Description
In the input BLIF file, there is an output port named out. However, after running the ABC command, this port is missing in the generated output BLIF file. This issue occurs when the output of a .subckt is connected to an .output port. Specifically, the out signal, which is the output of the subcircuit latch_^re^_clock_writerhead^_0, is an output port.
Additionally, simply reading the input BLIF file, processing the hierarchy, and generating the output BLIF without performing any optimization passes also produces this issue. The command for this is:
~/vtr-verilog-to-routing/abc/abc -c "read input.blif; write_hie input.blif output.blif;"Suspected Cause
I looked into this issue a while back and it seems the issue arises during the process of flattening the hierarchy. ABC removes the black boxes from the netlist as a preprocessing step before flattening. All the nets driving or being driven by a black box are converted to PI/POs. After the flattening steps are done, the black boxes are reintroduced into the hierarchy by reconnecting the nets to the black boxes and removing them from the PI/POs. However, this process does not seem to handle cases where a black box drives a net that has a PO as a load correctly. Most of the relevant functionality for this process is located in src/base/abcHie.c.
Extra Note
I conducted a quick experiment where I added a port with the same name "temp" to the input and output, essentially creating a direct connection between them. After running the above command, the input port temp is retained, but the output is removed. While I am not fully familiar with the internals of ABC, it seems that in the case of the black box, we have a similar situation where a black box drives an output port, and when the black box is removed during hierarchy flattening, an input has to be inserted with the exact same name as the output. So this issue could be in how the case of having the same named input and output during this phase is handled.