An FPGA-friendly 32-bit RISC-V CPU implementation • Hacker News Board

Re: An FPGA-friendly 32-bit RISC-V CPU implementation

#41

Post by Dolu » Thu, Jul 20, 2017, 9:13 AM UTC

SoylentYellow wrote: post #20

What license are you releasing this under, if any?

Honnestly, i haven't realy think about it. Not a constraining one, but more something like :

Do what ever you want with it, but if you find a bug, please tell me, and if you use it in a project which has a lot of money, please, share a bit with opensource guys, don't be too greedy ^^

Re: An FPGA-friendly 32-bit RISC-V CPU implementation

#42

Post by Dolu » Thu, Jul 20, 2017, 9:24 AM UTC

debatem1 wrote: post #37

aseipp wrote: post #23

Earlier quoted context omitted.

Honestly, I'd wager it's because Verilog and VHDL suck in a lot of ways basically. They work, but almost anything has better abstraction and reuse capabilities, even embedded DSLs or bespoke compilers or whatever, and offer better feedback loops during development. REPLs help a lot when building big circuits out of smaller ones. Being able to use a package manager to grab and manage SoC/IP components is convenient, e…

I suspect you're right, but it makes me sad. I really like verilog as a language and after working with it for a few years wish it was possible to program desktops in a similar way.

I was exactly in the same mood some years ago, until i triey one of those HDL alternative.

Re: An FPGA-friendly 32-bit RISC-V CPU implementation

#43

Post by monocasa » Thu, Jul 20, 2017, 3:53 PM UTC

duskwuff wrote: post #35

monocasa wrote: post #33

Earlier quoted context omitted.

They are usable externally. The Realview boards use it to connect a CPU chip with an external northbridge, but it's really rare. Even in that case, it's just because the Realview board is meant to prototype SoCs with the help of an FPGA.

Usable, but only barely. As AXI / APB3 are intended for on-die communications, they lack the line coding and error correction used by other busses like PCIe or SATA. On the upside, though, they take a lot less area to implement.

That's more a distinction between serial and parallel buses than on-chip/off chip. If you're not pumping a single signal to gbps speeds, you don't need the clock recovery and ECC that serdes style connections imply.

It all depends on your use case.

Re: An FPGA-friendly 32-bit RISC-V CPU implementation

#44

Post by dang » Thu, Jul 20, 2017, 8:34 PM UTC

microcolonel wrote: post #28

ajross wrote: post #17

Earlier quoted context omitted.

You've lost me on what you're arguing. I'm saying "we want to spend more time integrating open hardware designs into RISC-V devices and less time making new CPU cores in our fun new HDLs". And you're saying "we can't" because... why? I know that junk is there on OpenCores too. I've looked at it. I've synthesized some of it. No one uses it on silicon. That's the part we need to fix. And it's not because of SPICE param…

> You've lost me on what you're arguing. I'm saying "we want to spend more time integrating open hardware designs into RISC-V devices and less time making new CPU cores in our fun new HDLs". Why don't you quit being an arrogant armchair architect prick on Hacker News, telling everyone what they should and should not be doing, and do it yourself. This is not an open hardware project, this is a soft CPU core intended f…

Yikes. Personal attacks aren't allowed here and we ban accounts that do that, so please don't do that again. Your comment would be just fine if it were just the middle paragraph.