CGRA controller

[tancheng]

A CGRA controller is needed:

• To deliver control signals to each tile. Currently, each tile has control memory port exposed, which need to be connected to a controller, maybe via a NoC: https://github.com/tancheng/VectorCGRA/issues/29.
• In addition, the termination signal (might be generated by a branch(false) instruction/option or a return operation) needs to be recognized by the controller.
• The controller itself could either be centralized or distributed.
• The NoC connecting the controller could be as simple as a ring for now.
  • The NoC can be used to deliver both the control signals and the termination signals (differentiated based on message type).
  • The NoC can be other topologies as well, which is orthogonal to the CGRA design/execution mode/datapath.
• The controller should be able to invoke the CGRA execution once the data is preloaded (or invoke the CGRA without waiting for data for data-driven execution), which can unblock https://github.com/tancheng/VectorCGRA/issues/11.
• The controller plays a significant role when there is runtime-related features/functionalities, i.e., dynamic task scheduler, dynamic mapping change, DVFS, dynamic change between blocking/non-blocking data-driven/cycle-based execution (https://github.com/tancheng/VectorCGRA/issues/26), etc.

Blocked by:

• https://github.com/tancheng/VectorCGRA/issues/29
• https://github.com/tancheng/VectorCGRA/issues/25

[yyan7223]

I get it, let me think about the architecture of controller and NoC.

[tancheng]

I think a controller is also important/necessary for your PIM and custom kernel IP integration.