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

21–30 of 100 posts

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

#21

Post by adapteva »

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.

I am sure the RISC-V core team has a much better answer. Their mission statement is a good start.

https://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-1...

The good news is that RISC has been around since the early 80's so any killer hardware patent will likely have expired by now. Note that the RISC-V ISA is separate from any hardware implementations. If you get fancy with your micro-architecture you can definitely trample on one of the 1000's of micro-architecture patents filed across the industry.

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

#22

Post by _chris_ »

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 depends on the benchmark, and it changes from basic block to basic block. A history of failed VLIW projects can attest to this. A dynamic superscalar is far superior, even in power-efficiency.

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

#23

Post by adapteva »

stolsvik wrote: post #20
nickpsecurity wrote: post #10

Good that they're getting on the bandwagon as they're already popular with maker types. I also like the serendipity where this post led me to an equally exciting one: http://www.adapteva.com/announcements/an-open-source-8gbps-l... Love that they developed and open-sourced a 8Gbps, 1us, I/O interface. That might come in handy. :)

GPL License - kills all hope.

Nope, it's now MIT license!!

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

#25

Post by cmrx64 »

nickpsecurity wrote: post #10

Good that they're getting on the bandwagon as they're already popular with maker types. I also like the serendipity where this post led me to an equally exciting one: http://www.adapteva.com/announcements/an-open-source-8gbps-l... Love that they developed and open-sourced a 8Gbps, 1us, I/O interface. That might come in handy. :)

Agree! I love adapteva for a lot of reasons, and this makes me want to keep on piling the love.

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

#27

Post by browser-bob »

zhemao wrote: post #13
browser-bob wrote: post #11

Can RISC-V be implemented in the on-board Xilinx Zynq 7020 FPGA of the A101040 (Epiphany III) Parallella?

Yes, definitely. Berkeley's open-source Rocket[1] core can already be programmed onto the Zedboard and ZC706[2], which also use Zynq 7000 series FPGAs. Getting it to work on the Parallela should just be a matter of changing the clock constraints and pin settings and finding a configuration that will fit on the FPGA. [1] https://github.com/ucb-bar/rocket-chip [2] https://github.com/ucb-bar/fpga-zynq

Neat-o! Thanks :)

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

#28

Post by purpled_haze »

stolsvik wrote: post #20
nickpsecurity wrote: post #10

Good that they're getting on the bandwagon as they're already popular with maker types. I also like the serendipity where this post led me to an equally exciting one: http://www.adapteva.com/announcements/an-open-source-8gbps-l... Love that they developed and open-sourced a 8Gbps, 1us, I/O interface. That might come in handy. :)

GPL License - kills all hope.

Even though it isn't GPL anymore, how exactly would it kill all hope?

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

#29

Post by protomyth »

_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 it's hugely incompatible with general-purpose application core."

Has anyone ever done a study / experiment of a VLIW with multiple hardware threads and how that would impact the need for an even mix?

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

#30

Post by nickpsecurity »

purpled_haze wrote: post #28
stolsvik wrote: post #20

Earlier quoted context omitted.

GPL License - kills all hope.

Even though it isn't GPL anymore, how exactly would it kill all hope?

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're going to need something that integrates with proprietary if you want them to build on it. There's still the possibility of a LGPL-style thing where at least re-synthesized or optimized versions of the open-source part must be re-released. However, forcing that for I.P. it integrates with would kill adoption by any provider unless they like operating at six to eight digit losses. Annually.

Post reply on HN