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

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

github.com

Post reply on HN
Print view View original

31–40 of 44 posts

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

#31

Post by femto »

bedros wrote: post #30
Dolu wrote: post #26

Earlier quoted context omitted.

Are you sure it need a license ? I were thinking that AXI usage is royalities free ( https://en.wikipedia.org/wiki/Advanced_Microcontroller_Bus_A... )

that's my understanding from talking to an engineer at Qualcomm, however, if there's no need for a license, then it would make it lower cost to build SOC with off the shelf AXI IP

I've never understood why some people say a license is needed for something on which patents have expired. What's the legal basis, or is it bluff?

I can understand that copyright exists in the documentation that describes AXI, but that copyright covers only their documentation and not your own implementation (or is some derivation claimed?). I can understand that trademark might exist in the name "AXI", so don't use that name. Trade secrets seem to be moot, if you're not associated with whoever is keeping the secret. If none of the above apply, what basis is there for demanding a license?

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

#33

Post by monocasa »

zokier wrote: post #18
Dolu wrote: post #5

Earlier quoted context omitted.

Yes, silicon implementation provide the JTAG, but it's very likely their implementation will not be reusable for FPGA project (including JTAG debug things) because of their over complicated (but powerfull) solutions which would consume way to much area and restrict the FMax. Then this specific VexRiscv ecosystem also provide a basic SoC with an multi master AXI4 inteconnect, SDRAM controller, embedded ram, APB3 inter…

Is either AXI4 or APB3 usable as external bus (like PCI(/e)), or are they intended for on-die communication?

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.

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

#34

Post by shakna »

femto wrote: post #31
bedros wrote: post #30

Earlier quoted context omitted.

that's my understanding from talking to an engineer at Qualcomm, however, if there's no need for a license, then it would make it lower cost to build SOC with off the shelf AXI IP

I've never understood why some people say a license is needed for something on which patents have expired. What's the legal basis, or is it bluff? I can understand that copyright exists in the documentation that describes AXI, but that copyright covers only their documentation and not your own implementation (or is some derivation claimed?). I can understand that trademark might exist in the name "AXI", so don't use…

Licenses still apply post-expiry, in the US, Australia and a few other places.

It didn't use to be this way, but around the 80s the big precedents for this.

Most of the time, if you were a licensee before the expiry, then you continue to be so post-expiry. If however, you were not, then you have no existing contractual obligation, and can use it.

However it is something you need to consult a lawyer on, before making any decisions, because this area of law is more complicated than most, and is growing in complexity.

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

#35

Post by duskwuff »

monocasa wrote: post #33
zokier wrote: post #18

Earlier quoted context omitted.

Is either AXI4 or APB3 usable as external bus (like PCI(/e)), or are they intended for on-die communication?

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.

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

#36

Post by femto »

shakna wrote: post #34
femto wrote: post #31

Earlier quoted context omitted.

I've never understood why some people say a license is needed for something on which patents have expired. What's the legal basis, or is it bluff? I can understand that copyright exists in the documentation that describes AXI, but that copyright covers only their documentation and not your own implementation (or is some derivation claimed?). I can understand that trademark might exist in the name "AXI", so don't use…

Licenses still apply post-expiry, in the US, Australia and a few other places. It didn't use to be this way, but around the 80s the big precedents for this. Most of the time, if you were a licensee before the expiry, then you continue to be so post-expiry. If however, you were not, then you have no existing contractual obligation, and can use it. However it is something you need to consult a lawyer on, before making…

Thanks. That makes sense, as a licensee signs a contract, so they will be governed by the terms of the contract, and the contract can presumably be written to outlast the patent. It suggests to me that when a patent expires then licensees are potentially disadvantaged compared to non-licensees. It highlights that one must make sure that licenses are written to terminate royalties on patent expiry, or think twice about licensing patents that are close to expiry.

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

#37

Post by debatem1 »

aseipp wrote: post #23
quigonjinn wrote: post #8

Kinda off-topic. SpinalHDL is the second HDL, that I come across, being implemented in Scala. It seems that every popular programming language has at least one HDL implemented in it these days. Any obvious reasons for this trend?

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.

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

#38

Post by shakna »

femto wrote: post #36
shakna wrote: post #34

Earlier quoted context omitted.

Licenses still apply post-expiry, in the US, Australia and a few other places. It didn't use to be this way, but around the 80s the big precedents for this. Most of the time, if you were a licensee before the expiry, then you continue to be so post-expiry. If however, you were not, then you have no existing contractual obligation, and can use it. However it is something you need to consult a lawyer on, before making…

Thanks. That makes sense, as a licensee signs a contract, so they will be governed by the terms of the contract, and the contract can presumably be written to outlast the patent. It suggests to me that when a patent expires then licensees are potentially disadvantaged compared to non-licensees. It highlights that one must make sure that licenses are written to terminate royalties on patent expiry, or think twice abou…

Just to add:

Usually royalties do go down after expiry in contracts.

Contracts also usually cover a lot more: Support, documentation and other guarantees.

This means there's a few businesses out there, that even after patent expiry still choose to renew their license.

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

#39

Post by Dolu »

femto wrote: post #29
Dolu wrote: post #26

Earlier quoted context omitted.

Are you sure it need a license ? I were thinking that AXI usage is royalities free ( https://en.wikipedia.org/wiki/Advanced_Microcontroller_Bus_A... )

If there is a licensing problem with AXI, would Wishbone be a viable alternative [1]? [1] https://en.wikipedia.org/wiki/Wishbone_(computer_bus)

Yes it would be, it is very easy to retarget the CPU to another memory bus.

Then the Wishbone one isn't "perfect" as it can't map memories which have latencies without performance penality. It would be oky for the data bus of the cpu with or without cache, but for the instruction, without instruction cache, peak CPI would be divided by the memory latency.

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

#40

Post by Dolu »

vanjoe wrote: post #32

How do you manage cached and uncached memory accesses? There has been some discussion lately on the mailing lists about this

Cached an uncached memory access are currently staticaly specified by range :

https://github.com/SpinalHDL/VexRiscv/blob/master/src/main/s...

From 0xF000000 to 0xFFFFFFFF access will be uncached.

Post reply on HN