Skip to main content

架构/微架构

设计

  1. 标量寄存器和向量寄存器统一，支持自动进行转换
  2. 异步单元（SP-PU-L1-DMA）之间都采用异步机制，依赖转移到异步目标
    1. 统一的同步机制
    2. 静态分配同步资源
    3. 原生软硬件支持动态图的执行
    4. LD/ST 避免使用fence功能
  3. Launch：fork
    1. 资源初始化（同步资源，各种存储器，状态）
  4. launch/signal/wait:join
    1. launch pu instrution:  write_back_id  local_id
      1. write_back atomic add/sub
    2. wait instruction: local_id
      1. local_id GE LE counter
    3. wait remote instruction: remote_id
      1. local_id GE LE counter
  5. 灵活性&性能
    1. 支持灵活的数据尺寸
    2. 支持灵活的本地数据复用，尽量减少数据搬运数据
    3. 尽量避免算力浪费
      1. leading tailing 时间：LD/ST inflight delay，DMA Delay
        1. ping-pong
        2. pipeline
      2. 数据没有ready需ready、需要的fence引起的气泡
        1. 无缝的同步机制
      3. 不对齐、尾数

MAC

  1. Vector计算单元支持乱序和并行
  2. 软件编译指定明确的VR寄存器依赖，RO WO属性
  3. 自动拆解大指令成Vector指令，并行执行
  4. 软件静态排布VR寄存器，生成依赖关系，申请和释放管理
  5. Vector指令支持标量对其进行动态配置

Software

  1. 使用独立的硬件仿真软件，不依赖硬件仿真运行

ISA

  1. 标量
    1. RV64i
  2. 向量
    1. VLD VST VMUL VADD REDUCE_ADD REDUCE_MAX REDUCE_MIN VMUL_REDUCE_ADD
    2. MLD MST
  3. 张量
    1. GEMM
      1. 左/右数：128个=7位 + 3位扩展矩阵  = 10位  
      2. 输出：7位
      3. Opcode
  4. fence
    1. L1 cache line 计数
  5. VR
    1. 软件管理VR data hazard？ VR之间的依赖？
      1. 增加指令的表达信息
    2. 软件分配VR 还是 硬件rename ing ，解决bank冲突？
    3. 利用 VR count？软件进行管理依赖关系？
      1. LD ST 计算 的三类指令之间可以并行，通道内部没有必要并行
        1. 因为硬件资源没有特殊性，不会因为并行而减少气泡
      2. 默认，GEMM指令一定要在前面LD指令之后执行
      3. 默认，ST指令一定要在前面计算指令之后执行
  6. L1
    1. 软件管理 cache line
    2. cache line硬件计数，自动异步等待
    3. 针对L1 CacheLine的编程？
      1. 软件指定Load到L1 cache line的位置和有效长度
      2. 向量指令按照cache line的粒度和mask来执行指定的计算
      3. 这整个流程都是提前编译好，从L1-L1都是提前确定的
      4. 针对不同MNK大小需求，可以通过标量指令来快速配置，支持动态性
  7. 增加到128个标量寄存器 支持RV64扩展？
  8. 增加指令流控制
  9. 增加配合/加速向量单元的定制指令？ 通过兼容RiscV-V的指令来实现？？
Back to top