Hacker News Reader

_chris_on Ara: A 1 GHz+ Scalable and Energy-Efficient RISC-V Vector Processor

There were a ton of talk submissions, and the schedule is incredibly tight because of it. =(

_chris_on Ara: A 1 GHz+ Scalable and Energy-Efficient RISC-V Vector Processor

It's still a work-in-progress, but there should be some interesting news at the RISC-V Zurich conference next week [1]. For example, Imperas has announced an ISA simulator for the current 0.71 version of the specification [2].

[1] (https://tmt.knect365.com/risc-v-workshop-zurich/agenda/1)

[2] (http://imperas.com/articles/imperas-delivers-first-risc-v-si...)

_chris_on Godson-3: A Scalable Multicore RISC Processor with x86 Emulation (2009)

For starters, you need a mechanism to notify other cores that their instructions have changed. That may mean requiring coherent icaches, or maybe some more explicit but simpler mechanism.

_chris_on Verilator: Fast, Free Verilog HDL Simulator

> It requires Gtkwave to view waveforms with (opinion, but I hate the UI)

It dumps a value-change file (vcd) which can be viewed by anything, no? Sure it's not very compressed (and the compile-time for vcd-generation is unfortunate), but it's not a show-stopper.

_chris_on SweRV – An Annotated Deep Dive of the SweRV RISC-V Core

> When you have a look at the SweRV architecture and implementation, it is not incredibly complex, especially compared to, an out-of-order triple-issue A-15 core. And yet it achieves similar or higher CoreMark/MHz scores.

FYI, Coremark fits entirely within an L1 cache, so performance is significantly effected by load-to-use and load-to-load delay. The "skewed" pipeline design of SweRV helps it really shine here! The OOO cores typically have worse load-to-use and the OOO advantage typically shows up once you start missing in the L1 cache.

The remaining significant factor to Coremark performance is a good branch predictor, and to that end, I'm very impressed that their gshare can completely learn Coremark.

_chris_on SIMD Instructions Considered Harmful (2017)

Too far away and requires huge thread counts to make up for its overheads. A good vector unit should work well even for very short vectors (e.g., any size of memcpy).

_chris_on Verilog sources for Western Digital's open source RISC-V core

The core speaks AXI and AHB-Lite, so for an experienced FPGA/core guy, it probably wouldn't be too much work to integrate into their own FPGA flow. And since it doesn't have any floating-point, it will probably be able to fit on modestly-sized FPGAs.

_chris_on Apple resumes selling iPhone SE at lower $249 price on its clearance store

> Do HN readers have an unusual like for ‘small’ phones or is it just an unserved market?

My wife wants a phone that can fit into her jean pockets. Requiring handbags just to carry a phone around is absurd, and untenable for many people.

_chris_on Why MIT uses Python instead of Scheme for its undergraduate CS program (2009)

10 years ago; I'd really like to hear a post-mortem of this decision.

For context, MIT's previous EECS curriculum began with 4 required courses for all EE and CS majors. This meant that EEs had to suffer through Scheme, and CS'ers had to suffer through circuits. I'm sure everyone has their own opinion on whether this is a good thing or a bad thing.

Regardless, the EECS department switched to a new 7(?) "core" class format in which students choose 4(?), giving students the freedom to take more relevant courses to their interests/major. In this switch, 6.001 (scheme) was out and replaced with a more hands-on robotics-based Python lab class.

I can't really say which approach is better, but I do think there's an important place for the more pure "thinking" computer science classes too, even if it's not the first class taught to freshmen.

_chris_on MIPS Goes Open Source

In comparing RISC-V vs MIPS, I think people are forgetting that one is a Foundation of member companies driving development, and the other is one company releasing their IP.

There's obvious pluses and minuses to both approaches, but if I were a company trying to choose an ISA for my own IP development, I'd probably want the ISA that has a Foundation I can join and help drive its direction going forward [Ed: it will be interesting to see how MIPS proceeds from here].

_chris_on BOOM Open Source RISC-V Core Runs on Amazon EC2 F1 Instances

And in video form, if that's your thing: https://www.youtube.com/watch?v=_mZORF2vHAA&feature=youtu.be....

_chris_on BOOM Open Source RISC-V Core Runs on Amazon EC2 F1 Instances

No, the IO plumbing and infrastructure are different. FPGAs are a total pain because each platform is different. :'(

_chris_on BOOM Open Source RISC-V Core Runs on Amazon EC2 F1 Instances

I don't remember numbers (and resources aren't always apples-to-apples), but it's bigger than a Zedboard and 60% of a zc706 I believe. It's a ton of wires is the big issue I suspect.

_chris_on BOOM Open Source RISC-V Core Runs on Amazon EC2 F1 Instances

My parents thought it was quite odd that I named it the Berkeley Out of Order Machine. "Why would you advertise to the world that it doesn't work?"

_chris_on BOOM Open Source RISC-V Core Runs on Amazon EC2 F1 Instances

Unless you cut out floating point and superscalar, it requires a fairly large FPGA, on the order of >$1000. So you'd have to put it to serious use to break even with using AWS.

The other advantage of AWS is scale-out once you want to get benchmark data and not wait forever (or to simulate warehouse scale computers). In the past, maintaining our own FPGA cluster was a nightmare.

_chris_on One Reason That MIT Should Reinstate Scheme and 6.001 (2009)

It's been over 10 years now. Is there a good post-mortem on the outcome of the switch away from 6.001 and Scheme?

_chris_on A Plan 9 C compiler for RISC-V [pdf]

> But I'm not quite sure what's holding up general purpose CPUs (even just something crappy/good-enough).. The way I understand it CPUs aren't just beefy microcontrollers and they require some extra onchip hardware, but no one has done that yet for some reason.. Maybe someone knows better :)

There's general-purpose RISC-V CPU RTL lying around, and it's not too difficult to license the necessary peripherals, but it costs money to put together a board and fabricate at volume if you want to hit a Raspberry Pi/hobbyist price point. Unfortunately, it takes time and you need a market to justify the effort. But eventually it'll happen.

_chris_on Lerna adds clause to MIT license blocking certain companies from using it

I'm pretty sure adding a more restrictive license clause is a fork of the code base and any new code commits would use the newer, more restrictive license.

_chris_on Open source RISC-V implemented from scratch in one night

Sandsifter is dealing with the problem of "how do I find valid instructions in any 1-15 byte sequence, which yields 2^120 combinations?"

In RISC-V there are currently only 2 byte and 4 byte instructions, which you can brute force your way through. The specification does technically allow for longer sequences, in which case sandsifter will work just fine. [And the RISC-v privileged specification has existed for years].

_chris_on Open source RISC-V implemented from scratch in one night

RISC-V is pretty nice in that the ISA gets out of your way, and you can focus on the techniques to build a high-performance processor without wasting effort on legacy and other weird corner case behaviors. A++, would recommend.

However, if you want to build really high performance cores, there are plenty of challenging techniques you have to employ that add a lot of complexity that is hidden below the ISA abstraction layer (speculation for example).

So if you want to make RISC-V go fast, you have to employ more design tricks like "macro-op fusion". For example, scan for two load instructions in the fetch stream and fuse them into a single "load-pair" micro-op if they access adjacent addresses. There are a whole bag of tricks like this that are irrespective of the ISA and add a fairly high "skill-ceiling" to processor design.

_chris_on Solving Spectre and Meltdown may ultimately require a new type of processor

I gave a talk on this topic at a recent RISC-V conference (slides here: [1]).

I think this can entirely be hidden below the ISA abstraction, but it will be a lot of development work to do this and unfortunately getting new hardware into the field is a slow process. One part of this is buffering and killing speculative updates (or flushing on "time domain" switches). The other, and harder part, is to manage/avoid bandwidth contentions caused by speculation.

I think the better, long-term solutions will involve address IDs/capabilities to better denote security boundaries to the hardware. But that requires a lot of buy-in across many layers of the compute stack(OS/platform change for starters).

[1] https://content.riscv.org/wp-content/uploads/2018/05/13.00-1...

_chris_on The MRISC32 – A vector first CPU design

If your processor uses register renaming, the frequency of your core limits how many physical registers you can have in the register file. Therefore, you are incentivized to split integer and floating point register files so you can size up each register file to its limit.

You can also play other games like internal recoding the FP format if you split the register files.

On the other hand, you can remove the need for IntToFP and FPToInt move instructions if you use one register file.

At the end of the day though, I suspect it largely comes down to having more addressable architectural state to keep the two register files separate. Why have only 32 scalar registers when you can have 32 scalar int and 32 scalar fp registers?

_chris_on RISC-V Boom CPU

Nope, just a small batch test-chip run. And even out of a few dozen chips, I think we only did packaging for ~5 chips.

It boots Linux, but at 6 mm^2, it's not really big enough to contain an on-chip memory controller, so going out to DRAM is through an FPGA controller and thus is painful.

_chris_on Arm kills off its anti-RISC-V site after own staff revolt

Adapteva did not use RISC-V. Andreas Olofsson said that, if there was another version, he would probably use RISC-V.

[http://www.adapteva.com/andreas-blog/why-i-will-be-using-the...]

_chris_on Speculative buffer overflows: attacks and defenses. (Spectre BCBS) [pdf]

https://01.org/security/advisories/intel-oss-10002 (CVE-2018-3693).

_chris_on ARM: “RISC-V Architecture: Understand the Facts”

And then they started raising the licensing fees. Man what bad timing.

_chris_on ARM: “RISC-V Architecture: Understand the Facts”

Off the top of my head, Western Digital and NVIDIA have both announced using RISC-V in their upcoming products.

_chris_on ARM: “RISC-V Architecture: Understand the Facts”

I think you underestimate just how many hardware startups there are and how many of them are NOT going to license an ARM core for their service core.

_chris_on ARM: “RISC-V Architecture: Understand the Facts”

Apologies, I may be speaking out of my $(# on that. I'm aware Clifford has used it to demonstrate formal method techniques, but I don't know the full extend to it. Caveat Emptor to anyone who decided to rush out and add it to their SoC. ;)

_chris_on ARM: “RISC-V Architecture: Understand the Facts”

Let's say I'm making an SoC and I need an always-on service processor. It's a waste of effort for me to make it myself, so I'll either license one or grab one off the internet, if I could trust it.

In the past, people just threw a little bit of money to ARM and called it a day.

But now, I could grab picorv32 or rocket for free off the internet. Both have been taped out in this capacity before, both speak standard bus interfaces, and the former has been fully(?) formally verified.

Sure, it's not a resounding success story, but it helps me get my SoC to market sooner and at a lower cost (no need to even spend time negotiating with anybody).