The Gray counter is now operational, now is the time for some MUXing !

I already started to cover this subject in 25. MUX trees. The TAP/ directory now contains an interesting selection of MUX64 with various properties. I'll let you read the script and the output logs to see where it is going :

• MUX64_behavioral.vhdl is just a plain dumb VHDL version that accesses the input vector as an array.
• MUX64_BBTclassic.vhdl is an expansion of this, still using VHDL vector idioms.
• MUX64_BBTgates.vhdl implements the above with individual gates, so we can start to see the properties :
  { 1,  2,  4,  8, 16, 32 } : not good ! This is indeed the pathological case.
• MUX64_BBTBC.vhdl  uses 4 unbalanced sub-trees (MUX16_A.vhdl) and reaches the perfect score :
  { 1, 12, 12, 12, 13, 13 }
  however it might not be convenient to route. The sub-trees could get some treatment for local adaptation.
• MUX64_BBTBC.vhdl with  MUX16_B.vhdl is easier to route but worse { 1, 11, 11, 11, 11, 18 }
  
• MUX64_BBTBC.vhdl with MUX16_C.vhdl is the worst : { 1, 10, 10, 12, 12, 18 }
• MUX64_BBTm.vhdl is a modified version that reaches the closest suboptimal score { 1, 11, 11, 11, 14, 15 } with either MUX16_B.vhdl or MUX16_C.vhdl.
  This is the best compromise I have found yet.

The README.txt explains how I came up with this permutation.

20200802 : Update !

As if this was not enough shuffling wires around, the PISO part has to send data "Most Significant Bit First" so all the scanning order has to be reversed.

Or simply the order of the inputs of each MUX is reversed.

That's what I did with the latest version of the tree : MUX16_Brev.vhdl MUX16_Crev.vhdl and MUX64_BBTrev.vhdl implement a MUX64 with reversed inputs.

See the log 25. MUX trees to find a practical implementation with unguided synthesis.