6 ms·

T1: A RISC-V Vector processor implementation

117 points by namanyayg 2y ago

Neywiny 2y ago
Might be interesting to see this combined with vex. Also nice to see the recognition that memory bandwidth is an important consideration.
- crest 2y ago
  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 2y ago
Here is a list of open sourve RVV implementations: https://github.com/stars/camel-cdr/lists/rvv-implementations https://github.com/stars/camel-cdr/lists/rvv-implementations They have varying progress and target performance.
- explodingwaffle 2y ago
  TIL this github "list" feature. neat
  - mindcrime 2y ago
    > TIL this github "list" feature Same.
JoachimS 2y ago
Would love to have seen some benchmarks.
- camel-cdr 2y ago
  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 2y ago
Very cool
metadat 2y ago
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 https://github.com/chipsalliance/chisel
- IshKebab 2y ago
  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 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/ https://filamenthdl.com/
  - _chris_ 2y ago
    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.
    - IshKebab 2y ago
      Maybe. I haven't used it. But with the compile-to-SV language I do use you're right it generates a lot of temporary wires and the bugs are never there, but they make it extremely tedious to trace drivers from the point of failure back to the cause.
  - aseipp 2y ago
    The real reason to use those languages is because they often lend themselves to using the meta-language for other purposes, like writing flexible open ended test suites, or using some forms of code generation/metaprogramming to generate parts of the design from other things. That's very useful and one of the attractive properties of systems like Amaranth or Clash, and one of the downsides (IMO) of approaches like Filament or Bluespec. That said, the most important bits about Filament and Bluespec are their high-level concepts (like guarded actions and timeline types), which could be adopted into other RTLs as well. At the end of the day though, sometimes you just have to debug a netlist, and that probably will remain true of Filament too. (Any language with higher-order applicative concepts will eventually run into some issues with wire names, etc, that's just unavoidable.) I think the SystemVerilog or whatever is just a red herring at that point; the tools for doing netlist debugging all feel like the equivalent of having to debug compiler assembly output with no debug symbols. Making sure you need to reach for the debugger much less is a good first step, but I'm not sure how to improve this part.
fulafel 2y ago
Previously (name-wise): https://en.wikipedia.org/wiki/UltraSPARC_T1 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 2y ago
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 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 https://www.oracle.com/servers/technologies/opensparc.html
- bpye 2y ago
  I wonder if we would have seen Sun continue to release the RTL for future SPARC cores had they not been acquired by Oracle.
  - crest 2y ago
    Maybe, but it's not like the T1 or T2 had been successful designs. Idea 4x (or even 8x) SMT to hide L2 (and to an extend L3) like cache latency from an in-order architecture feels didn't work out. Not many users have only parallelizable integer workloads. I suspect Sun got desperately tried to do what they could on their dwindling budget within the constraints of 64 bit SPARC. It's massive architectural register file and fixed sized register windows had to be pain to implement in an out of order uarch. I would love to gain more insight into how Fujitsu pulled this minor miracle off as the swan song SPARC.

117 points by namanyayg 2y ago

Might be interesting to see this combined with vex. Also nice to see the recognition that memory bandwidth is an important consideration.

crest 2y ago
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 2y ago

Here is a list of open sourve RVV implementations: https://github.com/stars/camel-cdr/lists/rvv-implementations https://github.com/stars/camel-cdr/lists/rvv-implementations They have varying progress and target performance.

explodingwaffle 2y ago
TIL this github "list" feature. neat
- mindcrime 2y ago
  > TIL this github "list" feature Same.

JoachimS 2y ago

Would love to have seen some benchmarks.

camel-cdr 2y ago
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 2y ago

Very cool

metadat 2y ago

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 https://github.com/chipsalliance/chisel

IshKebab 2y ago
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 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/ https://filamenthdl.com/
- _chris_ 2y ago
  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.
  - IshKebab 2y ago
    Maybe. I haven't used it. But with the compile-to-SV language I do use you're right it generates a lot of temporary wires and the bugs are never there, but they make it extremely tedious to trace drivers from the point of failure back to the cause.
- aseipp 2y ago
  The real reason to use those languages is because they often lend themselves to using the meta-language for other purposes, like writing flexible open ended test suites, or using some forms of code generation/metaprogramming to generate parts of the design from other things. That's very useful and one of the attractive properties of systems like Amaranth or Clash, and one of the downsides (IMO) of approaches like Filament or Bluespec. That said, the most important bits about Filament and Bluespec are their high-level concepts (like guarded actions and timeline types), which could be adopted into other RTLs as well. At the end of the day though, sometimes you just have to debug a netlist, and that probably will remain true of Filament too. (Any language with higher-order applicative concepts will eventually run into some issues with wire names, etc, that's just unavoidable.) I think the SystemVerilog or whatever is just a red herring at that point; the tools for doing netlist debugging all feel like the equivalent of having to debug compiler assembly output with no debug symbols. Making sure you need to reach for the debugger much less is a good first step, but I'm not sure how to improve this part.

fulafel 2y ago

Previously (name-wise): https://en.wikipedia.org/wiki/UltraSPARC_T1 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 2y ago

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 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 https://www.oracle.com/servers/technologies/opensparc.html

bpye 2y ago
I wonder if we would have seen Sun continue to release the RTL for future SPARC cores had they not been acquired by Oracle.
- crest 2y ago
  Maybe, but it's not like the T1 or T2 had been successful designs. Idea 4x (or even 8x) SMT to hide L2 (and to an extend L3) like cache latency from an in-order architecture feels didn't work out. Not many users have only parallelizable integer workloads. I suspect Sun got desperately tried to do what they could on their dwindling budget within the constraints of 64 bit SPARC. It's massive architectural register file and fixed sized register windows had to be pain to implement in an out of order uarch. I would love to gain more insight into how Fujitsu pulled this minor miracle off as the swan song SPARC.