Support implementation of architecture_spec config.

[n0thingNoob]

Adding option -architecture-spec="include/ArchitectureSpec/architecture.yaml"
Architecture Dimensions: Configurable width and height
Tile Configuration: Default and override support for num_registers, ports, operations, memory.capacity
Link Configuration: Default and override support for latency, bandwidth, and existence
Operation Mapping: Complete mapping of all 36 operations from NeuraOps.td to CustomizableFunctionUnit

TODO:
-connectivity configure
-extensions
-tile_overrides.num_registers
-modify all tests

[tancheng]

Thanks for the PR, a few questions and minor comments can be easily answered/fixed.

For coding style and comment:

• Plz change all the variables from camel case to snake_case
• Plz make all the comments end with period.

Above two can be easily handled by AI.

[n0thingNoob]

Thanks for the PR, a few questions and minor comments can be easily answered/fixed.

For coding style and comment:

• Plz change all the variables from camel case to snake_case
• Plz make all the comments end with period.

Above two can be easily handled by AI.

Working on it. Need a little bit of time.

[n0thingNoob]

The extension and the connectivity are not implemented yet.

[tancheng]

The extension and the connectivity are not implemented yet.

Can you please elaborate on extension and connectivity?

[n0thingNoob]

An extension is a potential future feature—for example, a crossbar switch. Connectivity describes the topology (mesh, ring, etc.). Our current default topology is mesh.

[tancheng]

An extension is a potential future feature—for example, a crossbar switch. Connectivity describes the topology (mesh, ring, etc.). Our current default topology is mesh.

• What's the difference? Crossbar is type of topology as well.
• Can we later include king-mesh as well? With king-mesh, we can model mesh, ring, and most arbitrary topologies, by removing (overwriting) some links.

[n0thingNoob]

An extension is a potential future feature—for example, a crossbar switch. Connectivity describes the topology (mesh, ring, etc.). Our current default topology is mesh.

• What's the difference? Crossbar is type of topology as well.
• Can we later include king-mesh as well? With king-mesh, we can model mesh, ring, and most arbitrary topologies, by removing (overwriting) some links.

By extension I mean a future optional slot (mainly for reservation). Crossbar is just one example: an auxiliary switch block placed adjacent to a tile. I felt that a crossbar is a local switching function that augments a topology but doesn’t change the global graph. So I guess it could be an extension.
We definitely can support king-mesh. The question is whether I can modify the link-generation code in architecture.cpp or not, since king-mesh requires adding the four diagonal directions. To keep the spec clean, my initial thought was using connectivity to build the first class topology before doing any link or tile overrides—rather than asking users to build a mesh first and then patch it with overrides.

[n0thingNoob]

I can support the connectivity ASAP if we have an agreement on a list of pre-defined topologies.

[tancheng]

I can support the connectivity ASAP if we have an agreement on a list of pre-defined topologies.

I thought we agreed on:

• User chooses pre-defined king-mesh, then user provide overwrites (pruning, no adding).
• User chooses pre-defined mesh, then user provide overwrites (pruning, no adding).

Basically, user only prune sth. Let's discuss this during our weekly meeting.

[tancheng]

Can you reply to my comments, so I am clear about what is fixed or not? I will click the "resolved" if I verify it is fixed.

[n0thingNoob]

Can you reply to my comments, so I am clear about what is fixed or not? I will click the "resolved" if I verify it is fixed.

All comments should be replied now.

[n0thingNoob]

Working on it.

[tancheng]

Working on it.

Thanks. Sorry about picky.