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

61–70 of 100 posts

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

#61

Post by nickpsecurity »

krupan wrote: post #55
nickpsecurity wrote: post #39

Earlier quoted context omitted.

By allowing anyone to knock off the chip without paying back the R&D. There's already a huge market of counterfeits and clones coming out of China for most things you can think of. It's even easier without reverse engineering: hand design to a fab, individual or MPW, then package and sell the chips. Very little of the price of chips you buy is the material or packaging costs. It's mostly R&D recoup, marketing, admini…

"Very little of the price of chips you buy is the material or packaging costs." Are you sure about that? How much markup over material costs is there on most chips?

I'm not sure on most chips. I do know if you look up MOSIS, etc prices you'll find that most of the cost of the prototyping run is the masks. The masks start at tens of thousands then just go up from there. High-end nodes are in millions to tens of millions. Every prototype run of your chip takes a new mask. Hence, all the money spent on proprietary tooling to reduce odds of digital or physical defects. Many ASIC's still need respins. Then, there's 3rd party stuff like I/O packages.

Now, compared to that, the silicon wafer might cost a few grand with packaging (not volume) costing $10-20 a unit. For any OSS project, dare I say most of the cost will be in the first paragraph and recouping it will take significant unit prices. How significant depends on what's being sold and at what volume. A PIC or AVR clone at modest volume will be cheaper than an Oracle T2 clone at low volume. Hope that helps.

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

#62

Post by nickpsecurity »

wildmusings wrote: post #58
nickpsecurity wrote: post #45

Earlier quoted context omitted.

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 ridiculou…

Yeah, Intel is one of the biggest companies in the world. I was just speculating an absolute floor for just the microcode in particular.

You're the second person to bring up microcode. I'm curious why two are focused on this rather than the HW itself. What about you?

Note: For readers not in the know, microcode is the sequence of wiring activations of the physical, closed hardware. Instructions, merely series of bits, get translated to that by the microcode engine running from a memory rather than hardwired engine. Unlike the ISA, it's highly tied to the hardware since it drives it directly.

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

#63

Post by wsxcde »

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”…

What are you qualifications in computer architecture? You're arguing against pretty much everyone in the field.

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

You seem to be implying that there's RISC failed. If you ask anyone who mattered in computer architecture ranging from academics like Patterson who literally wrote the most used books in the field to Intel fellows, they'll all tell you that the essential point the RISC folks were making was proven right. This point being that RISC is requires less logic (=area,power) to implement, it's easier to write compilers for, processors have faster cycle times, and so on.

In the end though, it turned out the market valued software compatibility over performance. That, good marketing and a phenomenally efficient supply chain and fab resulted in Intel winning. But don't confuse this with CISC winning or RISC losing. If Intel had to do a clean slate design today, they'd do RISC themselves. In fact, Intel have a few proprietary microcontrollers hidden inside their chipsets and SoCs that were designed post-2005ish and these have RISC architectures.

> 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:

The benchmark performance depends only on how much effort is put into optimizing the implementation. Intel have on average maybe 200 architects and 200 more designers tweaking their processors for performance for the last 30 years. It is completely absurd to expect a team of 10 or so grad students to compete with them.

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

#64

Post by wsxcde »

microcolonel wrote: post #56
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”…

The reason they're dancing around the performance figures is because a) synthetic benchmarks like SPEC and CoreMark are of questionable value, and b) They don't have chips in customers' hands quite yet, so they can't be independently reproduced. If you look at the current results for Rocket and BOOM, you'll find that these microarchitectures seem competitive with Cortex A5/A8 and Cortex A15 respectively at comparable…

Much more importantly, an Intel design team has something like 1200 engineers working for 2-2.5 years on the next generation of an existing processor. I don't know about ARM, but I'd guess they probably something like a team of 200-300 people on working on each revision.There's no way a team of 10 or so grad students can hope to out-optimize them.

Also SPEC isn't a synthetic benchmark, it contains real applications like bzip2 and gcc.

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

#65

Post by wsxcde »

WhitneyLand wrote: post #16

How does RISC-V get around the issue of patent mine fields? For example we've seen its really difficult to make a competitive codec without infringing and even when it's accomplished there is lingering doubt until it's challenged. I hope this situation is somehow much different.

Patterson says they've tried their best to make sure it doesn't infringe on patents they know about but they obviously can't provide any guarantees.

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

#66

Post by wsxcde »

_yosefk wrote: post #8
creshal wrote: post #7

Earlier quoted context omitted.

RISC-V has a vector mode that can be used for SIMD applications. VLIW has been the future since the 80s, and we're still waiting for the magic wonder compilers that can actually spit out efficient VLIW code. Even GPUs have abandoned VLIW (AMD TeraScale) in favour of RISC (Nvidia, AMD GCN).

VLIW DSPs are in every phone. VLIW CPUs are almost certainly a bad idea and as to GPUs, AFAIK VLIW needs to coexist with barrel threading there which might create problems. But VLIW certainly has its place.

I suspect the DSP makers just use VLIW because of interia. They probably don't have the money or incentive to revisit their old decisions.

Also wouldn't you say that most of the stuff that used to be implemented on DSPs is now moving into ASICs? I wouldn't be so sure that VLIWs are going to be around forever.

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

#67

Post by userbinator »

Marat_Dukhan wrote: post #54
e12e wrote: post #50

Earlier quoted context omitted.

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)?

No they aren't internally RISC. On big Intel & AMD cores "ADD reg, mem" translates to a single uop. On Intel Atom even "ADD mem, reg" translates to a single uop. In fact, it is mostly legacy instructions (e.g. binary-coded decimal arithmetic) that are translated into multiple uops.

x86 uops are very wide, much wider than RISC instructions and more like VLIWs; P6 uops are 118 bits and I haven't easily found any description of the newer models but they are likely even wider.

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

#68

Post by Marat_Dukhan »

userbinator wrote: post #67
Marat_Dukhan wrote: post #54

Earlier quoted context omitted.

No they aren't internally RISC. On big Intel & AMD cores "ADD reg, mem" translates to a single uop. On Intel Atom even "ADD mem, reg" translates to a single uop. In fact, it is mostly legacy instructions (e.g. binary-coded decimal arithmetic) that are translated into multiple uops.

x86 uops are very wide, much wider than RISC instructions and more like VLIWs; P6 uops are 118 bits and I haven't easily found any description of the newer models but they are likely even wider.

The latest number I have is 157 bits in Intel Core (for a ROB entry).

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

#69

Post by wildmusings »

nickpsecurity wrote: post #62
wildmusings wrote: post #58

Earlier quoted context omitted.

Yeah, Intel is one of the biggest companies in the world. I was just speculating an absolute floor for just the microcode in particular.

You're the second person to bring up microcode. I'm curious why two are focused on this rather than the HW itself. What about you? Note: For readers not in the know, microcode is the sequence of wiring activations of the physical, closed hardware. Instructions, merely series of bits, get translated to that by the microcode engine running from a memory rather than hardwired engine. Unlike the ISA, it's highly tied to…

I'm not focused on this, it was an example used in the post I responded to.

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

#70

Post by _chris_ »

wsxcde wrote: post #64
microcolonel wrote: post #56

Earlier quoted context omitted.

The reason they're dancing around the performance figures is because a) synthetic benchmarks like SPEC and CoreMark are of questionable value, and b) They don't have chips in customers' hands quite yet, so they can't be independently reproduced. If you look at the current results for Rocket and BOOM, you'll find that these microarchitectures seem competitive with Cortex A5/A8 and Cortex A15 respectively at comparable…

Much more importantly, an Intel design team has something like 1200 engineers working for 2-2.5 years on the next generation of an existing processor. I don't know about ARM, but I'd guess they probably something like a team of 200-300 people on working on each revision.There's no way a team of 10 or so grad students can hope to out-optimize them. Also SPEC isn't a synthetic benchmark, it contains real applications l…

The problem with SPEC is it is a 1990's workstation benchmark suite... should my cell phone processor's design be guided by how quickly it can compile ia32 code? Or simulate quantum computers?
Post reply on HN