[HN Gopher] T1: A RISC-V Vector processor implementation
       ___________________________________________________________________
        
       T1: A RISC-V Vector processor implementation
        
       Author : namanyayg
       Score  : 86 points
       Date   : 2025-02-03 11:22 UTC (3 days ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | Neywiny wrote:
       | Might be interesting to see this combined with vex. Also nice to
       | see the recognition that memory bandwidth is an important
       | consideration.
        
         | crest wrote:
         | Some of the old Cray machines only cached instructions and
         | scalar data. Instead of a vector cache they used vector
         | scratchpad registers and plenty of interleaved memory channels
         | to keep up with the vector ALUs. That's one part of the design
         | space you can't go RISC-V without yet an other vendor
         | extension.
        
       | camel-cdr wrote:
       | Here is a list of open sourve RVV implementations:
       | https://github.com/stars/camel-cdr/lists/rvv-implementations
       | 
       | They have varying progress and target performance.
        
         | explodingwaffle wrote:
         | TIL this github "list" feature. neat
        
       | JoachimS wrote:
       | Would love to have seen some benchmarks.
        
         | camel-cdr wrote:
         | It's sadly not integrated into a scalar core yet, AFAIK it
         | currently uses spike to execute the scalar instructions.
         | 
         | You can try it if you want to:
         | 
         | They offer a pre-build docker environment, so you can play
         | around with the RTL simulation via "docker run --name t1 -it -v
         | $PWD:/workspace --rm ghcr.io/chipsalliance/t1-blastoise:latest
         | /bin/bash" This drops you into a shell, and you can start
         | simulating a 512-bit vector length processor, with "ip-emulator
         | --no-logging -C yourProgram", see the tests/ director for
         | example code. At least in theory, but there might still be a
         | few bugs.
        
       | hassleblad23 wrote:
       | Very cool
        
       | metadat wrote:
       | Am I understanding the README correctly in that:
       | 
       | You can execute some nix commands to fire up an emulator for this
       | CPU design? That's pretty cool, I wonder how hard it'd be to
       | reduce it to a docker command?
       | 
       | Also, I'd never heard of Chisel but it looks amazing - software
       | defines hardware via a Python-esque DSL to Verilog compiler.
       | 
       | https://github.com/chipsalliance/chisel
        
         | IshKebab wrote:
         | Chisel is just a Scala library to generate SV. I haven't
         | actually used it but I've used similar systems and a really big
         | problem with them is debugging. The generated SV tends to be
         | unreadable and you _will_ spend a lot of time debugging it.
         | 
         | Chisel has a similar competitor called SpinalHDL that is
         | apparently a bit better.
         | 
         | https://spinalhdl.github.io/SpinalDoc-RTD/master/index.html
         | 
         | IMO using general purpose languages as SV generators is not the
         | right approach. The most interesting HDL I've seen is Filament.
         | They're trying to do for hardware what Rust has done for
         | software. (It's kind of insane that nobody has done that yet,
         | given how much effort we put into verifying shitty SV.) Haven't
         | tried it yet though.
         | 
         | https://filamenthdl.com/
        
           | _chris_ wrote:
           | It's not that hard to debug-- your signal names and register
           | names all carry through. Sure, lots of temp wires get
           | generated but that's never where your bug is.
        
         | camel-cdr wrote:
         | The provide the docker image:
         | 
         | run docker image: docker run --name t1 -it -v $PWD:/workspace
         | --rm ghcr.io/chipsalliance/t1-blastoise:latest /bin/bash
         | 
         | execute program: ip-emulator --no-logging -C yourProgram
        
       | fulafel wrote:
       | Previously (name-wise):
       | https://en.wikipedia.org/wiki/UltraSPARC_T1
       | 
       | tl;dr - a 32-thread SPARC cpu from 20 years ago, with subsequent
       | chips getting to 256 threads per chip
        
       | chasil wrote:
       | It's a legacy processor, but the UltraSPARC T1 is the first thing
       | I thought of when I saw the title...
       | 
       | https://en.m.wikipedia.org/wiki/UltraSPARC_T1
       | 
       | This legacy CPU is actually open source, along with its
       | successor, the T2.
       | 
       | https://www.oracle.com/servers/technologies/opensparc.html
        
       ___________________________________________________________________
       (page generated 2025-02-06 23:00 UTC)