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

71–80 of 135 posts

Re: VRoom A high end RISC-V implementation

#71

Post by Taniwha »

Taniwha wrote: post #33
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.

Well (author here) - this is a private project - typically such a project would be very propriety - people don't get to show their work. But I'm looking to find someone to build this thing, it's been a while since I last built chips (last CPU I helped design never saw the light of day due to reason that had little to do with how well it worked). So I need a way to show it off, show it's real. So GPLing it is a great…

One other comment about why GPLing something is important for some like me - publishing my 'secrets' are a great way to turn them into "prior art" - you read it here first, you can't patent it now - I can protect my ideas from becoming part of someone else's protected IP by publishing it.

I spent a few years working on an x86 clone, I had maybe 10 (now expired) patents on how to get around stupidly obvious things that Intel had patented - (or around ways to get around ways to get around In tel that other's had patented) - frankly from a technical POV it was all a lot of BS, including my patents

Re: VRoom A high end RISC-V implementation

#72

Post by wrs »

wrs wrote: post #30
codedokode wrote: post #27

The presentation was interesting; but I would like to write an idea that is tangentially related to this CPU. I noticed that modern CPUs are optimized for legacy monolith OS kernels like Linux or Windows. But having a large, multimegabyte kernel is a bad idea from a security standpoint. A single mistake or intentional error in some rarely used component (like a temperature sensor driver) can get attacker full access…

Long ago, we in the Newton project at Apple had that idea. We (in conjunction with ARM) were defining the first ARM MMU, so we took the opportunity to implement “domains” of memory protection mappings that could be quickly swapped at a context switch. So you get multiple threads in the same address space, but with independent R/W permission mappings. I think a few other ARM customers were intrigued by the security po…

Too late to edit, but here's a documentation link that works better: https://developer.arm.com/documentation/dui0056/d/caches-and...

Re: VRoom A high end RISC-V implementation

#73

Post by Taniwha »

titzer wrote: post #69
Taniwha wrote: post #62

Earlier quoted context omitted.

yes and no - there's a few issues here: 1 - architectural - RISCV has a nice clean ISA, it's adding instructions quickly, CMOV is contentious issue there - I'm not an expert on the history so I'll let others relitigate it - it's easy to add new instructions to a RISCV machine, unlike Intel/ARM it's even encouraged - however adding a new instruction to ALL machines is more difficult and may take many years. But unlike…

Note I was talking about a conditionall call instruction, which is very useful for, e.g. safety checks.

conditional CALL is MUCH harder to implement well - it's because the call part essentially happens up at the PC/BTC end of the CPU while at the execution stage what you're doing is writing the saved PC to the LR/etc and the register compare (or accessing a condition code that may not have been calculated yet).

In many ways I guess it's a bit like a conditional branch that needs a write port - in RISCV, without condition codes, your conditional call relative branch distance will be smaller because the instruction encoding will need to encode 2-3 registers

Re: VRoom A high end RISC-V implementation

#74

Post by tsmi »

Lramseyer wrote: post #59
gary_0 wrote: post #46

Earlier quoted context omitted.

From what little I know about microarchitecture, this seems extremely impressive. Hopefully these aren't dumb questions: Are there GPL'd designs for PCIe, USB, etc, that could be used to incorporate this into a SoC design? If not, how much work is that compared to this? Also, what other kind of technical considerations would be involved to make this into a "real" chip on something like 28nm?

Not Paul Campbell, but I'll share what I know on the matter. So GPL'd IO blocks - This is a great question, and something I have definitely been asking myself! One thing to keep in mind is that IO interfaces like PCIe, USB, and whatnot have a Physical interface ("Phy" for short.) Those contain quite a bit of analog circuitry, which is tied to the transistor architecture that's used for the design. That being said, A…

One advantage of SkyWater opening its PDK is Universities are starting to back fill all the hardware that is missing.

Here's a SerDes from Purdue. I don't think this particular design has been validated in silicon yet though.

https://arxiv.org/abs/2105.13256

Re: VRoom A high end RISC-V implementation

#75

Post by tromp »

Taniwha wrote: post #45
sitkack wrote: post #34

Earlier quoted context omitted.

What does your benchmarking workflow look like? I am interested in * From a high level what does your dev iteration look like? * Getting instruction traces, timing and resimulating those traces * Power analysis, timing analysis (do you do this as part of performance simulation) ? * Do you benchmark the whole chip or specific sub units? * How do you choose what to focus on in terms of performance enhancements? * What…

At the moment I'm just starting working my way up the hierarchy of benchmarks, dhrystone's been useful though it's nearing the end of its use - I build the big FPGA version (on an AWS FPGA instance) to give me a place to run bigger things exactly like this. I currently run low level simulations in Verilator where I can easily take large internal architectural trace, and bigger stuff on AWS (where that sort of trace i…

> dhrystone's been useful though it's nearing the end of its use

Would my fhourstones [1] [2] benchmark be of any use?

[1] https://tromp.github.io/c4/fhour.html

[2] https://openbenchmarking.org/test/pts/fhourstones

Re: VRoom A high end RISC-V implementation

#76

Post by [deleted] »

Taniwha wrote: post #45
sitkack wrote: post #34

Earlier quoted context omitted.

What does your benchmarking workflow look like? I am interested in * From a high level what does your dev iteration look like? * Getting instruction traces, timing and resimulating those traces * Power analysis, timing analysis (do you do this as part of performance simulation) ? * Do you benchmark the whole chip or specific sub units? * How do you choose what to focus on in terms of performance enhancements? * What…

At the moment I'm just starting working my way up the hierarchy of benchmarks, dhrystone's been useful though it's nearing the end of its use - I build the big FPGA version (on an AWS FPGA instance) to give me a place to run bigger things exactly like this. I currently run low level simulations in Verilator where I can easily take large internal architectural trace, and bigger stuff on AWS (where that sort of trace i…

[deleted]

Re: VRoom A high end RISC-V implementation

#77

Post by Taniwha »

tromp wrote: post #75
Taniwha wrote: post #45

Earlier quoted context omitted.

At the moment I'm just starting working my way up the hierarchy of benchmarks, dhrystone's been useful though it's nearing the end of its use - I build the big FPGA version (on an AWS FPGA instance) to give me a place to run bigger things exactly like this. I currently run low level simulations in Verilator where I can easily take large internal architectural trace, and bigger stuff on AWS (where that sort of trace i…

> dhrystone's been useful though it's nearing the end of its use Would my fhourstones [1] [2] benchmark be of any use? [1] https://tromp.github.io/c4/fhour.html [2] https://openbenchmarking.org/test/pts/fhourstones

thanks I'll have a look - I'm not so interested in raw scores, more about relative numbers so I can judge different architectural experiments

Re: VRoom A high end RISC-V implementation

#78

Post by dzaima »

titzer wrote: post #69
Taniwha wrote: post #62

Earlier quoted context omitted.

yes and no - there's a few issues here: 1 - architectural - RISCV has a nice clean ISA, it's adding instructions quickly, CMOV is contentious issue there - I'm not an expert on the history so I'll let others relitigate it - it's easy to add new instructions to a RISCV machine, unlike Intel/ARM it's even encouraged - however adding a new instruction to ALL machines is more difficult and may take many years. But unlike…

Note I was talking about a conditionall call instruction, which is very useful for, e.g. safety checks.

I imagine something like that might be viable in the to-be-designed RISC-V J extension, as safety checks (mostly in JITs) would be close to the only thing benefiting from this.

Though, maybe instead of a conditional call, a conditional signal could do, which'd clearly give no expectation of performance if it's hit, simplifying the hardware effort required.

Re: VRoom A high end RISC-V implementation

#79

Post by rwmj »

Taniwha wrote: post #67
gary_0 wrote: post #46

Earlier quoted context omitted.

From what little I know about microarchitecture, this seems extremely impressive. Hopefully these aren't dumb questions: Are there GPL'd designs for PCIe, USB, etc, that could be used to incorporate this into a SoC design? If not, how much work is that compared to this? Also, what other kind of technical considerations would be involved to make this into a "real" chip on something like 28nm?

Great questions - I'm using an open source UART from someone else, an d for the AWS FPGA system I have a 'fake' disk driver plus timers/interrupt controllers etc So far I haven't needed USB/ether/PCIe/etc I've sort of sketched out a place for those to live - I think that for a high end system like this one you can't just plug something in - real performance needs some consideration of how: - cache coherency works - V…

Don't know much about the details, but this company / person claims to have developed some open source IP: http://www.enjoy-digital.fr/

Re: VRoom A high end RISC-V implementation

#80

Post by StillBored »

wrs wrote: post #30
codedokode wrote: post #27

The presentation was interesting; but I would like to write an idea that is tangentially related to this CPU. I noticed that modern CPUs are optimized for legacy monolith OS kernels like Linux or Windows. But having a large, multimegabyte kernel is a bad idea from a security standpoint. A single mistake or intentional error in some rarely used component (like a temperature sensor driver) can get attacker full access…

Long ago, we in the Newton project at Apple had that idea. We (in conjunction with ARM) were defining the first ARM MMU, so we took the opportunity to implement “domains” of memory protection mappings that could be quickly swapped at a context switch. So you get multiple threads in the same address space, but with independent R/W permission mappings. I think a few other ARM customers were intrigued by the security po…

Its similar to the original macOS, which used handles to track/access/etc memory requested from the OS and swap them to disk as needed. First you request the space, then you request access, which pinned it into ram.

PalmOS was another one that worked similarly. https://www.fuw.edu.pl/~michalj/palmos/Memory.html

Post reply on HN