Hello Luke.
Sometimes I totally agree with the RMS. The current patent system is
garbage, I am also a patentee.
But, well, we should avoid patents as often as possible. And yes, ARM
already proofs that they like to play the patent card regarding the AMBA
AXI bus. I am currently not sure, this (open - but not free) license is
banned for Huawei also.
The main difference between AMBI AXI and Wishbone is the streaming
capability. AXI can stream data, just with repetition stages, without
handshake signals. So, it would be easier and more sustainable to
bring-up Wishbone to the next level by standardize a similar streaming
feature. And yes, there are a lot of cores which using AMBA AXI which
had to be partly re-written for Wishbone. But currently, there is no
alternative, or as the German chancellor Merkel likes to say:
"alternativlos". With added streaming feature to Wishbone, we would get
an alternative full-featured SoC Bus and Designers could fix their bad
AMBA AXI bus interfaces..
BTW, I expect a better gate foot print for Wishbone than the
over-designed AMBA AXI or TileLink has.
IMHO your GPU/RISC-V stuff could benefit from a Wishbone streaming
feature best.
Regards,
Hagen.
---
"They who can give up essential liberty to obtain a little temporary
safety, deserve neither liberty nor safety." Benjamin Franklin (1775)
Am 24.09.2019 09:43 schrieb Luke Kenneth Casson Leighton:
On Mon, Sep 23, 2019 at 9:48 AM David Lanzendörfer
<[email protected]> wrote:
Hi Luke
In order to be truly libre, you've got to remove AXI from the RISC-V
implementation and replace it with TileLink or another bus, which
isn't
patented by a company.
Also I would strongly discourage you from using ARM patented
solutions,
this might most certainly come back in the future to hunt you.
appreciated, david: the main issue that we have is, with implementing
a GPU and VPU and CPU all in one, it's going to be unavoidable to run
into 3D patents, Video patents, you name it, we'll be hitting it.
from ICubeCorp alone - one company that i know of for certain created
a similar "Hybrid" CPU/GPU/VPU, we'll be hitting up to *seventeen*
patents:
https://patents.google.com/?q=ICubeCorp&oq=ICubeCorp
broadcom's videocore IV, which is based on the ARC core (bought by
synopsys), likewise has a whole stack of patents: ARC's primary
business was - is - licensing identical to ARM except embedded and not
as high-profile, with specialisation in Video SIMD instructions.
to even *try* to avoid these is just completely pointless: the entire
design would be so hamstrung as to be utterly commercially useless,
and, worse than that, we'd be taking on far more work and would
completely miss the goal as a result, missing out on additional
funding opportunities that would enable us to actually get to first
silicon.
in short: if we're adding AXI to the list of patents to avoid, because
we take on the additional responsibility of avoiding patents, we also
have to add the entire MASSIVE list of other patents in Video
Acceleration, 3D Acceleration, processor core design, and so on, and
it's just completely impractical.
some alternative strategies present themselves:
(1) if a customer (licensee) is presented with a patent demand, we can
look at prior art and arrange for the patent to be invalidated. we
have nothing to lose. enough of these being successful will cause
large patent holders to freak out and back the hell off.
(2) join a patent pool. like the linux foundation, except for
hardware. the newly-formed Open 3D Graphics Alliance is a good place
to start from, here.
(3) get to first silicon, get chips sold, get investment, *then* fund
a new ASIC design that avoids all known patents.
bottom line: we have to be realistic, and pick the best technology for
the job. TileLink, with its low level of adoption, Is Not It (and
using chisel3 is not an option for this processor). Wishbone, whilst
we may need some wb2axi bridges in order to avoid having to do major
rewrites, just doesn't cut it as far as complex multi-way routing is
concerned.
l.
_______________________________________________
Libresilicon-developers mailing list
[email protected]
https://list.libresilicon.com/mailman/listinfo/libresilicon-developers
_______________________________________________
libreplanet-discuss mailing list
[email protected]
https://lists.libreplanet.org/mailman/listinfo/libreplanet-discuss
