Can RISC-V be implemented in the on-board Xilinx Zynq 7020 FPGA of the A101040 (Epiphany III) Parallella?
Why do you want to do that? Isn't there a hard ARM core on the Zynq 7000s ?
Why I will be using RISC-V in my next chip
81–90 of 100 posts
Re: Why I will be using RISC-V in my next chip
#82Earlier 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).
nVidia Kepler and Maxwell (i.e. the two latest archs ATM) use VLIW instruction encoding
Do they? I can't find anything about it. VLIW for GPUs is always only mentioned in the context of AMD TeraScale – which has been obsoleted in favour of a RISC architecture five years ago.
Re: Why I will be using RISC-V in my next chip
#83Earlier quoted context omitted.
Even though it isn't GPL anymore, how exactly would it kill all hope?
How does the GPL apply to hardware? Let's say I take some GPL'ed verilog code, modify it a bit, build a chip out of it and sell the chip. Am I required to provide the verilog "source" for my chip? I guess if the chip counts as "object code" in GPL lingo then the answer is yes. There's a lot more than just the verilog code that goes into building a chip though. How is the physical layout, for example, handled? Is that…
I found an interesting and detailed legal analysis of that. It sounds like the answer isn't black and white:
http://jolt.law.harvard.edu/articles/pdf/v25/25HarvJLTech131...
Re: Why I will be using RISC-V in my next chip
#84Earlier quoted context omitted.
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?
Sure, that's fair. I was just pedantic about the precise meaning of a "synthetic" benchmarks, which is a benchmark generated to mimic real code but isn't a real/useful application by itself.
Re: Why I will be using RISC-V in my next chip
#85Earlier quoted context omitted.
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.
Oh OK
Re: Why I will be using RISC-V in my next chip
#86Earlier quoted context omitted.
"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?
100% sure - once you have the masks, pumping out chips is cheap, if you do it in volume. http://www.adapteva.com/andreas-blog/semiconductor-economics...
Key quotes:
"Super complex SOC platforms like Apple’s Ax family or the IBM Cell very likely exceeded $1B in total development costs and involved thousands of engineers in aggregate."
"Meanwhile relatively simple SOCs like the Epiphany family of chips were designed for less than $3M over the span of 3 years.[1,2]"
And Adapteva did such a good job being cheaper than average they wrote a [different] blog post about how they went about it. So, the low end was $3 million over 3 years while users wanting to ditch proprietary are asking for price/performance/watts closer to the above quote that cost $1 billion. Hence, my prediction it will take millions to tens of millions to make something acceptable. Also, me pushing Cavium's model of RISC multicore + HW accelerators for common things. I think it will help by taking load (& optimization) off the main CPU's.
Now, people doing analog stuff have it a lot easier given even 350nm is often good for that. That stuff can get really cheap:
http://www.planetanalog.com/author.asp?section_id=526&doc_id...
Re: Why I will be using RISC-V in my next chip
#87Earlier quoted context omitted.
Even though it isn't GPL anymore, how exactly would it kill all hope?
How does the GPL apply to hardware? Let's say I take some GPL'ed verilog code, modify it a bit, build a chip out of it and sell the chip. Am I required to provide the verilog "source" for my chip? I guess if the chip counts as "object code" in GPL lingo then the answer is yes. There's a lot more than just the verilog code that goes into building a chip though. How is the physical layout, for example, handled? Is that…
I was hoping someone jumped in for context. The other two commenters provide that. Now, in that context, let's just say that the ASIC ecosystem with companies sitting on hundreds of millions to billions in I.P. aren't about to (a) integrate a GPL component or (b) let their stuff be used in a GPL component if there's even the slightest chance it causes legal risk.
That's all the good ones. The only exception I know (and promote) was Aeroflex Gaisler putting an ASIC-proven CPU and peripheral IP in a GPL release. That people did nothing with. (sighs) Even he's not doing GPL for new stuff IIRC. The rest continue licensing on a per-producer basis... revenue which GPL would negate.
So, it's just incentives. The positive incentive is licensing, which they're doing. The negative incentives are anything risking their I.P., which GPL does. It's a double whammy against GPL'd or even free HW from existing ecosystem.
Re: Why I will be using RISC-V in my next chip
#88Earlier quoted context omitted.
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.
VLIW is many times cheaper (in terms of power and area) than OoO. It is not going anywhere from the low budget range.
But VLIW and OoO aren't the only two design points. The renewed interest in traditional inorder vector processors. In any case, I do think the point of DSPs was to be area/power efficient for certain specialized algorithms, and a lot of these are just becoming ASICs/specialized accelerators today.
Re: Why I will be using RISC-V in my next chip
#89Earlier quoted context omitted.
nVidia Kepler and Maxwell (i.e. the two latest archs ATM) use VLIW instruction encoding
Do they? I can't find anything about it. VLIW for GPUs is always only mentioned in the context of AMD TeraScale – which has been obsoleted in favour of a RISC architecture five years ago.
I guess that's because unlike AMD, nVidia doesn't officially document the GPU instruction set. But if you disassemble .cubin with nvdisasm, you'd see that code of Kepler/Maxwell is organized in bundles of 4/8 words, where the first word doesn't encode any instruction. Here is what Scott Gray of Nervana Systems, who developed a native assembler for Maxwell, write about it[1]: "Starting with the Kepler architecture Nvidia has been moving some control logic off of the chip and into kernel instructions which are determined by the assembler. This makes sense since it cuts down on die space and power usage, plus the assembler has access to the whole program and can make more globally optimal decisions about things like scheduling and other control aspects. The op codes are already pretty densely packed so Nvidia added a new type of op which is a pure control code. On Kepler there is 1 control instruction for every 7 operational instructions. Maxwell added additional control capabilities and so has 1 control for every 3 instructions."
[1] https://github.com/NervanaSystems/maxas/wiki/Control-Codes
Re: Why I will be using RISC-V in my next chip
#90Earlier 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?
There is no typical...but here are some guidelines
1.2x (companies are either ultra efficient, copycats, suicidal, or dumping)
2x (US companies shipping volume, healthy)
4x (goal for FPGA companies and mixed signal niche)
10x (goal for companies with monopolies)
100x (one-offs, like processors for military/satellite)