Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

VRoom A high end RISC-V implementation

moonbaseotago.github.io

Post reply on HN
Print view View original

11–20 of 135 posts

Re: VRoom A high end RISC-V implementation

#11

Post by Someone »

themerone wrote: post #4

What does GPL mean for a chip design? I understand how it applies to the HDL, but I doubt that it obligates you have to open your code to users of physical chips.

I guess you could argue that, if you bought a device with this CPU, you should be able to replace the CPU with one of your own that’s derived from this one.

I think that’s the spirit of the GPL in a hardware context, but I don’t think it’s a given (by a long stretch) that courts would accept that argument.

A somewhat clearer case would be if you bought a device that implements a GPL licensed design in a FPGA. I think you could argue such devices cannot disable the reprogrammability of the FPGA.

Re: VRoom A high end RISC-V implementation

#12

Post by tasty_freeze »

For a few years I worked with the guy behind this project, Paul Campbell. He is a fearless coder, and moves between hardware and software design with equal ease.

An example of his crazy coding chops, he was frustrated by the lack of verilog licenses at the place he worked back in the early 90s. His solution was to whip up a compliant verilog simulator, then wrote a screen saver that would pick up verification tasks from a pending queue. They had many macs around the office that were powered 24/7, and they could chew through a lot of work during the 16 hours a day when nobody was sitting in front of them. When someone sat down at their computer in the morning or came back from lunch, the screen saver would just abandon the simulation job it was running and that job would go back to the queue of work waiting to be completed.

Re: VRoom A high end RISC-V implementation

#13

Post by colejohnson66 »

tasty_freeze wrote: post #12

For a few years I worked with the guy behind this project, Paul Campbell. He is a fearless coder, and moves between hardware and software design with equal ease. An example of his crazy coding chops, he was frustrated by the lack of verilog licenses at the place he worked back in the early 90s. His solution was to whip up a compliant verilog simulator, then wrote a screen saver that would pick up verification tasks f…

So, BOINC before BOINC?

Re: VRoom A high end RISC-V implementation

#14

Post by evilos »

tasty_freeze wrote: post #12

For a few years I worked with the guy behind this project, Paul Campbell. He is a fearless coder, and moves between hardware and software design with equal ease. An example of his crazy coding chops, he was frustrated by the lack of verilog licenses at the place he worked back in the early 90s. His solution was to whip up a compliant verilog simulator, then wrote a screen saver that would pick up verification tasks f…

That is terrifying.

Re: VRoom A high end RISC-V implementation

#15

Post by evilos »

titzer wrote: post #8

This is a very ambitious project, so respect and good luck. I am wondering if the performance will pan out in practice, as it doesn't seem to have a very deep pipeline, so getting high clockspeeds may be a challenge. In particular the 5 clock branch mispredict penalty suggest the pipeline design is fairly simple. Production CPUs live and die by the gate depth and hit/miss latency of caches and predictors. A longer pi…

They mention in their arch slides that they expect to add at least 2 more pipeline stages to hit higher clocks.

Re: VRoom A high end RISC-V implementation

#18

Post by Taniwha »

titzer wrote: post #8

This is a very ambitious project, so respect and good luck. I am wondering if the performance will pan out in practice, as it doesn't seem to have a very deep pipeline, so getting high clockspeeds may be a challenge. In particular the 5 clock branch mispredict penalty suggest the pipeline design is fairly simple. Production CPUs live and die by the gate depth and hit/miss latency of caches and predictors. A longer pi…

As mentioned here I expect that reality will intrude and the pipe will get bigger - of course good a BTC (and spending lots of gates on it) is important because that's what mitigates that deep pipe.

I haven't published my latest work (end of the week) I have a minor bump to ~6.5 DMips/MHz - Dhrystone isn't everything but it's still proving a useful tool to tweak the architecture (which is what's going on now)

Re: VRoom A high end RISC-V implementation

#19

Post by jasonwatkinspdx »

colejohnson66 wrote: post #13
tasty_freeze wrote: post #12

For a few years I worked with the guy behind this project, Paul Campbell. He is a fearless coder, and moves between hardware and software design with equal ease. An example of his crazy coding chops, he was frustrated by the lack of verilog licenses at the place he worked back in the early 90s. His solution was to whip up a compliant verilog simulator, then wrote a screen saver that would pick up verification tasks f…

So, BOINC before BOINC?

A lot of people have come up with something similar. Someone I know implemented the Condor scheduler to run models on workstations at night at a hedge fund. That Condor scheduler dates to the 80s. Smaller 3d animation studios commonly do this too.

Re: VRoom A high end RISC-V implementation

#20

Post by blacklion »

> Eventually we'll do some instruction combining using this information (best place may be at entry to I$0 trace cache), or possibly at the rename stage

So much for "we will do only simplest of commands and u-op fusing will fix performance".

It is why I'm very suspicious about this argument from RISC-V proponents.

Post reply on HN