Rework pack pattern annotation generation

[mithro]

The pack pattern annotation generation should be done in following steps;

• Step 1 - Mark all paths with the pack attribute.
• Step 2 - Remove the pack attribute from any path which goes to a top level port.
• Step 3 - For each group emit a pack pattern.

Test cases;

   +-------------------+
   |                   |
   |   +---+   +---+   |
   |   |   |   |   |   |
   +--->   +--->   +--->
   |   |   |   |   |   |
   |   +---+   +---+   |
   |                   |
   +-------------------+

   +-------------------+
   |                   |
   |   +---+   +---+   |
   |   |   |   |   |   |
   +--->   +--->   +--->
   |   |   | | |   |   |
   |   +---+ | +---+   |
   |         |         |
   |         +--------->
   |                   |
   +-------------------+

  +--------------------+
  |                    |
  |   +---+   +---+    |
  |   |   |   |   |    |
  +--->   +--->   +---->
  |   |   | | |   |    |
  |   +---+ | +---+    |
  |         |          |
  |         | +---+    |
  |         | |   |    |
  |         +->   +---->
  |           |   |    |
  |           +---+    |
  |                    |
  |                    |
  +--------------------+

[acomodi]

Follow up on pack patterns in children pb_tyes

As discussed in the PR, the pack pattern auto-generation affects also the children pb types when building a top-level pb_type.

The image above represents a much simplified real case in the QL devices.

At generation time of the leaf pb_types, v2x is not aware of the fact that a pack pattern is required to connect and correctly pack together with the C_FRAG and Q_FRAG pb_types, which are generated before the top-level pb_type.

Only when the LOGIC pb_type is being generated, the relation between the C_FRAG output and the Q_FRAG input is understood, making v2x aware of the fact that a pack_pattern is required.

In the above example, there are four different pack patterns to be added, one for each possible path, as follows:

C_FRAG (mode SPLIT) --> C_FRAG_MODES --> LOGIC --> Q_FRAG_MODES -> Q_FRAG (mode INTERNAL)
C_FRAG (mode SPLIT) --> C_FRAG_MODES --> LOGIC --> Q_FRAG_MODES -> Q_FRAG (mode EXTERNAL)
C_FRAG (mode SINGLE) --> C_FRAG_MODES --> LOGIC --> Q_FRAG_MODES -> Q_FRAG (mode INTERNAL)
C_FRAG (mode SINGLE) --> C_FRAG_MODES --> LOGIC --> Q_FRAG_MODES -> Q_FRAG (mode EXTERNAL)

The problem stands in the fact that the pack pattern is not present in the original children pb_types.

[mithro]

I think the following diagram explains the issue?

• https://docs.google.com/drawings/d/1RNDhwfBa3k97LOTueD6mWfAEHDd9KNhPkg7AmMLjbc0/edit

Google Docs

acomodi pack patterns

M11 M12 M21 M22 BEL BEL BEL BEL

[mithro]

There needs to be four pack patterns generated which group together the following sets of bels;

• M11 -> M21
• M11 -> M22
• M12 -> M21
• M12 -> M22

[mkurc-ant]

@mithro @acomodi I've done some work to make vtr-xml-utils expand pack patterns. I've issued a WIP PR to open a discussion whether the approach is feasible: https://github.com/SymbiFlow/vtr-xml-utils/pull/16

The idea is to have pack_pattern annotations at the top-level of the hierarchy and then use them as seeds for expansion:

In the picture above the pack_pattern annotation is initially present inside the interconnect of CLB only. Then it gets expanded until it reaches any leaf pb_type.

The code I've written automatically duplicates pack-patterns whenever there are multiple paths possible for the initially annotated connection. Each path is meant to span from and to a leaf pb_type (no carry chain pack patterns supported yet). For now multiple pb_type modes are supported as well as <mux> and <direct> connections.

The expansion can go both "up" and "down" the signal path.

Any feedback would be appreciated.