Please enable JavaScript.

Coggle requires JavaScript to display documents.

coscup - Coggle Diagram

- - - - basic int and fp arithmetic
      - unified register file using zfinx instructions
      - RISC-V based
      - good propagation delay
    - - parallel instruction
      - migrate to bf16
      - other fp operations: exp, log, tanh
  - - - use clang to factorize code into host and device code
      - uses clang to transform c++ into llvm ir
      - uses clang to transform llvm ir into RISC-V assembler
      - we provide a HIP hostside runtime
        
        handles memory management
        
        handles launching kernels
        
        handles communications with gpu controller
      - we handle rewriting the LLVM IR to call into our HIP hostside runtime
- - - - maybe as easy as adding noob documentation to qflow?
      - probably need some tests for various edge-cases though, perhaps with a CI server
- - - - only BF16; no FP16, no FP32, no FP64
      - only fp operations needed by ml, eg exp, log, tanh
      - goal is to keep tape-out costs down, and yield up
- - - - but lots of dev needed
    - - open standard
      - not currently supported by pytorch => would need dev effort
      - slow, because has to support so many types of hardware, and reuirements from many consortium members
    - - tempting: already works with pytorch
      - unclear how to defend against IP related C&Ds from nvidia
    - - works with pytorch already
      - opensource (MIT) license
      - almost the same as CUDA, so relatively standard
  - - - might need to break with RISC-V somewhat when switching to use BF16 (currently using FP32, to get things working)
  - - - though this doesn't seem sufficient to fully specify the interface, so there will be some controller-specific work to do
- - - - with iverilog, can use gate level simulation to catch many errors
        
        but some still get through
      - with verilator, can use random initialization
        
        this seems pretty effective, found bugs that iveriloatr with GLS di not
        
        sometimes tricky to track down the bug, but at least know there is one
- - - - very easy to use
      - can write test cases in verilog
      - generates/compiles code very quickly
    - - strict GPLv2 license
        
        potentially an issue for using VPI
      - limited support for system verilog
  - - - great reputation in industry
      - runs quickly
      - relatively unrestrictive license (LGPLv2)
      - detects initiailzation errors reliably, using random initizlation
      - easy to link with C++
      - system verilog underway
    - - lots of system verilog functionality missing
      - cannot write standard verilog test bench unit tests
      - compilation/generation slow, hard to configure
  - - - good points
        
        very reliable
        
        didnt find a bug yet
        
        can handle a diverse space of verilog code
      - bad points
        
        limited support for system verilog
- - - - calculate propagation delay, in units of 'nand gate propagation delay'
      - calculate die area, in units of 'nand gate die area'
- - - - which can be given to other tools
      - good points
        
        supports system verilog
      - bad points
        
        whenever somethign goes wrong, throws you into generated verilog cocde
        
        I'd like to be thrown into the sv code, ideally