CIMFlow LogoCIMFlow

Memory, Network and Transfer

Address-space mapping, data paths, transfer runtime, and NoC delay/energy semantics

Transfer-related instructions map to memory domains, runtime data paths, and NoC costs based on the address-space configuration.


Address Space

All transfer decode decisions are based on the AddressSpace configuration. For each source and destination address, the simulator resolves three things:

Memory Domain
Local or global memory
Memory ID
Concrete memory region binding
Transfer Type
Local, global, send, or receive

Incorrect Mappings

If the address-space mapping is incorrect, the simulator will resolve addresses to the wrong memory region or fail at startup. Verify mappings in Input Files before debugging transfer behavior.


Transfer Types

The simulator decodes each transfer instruction into one of five types based on the source and destination addresses.

Local Transfer
MEM_CPY local to local via intra-core bus or dedicated data path
Global Load
MEM_CPY global to local through NoC
Global Store
MEM_CPY local to global through NoC
Send
SEND to another core via inter-core bus
Receive
RECV from another core via inter-core bus

Data Path Selection

For local transfers, the DataPathManager checks configured memory-pair mappings:

  • If (src_mem_id, dst_mem_id) matches a configured dedicated pair, the transfer uses a local_dedicated_data_path
  • Otherwise the transfer falls back to intra_core_bus

Global load/store and inter-core send/receive always use inter_core_bus. Dedicated data paths are defined in transfer_unit_config.local_dedicated_data_path_list.


Transfer Runtime Stages

Each transfer instruction passes through three stages inside the TransferUnit.

Issue Payloads
Read from Source
Write to Destination


Synchronization Through Transfer Path

TAG and WAIT are executed in the TransferUnit runtime path. For the full ISA-level semantics, see Execution and Resource Model.

  • TAG stores sync_id and attaches it to the next global_store
  • A tagged global_store triggers notify_write_complete(sync_id) to global memory
  • WAIT sends wait_for_writes(sync_id, expected_writes) and blocks until sync_complete
  • Consecutive TAG without an intervening tagged store is treated as a fatal invalid sequence

Control Path Split

TAG and WAIT are control opcodes at decode level, but their runtime behavior is implemented by the transfer/network/global-memory path. For decode and issue details, see Execution and Resource Model.

Last updated on