i'm delighted to be able to say that we've passed the review process to receive a grant for development of the Libre RISC-V SoC [1] under the 2019 NLnet "Enhanced Privacy and Trust" Programme [2].
the SoC is specifically to be designed in a fully transparent fashion at all times (HDL and software), so that there is absolutely no possibility of claims that it contains, for example, NSA spying backdoor co-processors [3] or other hidden means and methods by which user privacy is routinely violated by the technology that they legitimately purchase.
in addition to that the full software and hardware stack transparency (including in the VPU and GPU) not only aids learning and understanding in educational circles, the business case for full transparency is very clear: it's a simple matter of drastically reducing time spent on debugging hard to track down errors in extremely complex bug-ridden proprietary drivers [4]
examples abound of 3D or proprietary video decoders that have hard-coded assumptions that, due to the highly-integrated nature of SoCs, can eliminate a SoC entirely from consideration based not on the capabilities of the *hardware* but on the total lack of *software transparency*.
basically after ten years we got fed up of waiting around for the Industry Incumbents to design something that allows a fully transparent software stack... so, insanely, we have to make one [5]
we aim to bust through as many of the triple-layers of NDAs involved in ASIC development as we can get and still have a viable successful mass-volume embedded product, suitable for use in low-power products such as tablets, smartphones, mid-range netbooks and chromebooks, industrial devices and more.
in technical terms, that means a hybrid CPU / VPU / GPU and a SMP quad-core 800mhz dual/quad-issue out-of-order execution engine (based around the 58-year-old CDC 6600 design), with 1/2/4/8-wide SIMD ALUs hidden transparently behind a Vector Processing front-end, and custom instructions created where needed to give the software 3D and VPU drivers the performance and power-saving boost needed to meet the modest target of 3D and video 720p at 25fps, in an under *2.5* watt power budget for the entire SoC.
it is extremely ambitious for a libre-licensed project (OR1200 tops out at around 250mhz and is not SMP) and we have Mitch Alsup (the designer of the Motorola 68000) to thank for the discussions that made understanding OoO possible.
so that is some background.
the reason i am writing is to invite anyone who would like to help out - and receive some financial incentive (cash or shares [6]) for doing so - to get in touch and participate as we sort out the list of tasks to be done [7].
the grant is limited to $EUR 50,000 in this first round, and the final amount will depend on what milestones are agreed with the NLnet Foundation, hence why it is important to reach out *now* and invite people to help clarify the tasks, and make it clear which ones they would like to tackle. do bear in mind that the conditions required by the NLnet Foundation are payment on *completion* of agreed Milestones, so if they are particularly large tasks, subdivision will be crucial.
it's worth noting that the two main developers have circumstances that leads them to only require around USD $1000-1500 a month each, and that, after this first funding round is successfully completed it will be possible to apply for a much larger grant next year.
so we cannot go completely financially mad: the NLnet Foundation will just say "no" to anything such as a $25k proposal to develop a given peripheral, for example, however there is definitely room for e.g.:
* students who are doing a software or hardware engineering degree, always wanted to develop a processor and would like a way to supplement their income as an additional bonus, or * people already working full-time or part-time: one person is already donating their time at weekends to develop the TLB, Virtual Memory, and L1 and L2 Cache infrastructure for example (and doing a really good job of it, too).
and many others. so here's the conditions:
* the project is developed under the Libre-RISCV Charter, which you will need to agree to: http://libre-riscv.org/charter/discussion/ * full transparency means: no aspect of the SoC is to be developed by engaging in private or secret discussions. this constitutes "having something to hide" and would seriously undermine user trust (and would violate the terms of the NLnet grant). * in turn, that means that, as things stand, given that we are pushing the boundaries of innovation in RISC-V, if you have signed the RISC-V Membership Agreement there will be a conflict of interest that may prevent you from meeting the "full transparency" requirements, given that the RISC-V lists are *closed and secret*. * the code is being developed as a python "nmigen" application. you will need to be willing to learn nmigen as well as python. there are plenty of tutorials and a lot of code, now. * the coding standards are to meet pep8 (all of it, using autopep8, so it is not burdensome: just run a command), and for the code to be *readable and understandable*. examples are here [8] and here [9]. * good engineering development practices such as working out and writing specifications and agreeing them with the team, writing unit tests *at the time of developing the code*, and not engaging in "I Will Commit It When It's Finished" will be required. python is hairy enough as it is.
basically we are applying all the best aspects of team-based libre *software* development to *hardware*, and for anyone who wanted to know what that's like, but never encountered it before in a comprehensive multi-person *hardware* project before, now's your chance.
so if that sounds of interest, do get in touch, and join the mailing list [10].
also, if there is anyone who knows of "Social Enterprise" or "Benefit Corporation" style VC funding, or, recognising the benefits that a libre/open design approach brings to SoCs and to users, if you would like to sponsor the project, we'd love to hear from you too. yes we have a crowdsupply page in the pre-pre-launch phase [11].
l.
[1] https://libre-riscv.org/3d_gpu/ [2] NLnet.nl/PET/ [3] or, if there are, the full source of said NSA spying backdoor co-processor is made available, by the NSA, under a libre license, including associated private crypto keys, so that anyone can learn all about spying on *themselves*. this is what is termed "a humorous joke". [4] http://www.h-online.com/open/news/item/Intel-and-Valve-collaborate-to-develo... [5] https://www.crowdsupply.com/eoma68/micro-desktop/updates/picking-a-processor [6] https://slicingpie.com [7] http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-April/001019.htm... [8] https://git.libre-riscv.org/?p=ieee754fpu.git;a=blob;f=src/add/singlepipe.py... [9] https://git.libre-riscv.org/?p=soc.git;a=blob;f=TLB/src/TLB.py;h=3538bdc1dca... [10] http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev [11] https://www.crowdsupply.com/libre-risc-v/m-class
Congrats Luke-san,
Toyota has fund.
Best, S.Takano
2019年4月9日(火) 15:02 lkcl@lkcl.net:
i'm delighted to be able to say that we've passed the review process to receive a grant for development of the Libre RISC-V SoC [1] under the 2019 NLnet "Enhanced Privacy and Trust" Programme [2].
the SoC is specifically to be designed in a fully transparent fashion at all times (HDL and software), so that there is absolutely no possibility of claims that it contains, for example, NSA spying backdoor co-processors [3] or other hidden means and methods by which user privacy is routinely violated by the technology that they legitimately purchase.
in addition to that the full software and hardware stack transparency (including in the VPU and GPU) not only aids learning and understanding in educational circles, the business case for full transparency is very clear: it's a simple matter of drastically reducing time spent on debugging hard to track down errors in extremely complex bug-ridden proprietary drivers [4]
examples abound of 3D or proprietary video decoders that have hard-coded assumptions that, due to the highly-integrated nature of SoCs, can eliminate a SoC entirely from consideration based not on the capabilities of the *hardware* but on the total lack of *software transparency*.
basically after ten years we got fed up of waiting around for the Industry Incumbents to design something that allows a fully transparent software stack... so, insanely, we have to make one [5]
we aim to bust through as many of the triple-layers of NDAs involved in ASIC development as we can get and still have a viable successful mass-volume embedded product, suitable for use in low-power products such as tablets, smartphones, mid-range netbooks and chromebooks, industrial devices and more.
in technical terms, that means a hybrid CPU / VPU / GPU and a SMP quad-core 800mhz dual/quad-issue out-of-order execution engine (based around the 58-year-old CDC 6600 design), with 1/2/4/8-wide SIMD ALUs hidden transparently behind a Vector Processing front-end, and custom instructions created where needed to give the software 3D and VPU drivers the performance and power-saving boost needed to meet the modest target of 3D and video 720p at 25fps, in an under *2.5* watt power budget for the entire SoC.
it is extremely ambitious for a libre-licensed project (OR1200 tops out at around 250mhz and is not SMP) and we have Mitch Alsup (the designer of the Motorola 68000) to thank for the discussions that made understanding OoO possible.
so that is some background.
the reason i am writing is to invite anyone who would like to help out - and receive some financial incentive (cash or shares [6]) for doing so - to get in touch and participate as we sort out the list of tasks to be done [7].
the grant is limited to $EUR 50,000 in this first round, and the final amount will depend on what milestones are agreed with the NLnet Foundation, hence why it is important to reach out *now* and invite people to help clarify the tasks, and make it clear which ones they would like to tackle. do bear in mind that the conditions required by the NLnet Foundation are payment on *completion* of agreed Milestones, so if they are particularly large tasks, subdivision will be crucial.
it's worth noting that the two main developers have circumstances that leads them to only require around USD $1000-1500 a month each, and that, after this first funding round is successfully completed it will be possible to apply for a much larger grant next year.
so we cannot go completely financially mad: the NLnet Foundation will just say "no" to anything such as a $25k proposal to develop a given peripheral, for example, however there is definitely room for e.g.:
- students who are doing a software or hardware engineering degree, always
wanted to develop a processor and would like a way to supplement their income as an additional bonus, or
- people already working full-time or part-time: one person is already
donating their time at weekends to develop the TLB, Virtual Memory, and L1 and L2 Cache infrastructure for example (and doing a really good job of it, too).
and many others. so here's the conditions:
- the project is developed under the Libre-RISCV Charter, which you will
need to agree to: http://libre-riscv.org/charter/discussion/
- full transparency means: no aspect of the SoC is to be developed by
engaging in private or secret discussions. this constitutes "having something to hide" and would seriously undermine user trust (and would violate the terms of the NLnet grant).
- in turn, that means that, as things stand, given that we are pushing the
boundaries of innovation in RISC-V, if you have signed the RISC-V Membership Agreement there will be a conflict of interest that may prevent you from meeting the "full transparency" requirements, given that the RISC-V lists are *closed and secret*.
- the code is being developed as a python "nmigen" application. you will
need to be willing to learn nmigen as well as python. there are plenty of tutorials and a lot of code, now.
- the coding standards are to meet pep8 (all of it, using autopep8, so it
is not burdensome: just run a command), and for the code to be *readable and understandable*. examples are here [8] and here [9].
- good engineering development practices such as working out and writing
specifications and agreeing them with the team, writing unit tests *at the time of developing the code*, and not engaging in "I Will Commit It When It's Finished" will be required. python is hairy enough as it is.
basically we are applying all the best aspects of team-based libre *software* development to *hardware*, and for anyone who wanted to know what that's like, but never encountered it before in a comprehensive multi-person *hardware* project before, now's your chance.
so if that sounds of interest, do get in touch, and join the mailing list [10].
also, if there is anyone who knows of "Social Enterprise" or "Benefit Corporation" style VC funding, or, recognising the benefits that a libre/open design approach brings to SoCs and to users, if you would like to sponsor the project, we'd love to hear from you too. yes we have a crowdsupply page in the pre-pre-launch phase [11].
l.
[1] https://libre-riscv.org/3d_gpu/ [2] NLnet.nl/PET/ [3] or, if there are, the full source of said NSA spying backdoor co-processor is made available, by the NSA, under a libre license, including associated private crypto keys, so that anyone can learn all about spying on *themselves*. this is what is termed "a humorous joke". [4] http://www.h-online.com/open/news/item/Intel-and-Valve-collaborate-to-develo... [5] https://www.crowdsupply.com/eoma68/micro-desktop/updates/picking-a-processor [6] https://slicingpie.com [7] http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-April/001019.htm... [8] https://git.libre-riscv.org/?p=ieee754fpu.git;a=blob;f=src/add/singlepipe.py... [9] https://git.libre-riscv.org/?p=soc.git;a=blob;f=TLB/src/TLB.py;h=3538bdc1dca... [10] http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev [11] https://www.crowdsupply.com/libre-risc-v/m-class
-- You received this message because you are subscribed to the Google Groups "RISC-V HW Dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+unsubscribe@groups.riscv.org. To post to this group, send email to hw-dev@groups.riscv.org. Visit this group at https://groups.google.com/a/groups.riscv.org/group/hw-dev/. To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/79de14c4-253d-45... https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/79de14c4-253d-45a4-bb48-ff392f708d35%40groups.riscv.org?utm_medium=email&utm_source=footer .
Hello Luke,
Congratulations and success!
I do believe in open source hardware, it is crucial that your initiative succeeds!
BTW, we are a small group of nomad techies, coming from different EU countries, we all have links to our original country and the current country where we are staying, there are possibilities on a national level I think for financial incentives.
Best regards, Bert Life is too short, act now and enjoy!
Op di 9 apr. 2019 om 09:47 schreef 高野茂幸 adaptiveprocessor@gmail.com:
Congrats Luke-san,
Toyota has fund.
Best, S.Takano
2019年4月9日(火) 15:02 lkcl@lkcl.net:
i'm delighted to be able to say that we've passed the review process to receive a grant for development of the Libre RISC-V SoC [1] under the 2019 NLnet "Enhanced Privacy and Trust" Programme [2].
the SoC is specifically to be designed in a fully transparent fashion at all times (HDL and software), so that there is absolutely no possibility of claims that it contains, for example, NSA spying backdoor co-processors [3] or other hidden means and methods by which user privacy is routinely violated by the technology that they legitimately purchase.
in addition to that the full software and hardware stack transparency (including in the VPU and GPU) not only aids learning and understanding in educational circles, the business case for full transparency is very clear: it's a simple matter of drastically reducing time spent on debugging hard to track down errors in extremely complex bug-ridden proprietary drivers [4]
examples abound of 3D or proprietary video decoders that have hard-coded assumptions that, due to the highly-integrated nature of SoCs, can eliminate a SoC entirely from consideration based not on the capabilities of the *hardware* but on the total lack of *software transparency*.
basically after ten years we got fed up of waiting around for the Industry Incumbents to design something that allows a fully transparent software stack... so, insanely, we have to make one [5]
we aim to bust through as many of the triple-layers of NDAs involved in ASIC development as we can get and still have a viable successful mass-volume embedded product, suitable for use in low-power products such as tablets, smartphones, mid-range netbooks and chromebooks, industrial devices and more.
in technical terms, that means a hybrid CPU / VPU / GPU and a SMP quad-core 800mhz dual/quad-issue out-of-order execution engine (based around the 58-year-old CDC 6600 design), with 1/2/4/8-wide SIMD ALUs hidden transparently behind a Vector Processing front-end, and custom instructions created where needed to give the software 3D and VPU drivers the performance and power-saving boost needed to meet the modest target of 3D and video 720p at 25fps, in an under *2.5* watt power budget for the entire SoC.
it is extremely ambitious for a libre-licensed project (OR1200 tops out at around 250mhz and is not SMP) and we have Mitch Alsup (the designer of the Motorola 68000) to thank for the discussions that made understanding OoO possible.
so that is some background.
the reason i am writing is to invite anyone who would like to help out - and receive some financial incentive (cash or shares [6]) for doing so - to get in touch and participate as we sort out the list of tasks to be done [7].
the grant is limited to $EUR 50,000 in this first round, and the final amount will depend on what milestones are agreed with the NLnet Foundation, hence why it is important to reach out *now* and invite people to help clarify the tasks, and make it clear which ones they would like to tackle. do bear in mind that the conditions required by the NLnet Foundation are payment on *completion* of agreed Milestones, so if they are particularly large tasks, subdivision will be crucial.
it's worth noting that the two main developers have circumstances that leads them to only require around USD $1000-1500 a month each, and that, after this first funding round is successfully completed it will be possible to apply for a much larger grant next year.
so we cannot go completely financially mad: the NLnet Foundation will just say "no" to anything such as a $25k proposal to develop a given peripheral, for example, however there is definitely room for e.g.:
- students who are doing a software or hardware engineering degree,
always wanted to develop a processor and would like a way to supplement their income as an additional bonus, or
- people already working full-time or part-time: one person is already
donating their time at weekends to develop the TLB, Virtual Memory, and L1 and L2 Cache infrastructure for example (and doing a really good job of it, too).
and many others. so here's the conditions:
- the project is developed under the Libre-RISCV Charter, which you will
need to agree to: http://libre-riscv.org/charter/discussion/
- full transparency means: no aspect of the SoC is to be developed by
engaging in private or secret discussions. this constitutes "having something to hide" and would seriously undermine user trust (and would violate the terms of the NLnet grant).
- in turn, that means that, as things stand, given that we are pushing
the boundaries of innovation in RISC-V, if you have signed the RISC-V Membership Agreement there will be a conflict of interest that may prevent you from meeting the "full transparency" requirements, given that the RISC-V lists are *closed and secret*.
- the code is being developed as a python "nmigen" application. you will
need to be willing to learn nmigen as well as python. there are plenty of tutorials and a lot of code, now.
- the coding standards are to meet pep8 (all of it, using autopep8, so it
is not burdensome: just run a command), and for the code to be *readable and understandable*. examples are here [8] and here [9].
- good engineering development practices such as working out and writing
specifications and agreeing them with the team, writing unit tests *at the time of developing the code*, and not engaging in "I Will Commit It When It's Finished" will be required. python is hairy enough as it is.
basically we are applying all the best aspects of team-based libre *software* development to *hardware*, and for anyone who wanted to know what that's like, but never encountered it before in a comprehensive multi-person *hardware* project before, now's your chance.
so if that sounds of interest, do get in touch, and join the mailing list [10].
also, if there is anyone who knows of "Social Enterprise" or "Benefit Corporation" style VC funding, or, recognising the benefits that a libre/open design approach brings to SoCs and to users, if you would like to sponsor the project, we'd love to hear from you too. yes we have a crowdsupply page in the pre-pre-launch phase [11].
l.
[1] https://libre-riscv.org/3d_gpu/ [2] NLnet.nl/PET/ [3] or, if there are, the full source of said NSA spying backdoor co-processor is made available, by the NSA, under a libre license, including associated private crypto keys, so that anyone can learn all about spying on *themselves*. this is what is termed "a humorous joke". [4] http://www.h-online.com/open/news/item/Intel-and-Valve-collaborate-to-develo... [5] https://www.crowdsupply.com/eoma68/micro-desktop/updates/picking-a-processor [6] https://slicingpie.com [7] http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-April/001019.htm... [8] https://git.libre-riscv.org/?p=ieee754fpu.git;a=blob;f=src/add/singlepipe.py... [9] https://git.libre-riscv.org/?p=soc.git;a=blob;f=TLB/src/TLB.py;h=3538bdc1dca... [10] http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev [11] https://www.crowdsupply.com/libre-risc-v/m-class
-- You received this message because you are subscribed to the Google Groups "RISC-V HW Dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+unsubscribe@groups.riscv.org. To post to this group, send email to hw-dev@groups.riscv.org. Visit this group at https://groups.google.com/a/groups.riscv.org/group/hw-dev/. To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/79de14c4-253d-45... https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/79de14c4-253d-45a4-bb48-ff392f708d35%40groups.riscv.org?utm_medium=email&utm_source=footer .
-- You received this message because you are subscribed to the Google Groups "RISC-V HW Dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+unsubscribe@groups.riscv.org. To post to this group, send email to hw-dev@groups.riscv.org. Visit this group at https://groups.google.com/a/groups.riscv.org/group/hw-dev/. To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/CAOivKK%2Bm9ts%3... https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/CAOivKK%2Bm9ts%3DpomBJBEYao7BvSmhKKjhspXELj68PnZBa%2BOJ%3DQ%40mail.gmail.com?utm_medium=email&utm_source=footer .
On Tue, Apr 9, 2019 at 10:10 AM Bert delisvhdl@gmail.com wrote:
Hello Luke,
Congratulations and success!
thanks bert
I do believe in open source hardware, it is crucial that your initiative succeeds!
i think people are finally starting to wake up - Cambridge Analytica helped - to what people traditionally branded as "total religious fervent frothing zealous libre-manta-spouting loonies" have been going on about for decades.
however, just identifying the need to restore end-user trust isn't enough: it's actually necessary to *make* something, and make it according to a reasonably high-end enough spec so that it actually goes into products that people can buy.
BTW, we are a small group of nomad techies, coming from different EU countries, we all have links to our original country and the current country where we are staying, there are possibilities on a national level I think for financial incentives.
very interesting to hear. can we move this to e.g libre-riscv-dev@lists.libre-riscv.org ?
libresilicon-developers@list.libresilicon.com
-
Bert -
lkcl＠lkcl.net -
Luke Kenneth Casson Leighton
-
高野茂幸