[please do remove all but libre-riscv-dev when replying, thx]
https://libre-riscv.org/nlnet_proposals/
A series of funding proposals, each for EUR 50,000, have been submitted to NLNet. These are for charitable donations and may be given to either individuals or to Universities (not to Corporations) for completion of an allotted milestone.
The basic idea is to think through and plan for commercial completion all of the tasks that will make the Libre RISC-V SoC a success. It's a lot! We have the following:
- a second Vulkan 3D driver, which will be a port of AMDVLK. similar to swiftshader, for the Libre RISCV SoC, except taking into account the Vectorisation, predication and custom accelerated opcodes. - a video acceleration initiative: with NEON assembler being up to the job of decoding 720p video on recent ARM64 processors, the idea is to design instructions that will do the job and then follow through getting the code upstream. - two related proposals which, in combination, will result in an actual 180nm ASIC being taped out at TSMC. - a formal mathematical proof of the hardware design, proving inviolate guarantees of its correctness. this because although auditing the code is possible, it is both laborious, error prone, and could be compromised. mathematical proofs may be run by anyone and are inviolate. - an augmentation of gcc to support the processor’s parallel and vectorisation capabilities.
Yes, really: 180nm ASICs only cost around EUR 600 per square millimetre, and with around 20 or so mm^2 it is completely within the realm of possibility for an NLNet Grant to fund a test ASIC. With each square millimetre being around 40,000 gates in 180nm, that's around 800,000 gates, which is enormous.
We would then have a proven ASIC, and moving up to 40nm or below, which would require around the USD 2m mark, is a far less risky proposition.
The irony is that whilst these funding proposals are quite easy to write, we also need to find people willing to do the work! In particular, we need at least one EU Citizen per project. They do not have to be permanently resident in the EU, they do however need an EU residence. Yes this includes the UK at the time of writing.
This is an extremely important strategic project that puts you - software libre developers - in the driving seat of modern technology instead of picking up the reverse engineering crumbs that fall from the Corporate table with at least a 2 year delay.
If you would like to help and actually receive donations (directly transferred) from NLNet for doing so, please do contact me directly or on libre-riscv-dev.
L.
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.
-lev
On Monday, 23 September 2019 2:56:31 PM HKT Luke Kenneth Casson Leighton wrote:
[please do remove all but libre-riscv-dev when replying, thx]
https://libre-riscv.org/nlnet_proposals/
A series of funding proposals, each for EUR 50,000, have been submitted to NLNet. These are for charitable donations and may be given to either individuals or to Universities (not to Corporations) for completion of an allotted milestone.
The basic idea is to think through and plan for commercial completion all of the tasks that will make the Libre RISC-V SoC a success. It's a lot! We have the following:
- a second Vulkan 3D driver, which will be a port of AMDVLK. similar to
swiftshader, for the Libre RISCV SoC, except taking into account the Vectorisation, predication and custom accelerated opcodes.
- a video acceleration initiative: with NEON assembler being up to the
job of decoding 720p video on recent ARM64 processors, the idea is to design instructions that will do the job and then follow through getting the code upstream.
- two related proposals which, in combination, will result in an actual
180nm ASIC being taped out at TSMC.
- a formal mathematical proof of the hardware design, proving inviolate
guarantees of its correctness. this because although auditing the code is possible, it is both laborious, error prone, and could be compromised. mathematical proofs may be run by anyone and are inviolate.
- an augmentation of gcc to support the processor’s parallel and
vectorisation capabilities.
Yes, really: 180nm ASICs only cost around EUR 600 per square millimetre, and with around 20 or so mm^2 it is completely within the realm of possibility for an NLNet Grant to fund a test ASIC. With each square millimetre being around 40,000 gates in 180nm, that's around 800,000 gates, which is enormous.
We would then have a proven ASIC, and moving up to 40nm or below, which would require around the USD 2m mark, is a far less risky proposition.
The irony is that whilst these funding proposals are quite easy to write, we also need to find people willing to do the work! In particular, we need at least one EU Citizen per project. They do not have to be permanently resident in the EU, they do however need an EU residence. Yes this includes the UK at the time of writing.
This is an extremely important strategic project that puts you - software libre developers - in the driving seat of modern technology instead of picking up the reverse engineering crumbs that fall from the Corporate table with at least a 2 year delay.
If you would like to help and actually receive donations (directly transferred) from NLNet for doing so, please do contact me directly or on libre-riscv-dev.
L.
On Mon, Sep 23, 2019 at 9:48 AM David Lanzendörfer leviathan@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 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.
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 leviathan@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 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 Libresilicon-developers@list.libresilicon.com https://list.libresilicon.com/mailman/listinfo/libresilicon-developers
On Tue, Sep 24, 2019 at 9:55 AM Hagen SANKOWSKI hsank@posteo.de wrote:
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..
great: this sounds like a perfect *additional* Research Project which someone [else] could put in a request for funding. once it is available, we can look at converting the code over to use it, and converting any peripherals to use it.
or, if someone [else] wants to include the Libre RISC-V SoC peripheral set as a possible suite of examples to convert (which would help justify a budget of EUR 50,000) they are welcome to do so.
the relevance of the streaming capability is that we need an I2S Audio Bus.
i can help with a write-up: unfortunately i am hitting an _additional_ limit of EUR 250,000 per person for overall projects submitted, so cannot be the one to submit it.
l.
Luke Kenneth Casson Leighton schreef op di 24-09-2019 om 12:16 [+0100]:
On Tue, Sep 24, 2019 at 9:55 AM Hagen SANKOWSKI hsank@posteo.de wrote:
The main difference between AMBI AXI and Wishbone is the streamingcapability. AXI can stream data, just with repetition stages, withouthandshake signals. So, it would be easier and more sustainable tobring-up Wishbone to the next level by standardize a similar streamingfeature. And yes, there are a lot of cores which using AMBA AXI whichhad to be partly re-written for Wishbone. But currently, there is noalternative, or as the German chancellor Merkel likes to say:"alternativlos". With added streaming feature to Wishbone, we would getan alternative full-featured SoC Bus and Designers could fix their badAMBA AXI bus interfaces..
great: this sounds like a perfect *additional* Research Project whichsomeone [else] could put in a request for funding. once it isavailable, we can look at converting the code over to use it, andconverting any peripherals to use it. or, if someone [else] wants to include the Libre RISC-V SoC peripheralset as a possible suite of examples to convert (which would helpjustify a budget of EUR 50,000) they are welcome to do so. the relevance of the streaming capability is that we need an I2S Audio Bus. i can help with a write-up: unfortunately i am hitting an _additional_limit of EUR 250,000 per person for overall projects submitted, socannot be the one to submit it.
Have yo guys looked at the pipeline feature of Wishbone B4 ? What is missing there to make streaming possible ?
greets, Staf.
On Tue, Sep 24, 2019 at 1:06 PM Staf Verhaegen staf@fibraservi.eu wrote:
Have yo guys looked at the pipeline feature of Wishbone B4 ? What is missing there to make streaming possible ?
hagen mentioned (offlist) that the broadcast mode of wishbone b4 could indeed be used. he'd like to do a write-up / proposal and i am happy to help him review it.
l.
hagen, i cookie-cut one of the other proposals, you'll see it here: https://libre-riscv.org/nlnet_2019_wishbone_streaming/
if you want to use that to start from i left some TODO sections, do keep it short, it really does not need much. they can always contact you and ask follow-up questions.
if you prefer to write one yourself do feel free as well. you will see the list of questions that are asked, copied to that template.
l.
https://libre-riscv.org/nlnet_2019_wishbone_streaming/
Hagen we do not have much time left before Oct 1st so I just very quickly filled in some paragraphs. It is more important to get something in that is brief and short, they will ask questions during the review process.
If you can let me know, if you are happy with the above, or feel free to edit it direct?
If anyone has any suggestions on anything else to add do say so [soon!]
L.
Luke Kenneth Casson Leighton schreef op di 24-09-2019 om 13:12 [+0100]:
On Tue, Sep 24, 2019 at 1:06 PM Staf Verhaegen staf@fibraservi.eu wrote:
Have yo guys looked at the pipeline feature of Wishbone B4 ? What is missing there to make streaming possible ?
hagen mentioned (offlist) that the broadcast mode of wishbone b4 couldindeed be used. he'd like to do a write-up / proposal and i am happyto help him review it. l.
OK, let me mention I have for my Retro-uC currently nmigen Wishbone code. I use it to make an arbiter between JTAG and the CPU cores on the design (Z80, MOS6502 and Motorola 68000) that can do a read/write for each cycle. Plan is top commit code to my gitlab repo after ORConf. Dan from ZipCPU would say that I still have to formally verify the code though... .
greets, Staf.
On Tuesday, September 24, 2019, Staf Verhaegen staf@fibraservi.eu wrote:
OK, let me mention I have for my Retro-uC currently nmigen Wishbone code.
Great!
I use it to make an arbiter between JTAG and the CPU cores on the design (Z80, MOS6502 and Motorola 68000) that can do a read/write for each cycle. Plan is top commit code to my gitlab repo after ORConf. Dan from ZipCPU would say that I still have to formally verify the code though... .
Yes. Ah it just occurred to me to get in touch with him again, see if he would like to help with the formal proofs proposal.
Looks like you might get your "wish" after all, David :)
L.
greets, Staf.
libresilicon-developers@list.libresilicon.com
-
David Lanzendörfer -
Hagen SANKOWSKI -
Luke Kenneth Casson Leighton -
Staf Verhaegen