kmurray
commented
6 years ago @vaughnbetz @KennethKent @jeanlego @aarongraham9: Any thoughts?
It seems to we have only two options:
i) Convert .latches to black-boxes as described above.
- This is a fairly trivial change which should be simple to make
- But it may reduce the optimizations ABC can perform
ii) Synthesize each clock-domain through ABC independently, and then re-stich the netlist together into one netlist later.
- Splitting by clock domain is likely more work. Additionally, this would need to be done anywhere we use ABC (e.g. for logic optimization, but also for equivalence checking), or by tools which use ABC as a library (e.g. ACE) -- this seems like a fair amount of work
- However, it would allow ABC to perform more sequential optimizations.
jeanlego
aarongraham9
vaughnbetz
KennethKent
Expected Behaviour
The VTR flow should handle circuits with no, single, or multiple clocks correctly.
Current Behaviour
There are actually two (inter-related) bugs here:
A) Clock restoration fails in certain cases, due to a bug in the clock restoration script. This occurs when the .latches are re-ordered in the ABC output.
B) More seriously, fixing (A) reveals that clock restoration is currently incorrect in many cases, and no warning/error is generated. This has been passing regression tests since the script incorrectly uses the first clock for all latches; and we've only tested these code-paths with single-clock circuits (which coincidentally produces the correct results).
Steps to Reproduce
A) Clock restoration fails if
.latches are re-ordered (thanks to Dipika Badri for the initial report!)Observe the following error:
However, the .latch top^FF_NODE~50 does in fact exist in both the reference and post-ABC netlists.
B) Fix file seeking behaviour in restore_multiclock_latch_information.pl. Run
vtr_reg_basicand observe new cock restoration failures on previously passing circuits.Context
ABC strips away clock information when it performs synthesis. This information is required at later stages of the design flow (e.g. VPR) so that multi-clock circuits are handled correctly.
We previously beleived that simply name-matching the
.latches would be sufficient to uniquely identify.latches in both the pre and post ABC netlists. However this is not always the case.For instance, before ABC:
and after ABC:
indicating that ABC is significantly modifying the latch names and structure in non-trivial ways. (Investigation shows that some latches are optimized away during the ABC command
ifraig). This means that simple name matching is insufficient to correctly restore clock information correctly.Possible Solution
For (A) it is trivial to fix the script to correct this issue by ensuring it seeks to the beginning of the file correctly. However fixing this causes (B) to start generating errors (it was a silent error before).
As shown above, it seems that in some instances ABC completely re-names the connections to/from .latches, which breaks the fundamental assumption that the clock restoration script makes (i.e. that it can match .latches based on output signal names).
It seems to me that the best course of action is to convert all
.latches to blackboxes before passing netlists through ABC, and then restoring them to.latches after ABC. This would ensure all clock information was preserved, but at the cost of disabling sequential optimizations within ABC (we already disable most sequential optimizations like re-timing anyway).For example, given an initial
.latch:a script would convert it to a blackbox as it was sent through ABC:
where the subckt type (
latch_re_3) encodes that it is rising-edge trigged with an initial value set to don't care (3). Since ABC leaves blackboxes alone, a script could then convert the blackbox back into a latch without loosing any information:Your Environment