Pattern matching

[tancheng]

@HobbitQia We can discuss pattern matching stuff here.

Our initial discussion includes:

• DFG common pattern recognition algorithm
• Each pattern should have a corresponding HW, those HW FUs can be fused, then can feedback to the pattern matching
  • In addition, per single pattern, I believe there is also some flexibility, e.g., to support mul->add, HW FU should be a multiplier followed by adder (MAC), then this MAC can easily support:
    • add(mul(a, b), c)
    • add(c, mul(a, b))
    • add(c, d) | mul(a, b)
  • Benefit can come from pruning redundant HW units, and recognizing other patterns
  • Tradeoff exists in:
    • HW -- whether sharing certain HW FUs
    • SW -- priority when performing pattern matching, as there is common part across different target patterns
  • The challenge might be in the micro-configuration of the fused pattern.
    • Straightforward solution is to provide a fixed number of modes:
      • add(mul(a, b), c) -- MAC-mode0
      • add(c, mul(a, b)) -- MAC-mode1
      • add(c, d) & mul(a, b) -- MAC-mode2
      • add(c, d) -- MAC-mode3
      • mul(a, b) -- MAC-mode4
• Considering topology as fused/shared HW FU would have more inports and outports