Continue to support "legacy" style of describing adders

[mithro]

I believe synth_opt_adders should continue to support the "legacy" way of describing adders, IE The three configuration parameters which are;

• Fanout
• Logic Levels
• Wire tracks

The reasons I think this needs to continue to be supported because;

• There is a long history describing adders in these three terms and they are familiar to many people in the wild.
  • If people have to first understand something new they are less likely to use this resource.
  • You want people to easy see how this compares to something they already understand.
• It reduces the space into 3 reasonably easy to understand sections.
• It produces nice diagrams like;
  • 
  • 
• These 3 parameters can easily be used to build tables and to be tuned by optimizers.
• The conversion between the new method and the old method is potentially fraught with danger, so you want to "own" this part.

It is also good to have a great example of using these three terms and mapping to the more generic method. While the new more generic method of describing adders is useful for research, it is much harder to understand.

I think of this kind of like Newtonian mechanics (old F / L / W method) verse Einsteinian Mechanics (Teo's new method). While technically Einsteinian Mechanics is more accurate it also not taught first.

[tdene]

Related: #104 #106

[mithro]

FWIW - With the above two diagrams and about 3-4 sentences I was able to explain the L/F/T stuff to @proppy well enough he seem to understand it.

[tdene]

The following are my thoughts:

• Legacy diagrams are very useful for educational purposes and should be supported, as per Revive v0.4.5's diagram style #104
• Legacy diagrams can be quickly revived without the need for a full conversion back-end. The code is already there, in tag v.0.4.5, and it can be wrapped inside a try except clause that simply fails if used on a structure that cannot be depicted by classic diagrams.
• I do not see value in actual conversion between the classic description and the general description. Without passing judgment on whether the restrictions of the classic space are an advantage or a hindrance, more importantly, I strongly believe that the classic space lacks the mathematical formalism necessary to prove important facts and to design efficient+accurate exploration algorithms.
• Similarly, I do not see value in algorithmic exploration of the classic (restricted) adder space using classic formalism. I believe that any such effort, such as that deprecated in the last 400 lines of this file should remain unsupported, and should be removed as soon as better algorithmic exploration enters the public domain.
• Even if the expanded space should prove to be useless in one scenario or another, it is my belief that useful applications can only come out of a description of the classic space using the general mathematical framework.

In short, I fully agree that legacy diagrams and select nomenclature (e.g: Brent-Kung) should be supported, but I believe that supporting applications that wish to use the legacy mathematics is pointless, as any such applications will be strictly inferior in terms of both run-time performance and quality-of-results.

Closer to Rutherford's purely-descriptive model vs the mathematical models that followed (Bohr, orbitals, etc).