[P1] A simulator to respect arch specs and the instructions generated by codegen

[tancheng]

Currently blocked by #6.

We can have our own one inside the tools directory.

[n0thingNoob]

I created a draft parameter input in YAML for users, and then we can use a script to transfer it into a JSON-style output. Here is an example:
architecture:
name: "NeuraCGRA"
version: "1.0"
width: 4
height: 4

default tile type (e.g. alu, memory, input/output, config)

tile_type: "alu"
num_registers: 64
default_ports: ["N", "S", "W", "E"]

Default instructions that ALU should support

operations: ["add", "mul", "sub"]

link_defaults:
latency: 1
bandwidth: 32

connectivity: mesh, torus, or custom

connectivity: "mesh"

If connectivity is custom, define all links explicitly:

links:

• id: 0
  src_tile: 0
  dst_tile: 1
  src_port: "E"
  dst_port: "W"
  latency: 1
  bandwidth: 32
• id: 1
  src_tile: 0
  dst_tile: 4
  src_port: "S"
  dst_port: "N"

Per-tile overrides (optional)

tile_overrides:

• id: 0
  type: "input"
• id: 3
  type: "output"
• id: 5
  type: "memory"
  capacity: 2048
• id: 10
  type: "control"

extensions:
crossbar: false

simulator:
execution_model: "serial"

logging:
enabled: true
file: "output.log"

driver:
name: "Driver"
frequency: "1GHz"

device:
name: "Device"
frequency: "1GHz"
bind_to_architecture: true

I might’ve missed a few features—feel free to take a look and let me know if anything’s missing, for both the RTL and simulators.
（I found the format is different after I update it）

[tancheng]

Thanks for the update @n0thingNoob,

id: 1
src_tile: 0
dst_tile: 4
src_port: "S"
dst_port: "N"

We don't actually need src_port and dst_port as the tile ids are already provided?

id: 0 // or we can use coordinates like (x, y) to identify and set the tile.
type: "input"
// could add more attributes like ports or registers, if no attributes, we still have the default setting.
id: 3
type: "output"
id: 5
type: "memory"
capacity: 2048
id: 10
type: "control"

Can you elaborate on type? not sure the meaning about input/output/memory/control means there.

[tancheng]

CCing @yuqisun for visiblity. We need to align the format to contruct/initialize/model a specific CGRA using the CgraTemplateRTL.py. @n0thingNoob is providing a demo/example about the input param format.

[n0thingNoob]

For the first question, we don't strictly need src_port or dst_port, but it is useful for hardware layout or visualization just in my opinion. We can skip it.

For the second one, here is a table:
alu: arithmetic logic unit for computations
Input: The input tile receives data from outside of the CGRA (memory or host)
output: output tile that sends results out of the CGRA
memory: memory tile, it can provide some local scratchpad storage
control: (Optional) Control tile that may manage scheduling, global synchronization, or configuration control. Not required in all architectures, but may be useful in complex systems.

architecture.txt

[tancheng]

For the first question, we don't strictly need src_port or dst_port, but it is useful for hardware layout or visualization just in my opinion. We can skip it.

For the second one, here is a table: alu: arithmetic logic unit for computations Input: The input tile receives data from outside of the CGRA (memory or host) output: output tile that sends results out of the CGRA memory: memory tile, it can provide some local scratchpad storage control: (Optional) Control tile that may manage scheduling, global synchronization, or configuration control. Not required in all architectures, but may be useful in complex systems.

architecture.txt

Input, output, and memory can co-exist for the same tile, right?

[n0thingNoob]

For the first question, we don't strictly need src_port or dst_port, but it is useful for hardware layout or visualization just in my opinion. We can skip it.
For the second one, here is a table: alu: arithmetic logic unit for computations Input: The input tile receives data from outside of the CGRA (memory or host) output: output tile that sends results out of the CGRA memory: memory tile, it can provide some local scratchpad storage control: (Optional) Control tile that may manage scheduling, global synchronization, or configuration control. Not required in all architectures, but may be useful in complex systems.
architecture.txt

Input, output, and memory can co-exist for the same tile, right?

Yes, they can co-exist in one tile, but I remember there are some architectures that set specific tiles as memory tiles. We can delete input/output and control type. maybe I can write it like this:
tile_overrides:

• id: 0
  compute: false
  memory:
  capacity: 1024

• id: 3
  compute: true
  operations: ["mac", "add", "mul"] # for specific operations tile

• id: 5
  compute: true
  memory:
  capacity: 2048
  #here we might want to indicate what ports they need? Since we are setting special tiles here.

[tancheng]

yes, we may also rewrite following for a tile:

tile_type: "alu"
operations: ["add", "mul", "sub"]
num_registers: 64
default_ports: ["N", "S", "W", "E"]

And compute: false might not be not necessary if we can overwrite operations: [].
And type: "input" can be represented via operations: [load] while type: "output" can be represented via operations: [store].

WDYT?

[n0thingNoob]

So maybe we can try this:
tile_overrides:

• id: 0
  operations: ["load"]
  num_registers: 32
  ports: ["S", "E"] # Only S and E ports active

• id: 3
  operations: ["store"]
  num_registers: 32
  ports: ["W"] # Only west-facing output

• id: 5
  operations: ["add", "mul"]
  num_registers: 32
  memory:
  capacity: 2048
  ports: ["N", "S", "E", "W"] # Fully connected, this is unnecessary, just to show the full connected situation. we do not need to write it and it will follow the default connection setting in global variable.

• id: 6
  operations: [] # No compute
  num_registers: 32
  ports: ["E", "W"] # Acts like a router tile

Is this one better? I think we might not need the tile type? just use operations to describe it.

[tancheng]

tile default parameters:
  operations: ["add", "mul"]
  num_registers: 32

tile specialization:
  id: 0
    x: 0
    y: 0
    operations: ["load"]
    num_registers: 4

  id: 3
    x: 3
    y: 0
    operations: ["add", "mul", "load", "store"]

  id: 5
    x: 1
    y: 1
    operations: ["add", "mul", "shift"]
    memory:
    capacity: 2048
    
  id: 6
    x: 2
    y: 1
    operations: [] # No compute

You are free to add ports if you want. I have not yet considered how memory is leveraged, but it is good to have as Sambanova has such stuff.