vtr-verilog-to-routing
vtr-verilog-to-routing copied to clipboard
verilog-to-routing
Enabled BLIF buffer elimination in preparation for InOuts
Description
Enables the logic for eliminating the redundant final buffer in the BLIF output. This is a necessary precursor to InOuts as the extra buffer is not driven by the input correctly
Types of changes
- [x] Bug fix (change which fixes an issue)
- [ ] New feature (change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
Checklist:
- [ ] All new and existing tests passed
@kmurray This changes Odin II's BLIF output slightly which seems to have had some QoR changes for VPR. The issues on Travis appear to be improvements. What do I need to do to regenerate the golden results to make this pass?
Running the regression tests (with -create_golden to regenerate golden) for basic, strong and nightly I get this error:
vtr_func_formal: k6_frac_N10_40nm.xml/stereovision3.v/common file : abc.lec.out
failed: Couldn't determine Logical Equivalence status between stereovision3.odin.blif <-> sv_chip3_hierarchy_no_mem_post_synthesis.blif (took 3.21 seconds)
I assume this means ABC somehow broke with these changes?
My concern here is that I believe this modification must definitionally be identical behaviour, since the driving net can only have a fanout of one (otherwise I do not do this optimisation) so the drivers of this net must necessarily assign directly to the output wire.
The only thing I can think is that somehow there is a combinational loop formed somewhere, but I dont see how this could be possible since fanout = 1 and we dont have InOuts yet (and if we did it would be a bug in stereovision not Odin II)
@jeanlego Thoughts?
Does @jeanlego's suggested code change above fix the logical equivalence failure or is there still an issue with that?
Does @jeanlego's suggested code change above fix the logical equivalence failure or is there still an issue with that?
Sadly no but I'm out for the week so I can't pull the code to diff the resulting blif
Assigning this to @sdamghan to see if he wants to finish this PR, or abandon it.
@vaughnbetz not sure why this is left, I was not aware of the progress of this PR. Will investigate more in the future
