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

Why I will be using RISC-V in my next chip

adapteva.com

Post reply on HN
Print view View original

41–50 of 100 posts

Re: Why I will be using RISC-V in my next chip

#41

Post by wildmusings »

colejohnson66 wrote: post #38
nickpsecurity wrote: post #30

Earlier quoted context omitted.

How much do you see going on in GPL'd hardware despite tools and motivation being available going back decades? Almost nothing. Takes expensive tools, limited expertise, expensive masks for prototyping... all sorts of expenses that mean it virtually doesn't happen unless cost can be recovered. Stuff is so outrageously expensive and difficult at better nodes that re-using proven (costly) I.P. is the norm. Hence, you'r…

How does the GPL prevent them from making money? Sure, I have essentially the source code of someone's processor, but unless I have millions of dollars to fabricate a chip, the source's only use is to learn how things work. Intel, if they wanted to, could release the source code of their microcode for their processors under the GPLv2 and not provide the signing certificate (like TiVo did), and all people would be abl…

Intel has competitors. Why would Intel want to provide its competitors with what must be, at the very least, tens of millions of dollars worth of work?

Re: Why I will be using RISC-V in my next chip

#42

Post by codebook »

I'm still not sure whether RISC-V will be one of main stream microprocessor in the industry field.

1. Still the core is not yet solid.

2. Not much powerful debugging tools exist.

3. Chisel itself. Every engineer who is willing to use RISC-V should understand output of chisel source code in order to do ECO or some other low level jobs.

4. BSD itself. It is strong and also weakness. There's no way to merge revision into main repository. It will not be quite trouble if RISC-V remains as it is. But will be a big problem if RISC-V evolves by its own development team.

I hoped this RISC-V becomes mainstream processor since I attended the lecture from Mr.Yunsup Lee 4 years ago. I really want to say "I was wrong at that moment" after all.

Re: Why I will be using RISC-V in my next chip

#43

Post by _chris_ »

codebook wrote: post #42

I'm still not sure whether RISC-V will be one of main stream microprocessor in the industry field. 1. Still the core is not yet solid. 2. Not much powerful debugging tools exist. 3. Chisel itself. Every engineer who is willing to use RISC-V should understand output of chisel source code in order to do ECO or some other low level jobs. 4. BSD itself. It is strong and also weakness. There's no way to merge revision int…

Chisel? There are dozens of non-Chisel RISC-V cores out there already (and many more that are closed source and being used by companies like Bluespec and Rumble).

Re: Why I will be using RISC-V in my next chip

#44

Post by zhemao »

codebook wrote: post #42

I'm still not sure whether RISC-V will be one of main stream microprocessor in the industry field. 1. Still the core is not yet solid. 2. Not much powerful debugging tools exist. 3. Chisel itself. Every engineer who is willing to use RISC-V should understand output of chisel source code in order to do ECO or some other low level jobs. 4. BSD itself. It is strong and also weakness. There's no way to merge revision int…

There's a distinction between the RISC-V ISA and our open source processor implementations. The ISA is an open standard that anyone can make an implementation of. There are many RISC-V implementations out there. Most of them are not based on our RocketChip codebase and use Verilog, not Chisel.

Re: Why I will be using RISC-V in my next chip

#45

Post by nickpsecurity »

wildmusings wrote: post #41
colejohnson66 wrote: post #38

Earlier quoted context omitted.

How does the GPL prevent them from making money? Sure, I have essentially the source code of someone's processor, but unless I have millions of dollars to fabricate a chip, the source's only use is to learn how things work. Intel, if they wanted to, could release the source code of their microcode for their processors under the GPLv2 and not provide the signing certificate (like TiVo did), and all people would be abl…

Intel has competitors. Why would Intel want to provide its competitors with what must be, at the very least, tens of millions of dollars worth of work?

You have the right idea but it's way more that you think. Intel spends over a billion dollars per quarter on all their tech.

https://ycharts.com/companies/INTC/r_and_d_expense

I agree R&D on any given bit of HW design is at least tens of millions. Probably more than once per year going back a decade given it's custom and formally verified. Standard cell approximating that would be a fraction of it but still ridiculously high if aiming for competitive performance/watt.

Re: Why I will be using RISC-V in my next chip

#46

Post by userbinator »

I'm surprised to see a lot of RISC proponents still around, because I think it's quite clear that things didn't quite work out the way they thought it would --- the vision of cheap, simple, high-performance CPUs just didn't happen. Thus I'm not of the opinion that another "MIPS, but free" architecture is such a good idea.

Benchmarks are controversial but by most measures the RISC-V performance should be “good enough” for most use cases

In my experience, statements like this really mean "it's actually really bad, but we don't want to say that"... after all, who would call benchmarks "controversial" if they were winning? There do tend to be few comparative benchmarks, but here's one that shows how ARM and x86 are competitive, but MIPS is behind in energy efficiency:

http://www.extremetech.com/extreme/188396-the-final-isa-show...

Even modern ARM cores, an architecture that started out being very RISC, use microinstruction-based translation in their front end and probably have more in common with Intel's microarchitectures than MIPS and the like.

I think a "CISC-V" could be more interesting - something x86-like (AFAIK the remaining patents are only on the Pentium and above instruction set extensions, and those may expire soon, so 486 and below are now public-domain ISAs) with a small dense instruction set, but extended in a different direction. "x86, but free". ("ARM, but free" would likely not work for legal reasons.)

Re: Why I will be using RISC-V in my next chip

#47

Post by userbinator »

nickpsecurity wrote: post #40
colejohnson66 wrote: post #38

Earlier quoted context omitted.

How does the GPL prevent them from making money? Sure, I have essentially the source code of someone's processor, but unless I have millions of dollars to fabricate a chip, the source's only use is to learn how things work. Intel, if they wanted to, could release the source code of their microcode for their processors under the GPLv2 and not provide the signing certificate (like TiVo did), and all people would be abl…

Main reply here: https://news.ycombinator.com/item?id=10873839 Microcode is a separate issue that's debateable. Their CPU hardware, patents, logistics, ecosystem, and branding are real source of revenue. Microcode release might nit hurt them. However, it might contain trade secret methods for utilizing hardware in a clever way that could give competition (mainly startups) an edge. Biggest players, esp AMD, probably a…

That said, Im for opening up microcode and even push for microcoded RISC-V.

You mean a CISC-V? ;-)

Re: Why I will be using RISC-V in my next chip

#48

Post by nickpsecurity »

userbinator wrote: post #47
nickpsecurity wrote: post #40

Earlier quoted context omitted.

Main reply here: https://news.ycombinator.com/item?id=10873839 Microcode is a separate issue that's debateable. Their CPU hardware, patents, logistics, ecosystem, and branding are real source of revenue. Microcode release might nit hurt them. However, it might contain trade secret methods for utilizing hardware in a clever way that could give competition (mainly startups) an edge. Biggest players, esp AMD, probably a…

That said, Im for opening up microcode and even push for microcoded RISC-V. You mean a CISC-V? ;-)

Lol. Clever. I'll keep it Microcoded RISC-V until people start doing something bloated like emulating x86 in it. ;)

cough Loongson people cough

Re: Why I will be using RISC-V in my next chip

#49

Post by userbinator »

_chris_ wrote: post #22
dbdjxjcnd wrote: post #2

SIMD and VLIW are the future of microprocessors, and unfortunately it doesn't seem like this ISA will be able to support them.

There's a chapter in the current RISC-V manual that explains how you could make a RISC-V-like VLIW ISA. But VLIW is most certainly NOT the "future". VLIW demands an even "mix" of instruction types, and that's largely incompatible with general-purpose application code. And the concept of baking into your ISA what the designer believes is the "perfect functional unit mix" is an anti-pattern. What's the perfect mix depe…

VLIW demands an even "mix" of instruction types, and that's largely incompatible with general-purpose application code.

The Itanium is a great example of this. Benchmarks that pushed the CPU to its limits looked amazing, but real-world performance with general-purpose code was awful. There just isn't enough parallelism in general-purpose code to justify extremely huge instruction bundles that will mostly be wasted with NOPs.

Re: Why I will be using RISC-V in my next chip

#50

Post by e12e »

userbinator wrote: post #46

I'm surprised to see a lot of RISC proponents still around, because I think it's quite clear that things didn't quite work out the way they thought it would --- the vision of cheap, simple, high-performance CPUs just didn't happen. Thus I'm not of the opinion that another "MIPS, but free" architecture is such a good idea. Benchmarks are controversial but by most measures the RISC-V performance should be “good enough”…

But aren't modern Intel and AMD CPUs internally RISC(-like)? It seems like we have great compilers for CISC targets, and can make great RISC CPUs that process CISC instruction sets really well?

Perhaps the issue is that the internals of eg. modern Intel CPUs are locked up at Intel, so the missing step from CISC assembly to efficient RISC is missing (while we've got high-level/C/C++ to CISC covered)?

Post reply on HN