FilterHN

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.

▲

camel-cdr

1 year ago

[-]

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

1 year ago

[-]

TIL this github "list" feature. neat

▲

mindcrime

1 year ago

[-]

> TIL this github "list" feature

Same.

▲

Neywiny

1 year ago

[-]

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

▲

crest

1 year 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.

▲

metadat

1 year 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

▲

IshKebab

1 year 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

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/

▲

aseipp

1 year 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.

▲

IshKebab

1 year ago

[-]

Yeah I agree that debugging generated SV is like debugging assembly and you rarely have to do that when writing normal programs. I think the difference is tooling. I can fire up an IDE debugger and have full access to all the relevant information and controls without seeing any assembly.

I don't know of any compile-to-SV tools that have a debugger anywhere near as capable as that. They definitely should! But they don't right now, so we're stuck at debugging RTL.

▲

_chris_

1 year 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

1 year 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.

▲

camel-cdr

1 year ago

[-]

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

▲

JoachimS

1 year ago

[-]

Would love to have seen some benchmarks.

▲

camel-cdr

1 year 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.

▲

fulafel

1 year ago

[-]

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

▲

hassleblad23

1 year ago

[-]

Very cool