[libre-riscv-dev] [Libre-silicon-devel] NLNet Funding Proposals for the Libre RISC-V SoC: call for participation
hsank at posteo.de
Tue Sep 24 09:54:56 BST 2019
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
"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
> <leviathan at libresilicon.com> 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
>> patented by a company.
>> Also I would strongly discourage you from using ARM patented
>> 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*
> 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
> 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
> Libresilicon-developers mailing list
> Libresilicon-developers at list.libresilicon.com
More information about the libre-riscv-dev