1:53 a.m.
[question at end: feel free to skip to that. rest of message is background]
hi folks, i've been keeping track of lowrisc for some time, and like
the approach you're taking as the CIC framework provides for a really
good way to honour ethical commitments.
i noticed on the irc channel on oftc.net that the question was raised
about the faq entry that an SoC would be crowd-source-started within
2017. after taking a quick peek at the discussion on the list i get
the distinct impression that you're spending significant resources
fighting git merges, and it's sucking valuable time, unfortunately
narrowing the focus.
i first mentioned this yesterday on irc and, after my irc client
disconnected (and stayed down) i realised it would be better sent to
this list anyway.
as you probably know i've spent five to six years working with
literally dozens of different SoCs, so i have a really, *really* clear
understanding of how pinmuxes are done, and i also took a course (and
still remember it) at university on how to "target" a processor design
at a specific application. you're also no doubt aware (as i was from
my mentor with 30 years experience in VLSI and the mass-volume silicon
industry) that by the time you get to 800, 900, 1000+ pins, the damage
done by the gold bond-wiring process hammering the die and the PCB
that the die is on causes cracks (and failures of the IC), such that
the high pin-count ICs are SERIOUSLY disproportionately low-yield...
and thus incredibly, incredibly expensive. you would also most likely
wish to ensure that the lowRISC SoC is as financially successful
(covers several different markets) as possible.
it's therefore critical to get the pincount down as low as possible,
whilst at the same time being critically important to target as many
markets as possible with the same IC (not quite the same as "the same
die", because you can always make a die that has some pads internally
left unconnected to actual IC package pins).
the "minioncores" concept is an extremely good one for basically
turning general-purpose I/O into actual functions, with the
significant advantage over standard hard-coded macros that there is no
need to have the "mux" part of a "pinmux", greatly simplifying the IC
and routing. aside from the main technical disadvantage that
bit-banging without hardware-assist has a maximum speed threshold
related to the minioncore's maximum clock rate, the only thing to
still watch out for is that, as demonstrated and emphasised in the
links below (particularly peripheralschematics page) level-shifting
*really must* be included on-chip (even if it's a multi-chip module).
one freescale IC iMX made the severe mistake of having something
bizarre like a 2.6v GPIO VREF. absolutely every single deployment of
that SoC required absolutely every single GPIO to be routed via level
shifters. that's hundreds of pins and massive amounts of board space
consumed PLUS a hugely disproportionate increase in the BOM, for even
a basic application: bear in mind that for each GPIO you need an IC
with *double* the number of pins on the (external) level-shifter.
... by this point you may be getting the sinking feeling that the task
of actually developing the pinouts for a SoC is an extremely
specialist and comprehensive area requiring just as much expertise and
attention as the equally-important task that you're presently
primarily and actually focussed on: the development of the lowriscv
core. this is something that i can help you with.... so that you
don't have to spend the time, or heavily change focus.
below are the links to an analysis, based on the requirements of the
M-Class Shakti Core, which covers the industrial, mobile, smartphone
and netbook/laptop market *without requiring any mixed analog/digital
circuits of any kind* on the actual SoC itself.
http://rhombus-tech.net/riscv/shakti/m_class/
http://rhombus-tech.net/riscv/shakti/m_class/pinouts/
http://rhombus-tech.net/riscv/shakti/m_class/pinouts.py
http://rhombus-tech.net/riscv/shakti/m_class/peripheralschematics/
also to save a heck of a lot of effort (and from making SoC design
mistakes due to lack of analysis and planning), peripheral schematics
are also included, not just so that when it comes to making a
particular design a set of Reference ICs to use is readily available,
but also included is the pinouts of each IC, which in turn are
incorporated into the list of pin-mux coverage for the applications /
target markets, thus ensuring that the SoC *can* actually cover,
successfully, all the markets in question.
the coverage was done programmatically, with the stand-alone python
program "pinouts.py". a first "finger-in-the-air" set of pinouts was
added, followed by a first target market, then progressively more
targets added and the pinouts adjusted accordingly, by hand, to ensure
that 100% coverage was guaranteed.
the first attempt i made at this type of pinmux was 5 years ago. it
was done entirely by hand, by (stupidly as it turned out) trying to
fight KiCAD (and several absolutely critical bugs and severe design
flaws which the developers actively failed to comprehend, despite many
many people attempting to explain it to them) - consequently the task
took MONTHS.
learning from that experience, the development of this particular
pinmux was completed in *three days*, with later target market
reference designs taking under an hour to add.
question: would you be interested to make use of my expertise to
create the pinmux for the SoC that's part of the proposed
crowd-sourcing? and, if so, would you be prepared to ensure that
either in an ethical way i financially benefit directly from doing so,
or that there is sufficient overlap such that the [libre and ethical]
goals that i seek to "have completed" are met in some indirect way?
tia,
l.
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
3:27 a.m.
Dear Luke,
Thank you for your contribution to the discussion. I’m not sure whether damage sustained
during wire bond attachment is a limiting factor in ASIC yield, defects per square
millimetre is usually reckoned to be the dominant factor, but as you say, a large pinout
implies a large silicon area, and since area grows as the square of pin count for pad
limited devices this is indeed a serious limitation.
Turning to your main point, the ingenious use of multiplexing to boost the available uses
of the chip, I wasn’t able to identify where the mobile dynamic memory would be connected
(is this redundant in your hardware architecture?) and you must realise that any kind of
multiplexing of JTAG with other functions is a no-no if boundary scan is to work
properly.
Any discussion about possible uses needs to start with an analysis of market opportunities
and riscs (sic) and we had in mind some sort of embedded/IOT/teaching computer rather than
low-end laptop.
Your final point about payment is a tricky one. We have volunteers donating their time and
intellectual property under open source licenses all the time. Is it right that their
efforts should rank behind unsolicited contributions? We have in the past paid external
consultants for specific, shrink-wrapped pieces of work where we have identified a
specific gap in our internal resource. But we can’t accept contributions that are non-free
as it would undermine the efforts of other companies to incorporate our IP into their own
high-volume products.
Regarding the date of 2017 for the crowdfunding silicon I can confirm that date has
slipped again. But you may see lowRISC incorporated into other company’s products before
we have our own chip, depending on their particular requirements. Backend engineering is
an expensive, labour intensive and somewhat dull task, which is made easier by better
quality front-end design, which is our focus at the moment.
Regards,
Jonathan
Sent from my iPhone
On 27 Nov 2017, at 06:53, Luke Kenneth Casson Leighton
<lkcl(a)lkcl.net> wrote:
[question at end: feel free to skip to that. rest of message is background]
hi folks, i've been keeping track of lowrisc for some time, and like
the approach you're taking as the CIC framework provides for a really
good way to honour ethical commitments.
i noticed on the irc channel on oftc.net that the question was raised
about the faq entry that an SoC would be crowd-source-started within
2017. after taking a quick peek at the discussion on the list i get
the distinct impression that you're spending significant resources
fighting git merges, and it's sucking valuable time, unfortunately
narrowing the focus.
i first mentioned this yesterday on irc and, after my irc client
disconnected (and stayed down) i realised it would be better sent to
this list anyway.
as you probably know i've spent five to six years working with
literally dozens of different SoCs, so i have a really, *really* clear
understanding of how pinmuxes are done, and i also took a course (and
still remember it) at university on how to "target" a processor design
at a specific application. you're also no doubt aware (as i was from
my mentor with 30 years experience in VLSI and the mass-volume silicon
industry) that by the time you get to 800, 900, 1000+ pins, the damage
done by the gold bond-wiring process hammering the die and the PCB
that the die is on causes cracks (and failures of the IC), such that
the high pin-count ICs are SERIOUSLY disproportionately low-yield...
and thus incredibly, incredibly expensive. you would also most likely
wish to ensure that the lowRISC SoC is as financially successful
(covers several different markets) as possible.
it's therefore critical to get the pincount down as low as possible,
whilst at the same time being critically important to target as many
markets as possible with the same IC (not quite the same as "the same
die", because you can always make a die that has some pads internally
left unconnected to actual IC package pins).
the "minioncores" concept is an extremely good one for basically
turning general-purpose I/O into actual functions, with the
significant advantage over standard hard-coded macros that there is no
need to have the "mux" part of a "pinmux", greatly simplifying the
IC
and routing. aside from the main technical disadvantage that
bit-banging without hardware-assist has a maximum speed threshold
related to the minioncore's maximum clock rate, the only thing to
still watch out for is that, as demonstrated and emphasised in the
links below (particularly peripheralschematics page) level-shifting
*really must* be included on-chip (even if it's a multi-chip module).
one freescale IC iMX made the severe mistake of having something
bizarre like a 2.6v GPIO VREF. absolutely every single deployment of
that SoC required absolutely every single GPIO to be routed via level
shifters. that's hundreds of pins and massive amounts of board space
consumed PLUS a hugely disproportionate increase in the BOM, for even
a basic application: bear in mind that for each GPIO you need an IC
with *double* the number of pins on the (external) level-shifter.
... by this point you may be getting the sinking feeling that the task
of actually developing the pinouts for a SoC is an extremely
specialist and comprehensive area requiring just as much expertise and
attention as the equally-important task that you're presently
primarily and actually focussed on: the development of the lowriscv
core. this is something that i can help you with.... so that you
don't have to spend the time, or heavily change focus.
below are the links to an analysis, based on the requirements of the
M-Class Shakti Core, which covers the industrial, mobile, smartphone
and netbook/laptop market *without requiring any mixed analog/digital
circuits of any kind* on the actual SoC itself.
http://rhombus-tech.net/riscv/shakti/m_class/
http://rhombus-tech.net/riscv/shakti/m_class/pinouts/
http://rhombus-tech.net/riscv/shakti/m_class/pinouts.py
http://rhombus-tech.net/riscv/shakti/m_class/peripheralschematics/
also to save a heck of a lot of effort (and from making SoC design
mistakes due to lack of analysis and planning), peripheral schematics
are also included, not just so that when it comes to making a
particular design a set of Reference ICs to use is readily available,
but also included is the pinouts of each IC, which in turn are
incorporated into the list of pin-mux coverage for the applications /
target markets, thus ensuring that the SoC *can* actually cover,
successfully, all the markets in question.
the coverage was done programmatically, with the stand-alone python
program "pinouts.py". a first "finger-in-the-air" set of pinouts
was
added, followed by a first target market, then progressively more
targets added and the pinouts adjusted accordingly, by hand, to ensure
that 100% coverage was guaranteed.
the first attempt i made at this type of pinmux was 5 years ago. it
was done entirely by hand, by (stupidly as it turned out) trying to
fight KiCAD (and several absolutely critical bugs and severe design
flaws which the developers actively failed to comprehend, despite many
many people attempting to explain it to them) - consequently the task
took MONTHS.
learning from that experience, the development of this particular
pinmux was completed in *three days*, with later target market
reference designs taking under an hour to add.
question: would you be interested to make use of my expertise to
create the pinmux for the SoC that's part of the proposed
crowd-sourcing? and, if so, would you be prepared to ensure that
either in an ethical way i financially benefit directly from doing so,
or that there is sufficient overlap such that the [libre and ethical]
goals that i seek to "have completed" are met in some indirect way?
tia,
l.
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
5:52 a.m.
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Mon, Nov 27, 2017 at 8:27 AM, Dr Jonathan Kimmitt <jrrk2(a)cam.ac.uk> wrote:
Dear Luke,
Thank you for your contribution to the discussion.
thank you for replying so quickly. key question moved to the bottom
(for ease of context-cutting), rest is clarification / info, no actual
response needed.
I’m not sure whether damage sustained during wire bond
attachment is a limiting factor in ASIC yield,
at the very large sizes (1000+), yes it is. or, has been, some point
up until around 10 years ago unless there has been a technical
solution found since (my mentor's experience / knowledge ends/ended
around that time).
defects per square millimetre is usually reckoned to be the dominant
factor, but as you say, a large pinout implies a large silicon area, and since area grows
as the square of pin count for pad limited devices this is indeed a serious limitation.
indeed that is the most well-known case: large die == automatically
more expensive. micro-fractures caused by hitting the die hard enough
to melt and fuse the gold bond-wires is not so well-known (most
companies would not even remotely consider creating a 1000+ pin...
Monster... as their very first SoC). it is however indeed a
combination of both factors.
i was extremely lucky to have been trained over a 10 year period by
someone who really, really knew what they were talking about, and who
had first-hand experience of the development and mass-production of
ICs.
many people are not aware for example that 95% yields are not
achieved through one single "thing" jumping the yields from the
initial low figures in one fell swoop, but by applying fifty to a
hundred *separate* improvements, each of a half to one percent, over a
long, long time, fine-tuning a DEDICATED fab line over many many
months of mass-production to producee ONE specific set of masks for
ONE specific customer. any interruption in that process means
throwing everything away, as even changing over to a new set of masks
means disturbing the setup and wasting the time spent on the
optimisations.
it's tricky stuff! :)
Turning to your main point, the ingenious use of multiplexing to
boost
the available uses of the chip,
it's pretty much standard practice, right across the board, both in
the embedded / MCU world (ST, Atmel) and in the 32/64-bit SoC world:
TI, Freescale/NXP, Rockchip, Allwinner, Samsung, Nexell - any SoC
which *doesn't* reduce pincount (and cost) by multiplexing is...
well... it's going to be cost-competitively on the heavily negative
side.
I wasn’t able to identify where the mobile dynamic memory would
be connected (is this redundant in your hardware architecture?)
you mean DDR3 / DDR3L / LPDDR3? that's in
http://rhombus-tech.net/riscv/shakti/m_class/pinouts/ "Fixed Pinouts",
2nd section. it's by far the largest part of the "non" multiplexable
set of pins, some 80 or so just on its own excluding VCC/GND (an extra
20).
and you must realise that any kind of multiplexing of JTAG with other
functions is a no-no if boundary scan is to work properly.
ah. Allwinner, Rockchip, and many others have achieved it, so it's
definitely technically doable. note the inclusion of "JTAG_SEL" on
the pinouts, which will "pre-set" the pin-mux at boot time with one
preset value to directly expose the JTAG function onto one set of
pins, or another preset value to put them onto alternative pins,
depending on whether JTAG_SEL is hard-wired to GND or VCC (or left
floating / on a jumper header on the PCB, whatevery you like).
so it *appears* that JTAG is not actually multiplexed as far as the
actual internal hardware is concerned. it just means you have to be
careful about the boot process.
as mentioned in the publication i wrote: the advantages are
significant. as both Allwinner and Rockchip (at the very least) have
done: by multipllexing JTAG (4 pins) onto SD/MMC (6 pins) plus a UART
(2 pins), then making sure that that external SD/MMC (6 pins) is an
*EXTERNAL* socket on the PCB, you no longer need to crack open a
production product, breaking or smashing its hermetically-sealed case
for example, in order to debug it, reverse-engineer it or replace its
proprietary firmware (which _will_ happen at some point... *sigh*....)
it's so prevalent a technique that there are even
microsd-to-JTAG-plus-UART break-out boards available on aliexpress, of
all places :)
strictly speaking a JTAG_SEL pin is not actually necessary: the
practice of selecting *either* pin-mux (default) onto SD/MMC alongside
UART *or* pinmux (default if JTAG_SEL=LOW) onto SPI (4-to-4-pin) is
one that is utilised in nearly every Allwinner SoC, but it would be
perfectly fine to drop the JTAG_SEL pin and mux with SD/MMC alongside
UART.
howeverrrr.... if you *don't* do that, and you have to use that
specific SD/MMC for connection to an *internal* peripheral, you're now
stuffed :) you don't have any JTAG capability at all.
sooo... insteaaad.... you'd need to select JTAG_SEL=low, there, and
dedicate the mux'ed pins with the SPI interface.... SPI2 i believe in
this case... and that's why SPI2 has *multiple* exit points, so that
you can, if you need SPI2, put SPI2 out...
... you get the idea, i'm sure: it's actually extremely complex, and
it's really *really* necessary to think about this in advance, planned
completely and comprehensively from the "target markets".
Any discussion about possible uses needs to start
with an analysis of market opportunities
aaabsolutely. absolutely, absolutely, absolutely. so that's exactly
and precisely where i started from, in the (very rapid) discussions
with the head of the shakti project, about 10 days ago.
and riscs (sic) and we had in mind some sort of
embedded/IOT/teaching
computer rather than low-end laptop.
it turns out that, as you can probably see from the example pinmux, a
laptop / netbook (which need not actually be considered or called
"low-end" at all - the Acer Chromebook C201 _vastly_ outperforms Intel
Atom "laptops" 50 to 100% over its price bracket, and it uses a quotes
low-end quotes RK3288 processor), is actually a subset of the much
more complex embedded/IOT markets.
in essence: if the embedded/IOT/teaching planned pinouts *happens* to have:
* RGB/TTL video (opencores vga/lcd controller being the simplest /
quickest way to achieve that: btw i have access to *FULL*
GPL-compliant linux kernel driver source code to match it - you won't
find anyone else in the world who can make that available to you
without some sort of financial / time cost),
* SD/MMC
* I2C
* SPI
* UART
* GPIO
* USB
then... errr... that happens to be the *exact* set functions needed to
create a laptop! :)
interestingly, absolutely every single one of those functions is
available free of charge, BSD or LGPLv2-licensed, on opencores.org
(references in the online document i've published).
so.
key question is at the end.
"embedded" is a very general term, it can cover industrial purposes
(for which CAN bus - patented - and lots of full UARTs, ADC, DAC, PWM
and on-board timers are generally needed) or other markets (you only
have to look at the proliferation of parts from e.g. ST to appreciate
quite how large the embedded market is)
"IoT"... a silly, silly name, but hey, what can you do? :) basically
it means nothing more than "embedded".... :)
"Teaching".... again, quite general: what's the goal, there?
targetting the arduino-level or the beaglebone/1ghz+ embedded
processor level on credit-card-sized form-factor level? [i don't like
the hypocrisy of the rbpi foundation trying to "teach" children that
it's ok to explore and educate themselves so far... but if they want
to explore the ARC-based GPU/VPU they CAN'T... because of DRM,
RIAA/MPAA-sponsored cartelling, *plus* patent licensing issues on
video CODECs, so prefer *not* to refer to the raspberry pi in any way.
bit of a sore point there, you can probably tell...]
anyway: question moved to the bottom.
Your final point about payment is a tricky one.
"in kind" is perfectly fine, i forgot to specifically emphasise the
"third person nature" of the goals that i seek. whomever or however
achieves the libre and ethical goals i seek to [third person] see
achieved, is completely irrelevant for me.
i've discussed this before with some of the team members (off-list, a
year ago): one of the "concrete", non-financial and indirect ways that
i would not only be happy with but would instead be completely
delighted with would be to ensure that that planned SoC covers - in
full - the EOMA68 hardware specification.
EOMA68 is actually very basic. expressed simply (details and niggles
are on the spec page on elinux.org): 18-pin RGB/TTL, 1x I2C, 2x USB
(via 1x plus a 2-port USB Hub is perfectly fine), 1x UART, 1x PWM, 1x
SPI, 1x SD/MMC, 4x EINT-capable GPIO, plus the capacity to pin-mux the
EINT, I2C, UART, PWM, SPI and SD/MMC over to plain (non-EINT-capable)
GPIO.... errr... that's basically it. it's hardly burdensome, and if
you look at each of the interfaces, i think you'd agree that any
embedded/IOT/teaching SoC that did *not* have those exact same
interfaces as part of a subset of its overall functionality would....
ultimately... not be very well received.
last time i spoke (privately) to the team, i believe that the only
function that they explained they were missing was SD/MMC, and since
then a full SD/MMC interface (non-SPI-compatible) with linux kernel
source driver code has turned up on opencores.org
But we can’t accept contributions that are non-free
well that's good, because as a software libre developer and advocate
i wouldn't *want* to contribute in a proprietary fashion. no, that's
nowhere near strong enough: *if* i got *one whiff* of any evidence
that the lowRISC team was *remotely* considering turning the project
proprietary, i would IMMEDIATELY terminate all and any involvement,
endorsement and assistance. and would be quite... annoyed. the sole
exclusive reason why i am currently utilising proprietary SoCs is:
there aren't any good libre ones.
in the search for ways to help you, i've already weeded out several
sources of hard macros that are proprietary, and have spent
significant time tracking down one last major piece: a
libre-compatible / libre-licensed DDR3 controller. the PHY
unfortunately is still yet to be done, and i have been made aware that
the Shakti Team has, as one of its goals, to do precisely that:
implement a completely BSD-licensed DDR3 controller and PHY. that's
*in addition* to the other group having already implemented a
license-compatible DDR3 Controller.
Regarding the date of 2017 for the crowdfunding silicon I
can confirm that date has slipped again.
it happens :) i'm keenly aware that technical projects require some
form of 100% implemented proof-of-concept before they can be accepted,
and if the proposed interfaces have not been clearly defined and 100%
selected *and proven* (if nothing else in an FPGA), there's *no way*
that it would even be *sensible* to approach a crowd-funding company,
let alone consider starting a campaign.
btw if you're not already in touch with him i am more than happy to
introduce you to joshua, of crowdsupply. they have a much better
technical grasp than the "yeah we don't give a damn unless you're one
of our special mates" kickstarter, they actually *support* and
*empower* you because the team actually care, and they also convert
the crowd-funding page to a "preordering shop" afterwards and much,
much more. since the EOMA68 campaign (and after the fuss with purism,
which i helped them to clear up, particularly with the FSF who were
*really* pissed due to some key misunderstandings), Crowdsupply's
experience and support for Libre Projects has become second to none in
the entire crowd-funding world.
But you may see lowRISC incorporated into other company’s products
before we have our own chip, depending on their particular requirements.
i'd be interested to hear, if you have any recommendations (private
off-list or otherwise) of companies that would be keen to benefit from
the increased exposure and market share that could be achieved
through, for example, joint crowd-funding campaigns involving the
simultaneous creation of an EOMA68 Computer Card utilising their
planned SoC.
Backend engineering is an expensive, labour intensive and somewhat
dull task,
which is made easier by better quality front-end design, which is our focus at the
moment.
ha :) perfectly understood.
so, here's the key question, all the above is background / clarification.
would you and the team be happy to go into details about what the
proposed target markets are? some scenarios would help lock it down
pretty quickly. what kinds of peripherals and sensors are expected to
be connected in classrooms / universities. which segment of the
embedded market is to be targetted. what are the usage scenarios for
the IoT market.
from there, it's a pretty straightforward task to identify exactly
which interfaces (and how many) are required. from *there* it's a
simple matter of iterating around an adaptation of pinouts.py to
create a suitable pinmux, if indeed one is actually needed at all,
depending on the speed / bus-widths that the I/O minioncores could
cope with. the reason i mention that specifically is: if a 200mhz
48/64-bit-wide SRAM bus is required for one of the target markets, for
example, a minioncore may not *actually* be capable of handling either
that wide a bus (without special extension to its instructions), or
have the kind of instruction-set bandwidth to cope with bit-banging a
200mhz bus clock rate, particularly if it's in 45nm and is only
running at say only 500mhz.
this kind of analysis is what i'm good at. some people would
consider it... labour-intensive or simply... far, far too many
variables to cope with: i quite like it :)
in this case however, given the very specific focus that the team
currently has, it would be almost a dis-service to pull them off of
that, i've read the articles about the effect that context-switching
has on human neural structures / brain chemistry. the results are: a
dramatic drop in productivity.
l.
7:06 a.m.
Dear Luke,
this seems like a lively discussion, I overlooked in your info that
fixed and multiplexed
pins are in separate tables. Regarding the JTAG,my point was that
JTAG_SEL would not
be a testable boundary scan pin, if it controlled access to the JTAG TAP
itself, but this might
be an acceptable testability loss. It sounds like you have many of the
same objectives as ourselves,
and what would be a useful contribution would be to take a copy of our
database and patch it using
open source IPs, such as the open source DDR that you mentioned, to
demonstrate a viable
integrated solution which does not require Xilinx IPs. At the moment we
are not accepting new GPL and LGPL
blocks because of the uncertain legality of linking these blocks with
proprietary ASIC libraries. Any such blocks
that we have will eventually have to be redesigned or replaced.
This would rule out some of the Opencores designs, and even those which
are eligible would require adaptation to use
NASTI(axi compatible) bus instead of Wishbone bus.
We also do not assume that a Minion I/O processor would have a
conventional Von Neumann architecture, or that
it would have to be a Turing machine. Any kind of state machine that did
the job might be the best solution.
I find it gratifying that you emphasize the importance of providing
viable Linux drivers to go with the various hardware
blocks. These kind of details can use up quite a bit of time in getting
a solution going.
We have also found that many HDL projects are a work in progress, and it
is one thing to point to a solution, and another
to understand it and/or update to the point of being able to use it in
an integrated SOC project.
If our first product turns out to be a semi-custom or sea-of-gates
implementation, there will be a performance penalty
to pay for the lower up-front costs, and consequently high-end
applications such as laptops would be ruled out.
When I mentioned IoT, I was particularly thinking of Wireless consumer
devices (Zigbee/BluetoothLE/Wifi interfaces)
which as you say are a subset of embedded solutions with particular
requirements, such as long battery life.
For the avoidance of doubt, my suggestions to you are my own view and
not the considered view of the while LowRISC team.
I can confirm that at no point will LowRISC become proprietary, we are
so open that everything we have is stored
openly and externally on GitHub, including all our mistakes and
also-rans. Not many companies can say that.
Regards,
Jonathan
On 27/11/17 10:52, Luke Kenneth Casson Leighton wrote:
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Mon, Nov 27, 2017 at 8:27 AM, Dr Jonathan Kimmitt <jrrk2(a)cam.ac.uk> wrote:
> Dear Luke,
> Thank you for your contribution to the discussion.
thank you for replying so quickly. key question moved to the bottom
(for ease of context-cutting), rest is clarification / info, no actual
response needed.
> I’m not sure whether damage sustained during wire bond
> attachment is a limiting factor in ASIC yield,
at the very large sizes (1000+), yes it is. or, has been, some point
up until around 10 years ago unless there has been a technical
solution found since (my mentor's experience / knowledge ends/ended
around that time).
> defects per square millimetre is usually reckoned to be the dominant factor, but as
you say, a large pinout implies a large silicon area, and since area grows as the square
of pin count for pad limited devices this is indeed a serious limitation.
indeed that is the most well-known case: large die == automatically
more expensive. micro-fractures caused by hitting the die hard enough
to melt and fuse the gold bond-wires is not so well-known (most
companies would not even remotely consider creating a 1000+ pin...
Monster... as their very first SoC). it is however indeed a
combination of both factors.
i was extremely lucky to have been trained over a 10 year period by
someone who really, really knew what they were talking about, and who
had first-hand experience of the development and mass-production of
ICs.
many people are not aware for example that 95% yields are not
achieved through one single "thing" jumping the yields from the
initial low figures in one fell swoop, but by applying fifty to a
hundred *separate* improvements, each of a half to one percent, over a
long, long time, fine-tuning a DEDICATED fab line over many many
months of mass-production to producee ONE specific set of masks for
ONE specific customer. any interruption in that process means
throwing everything away, as even changing over to a new set of masks
means disturbing the setup and wasting the time spent on the
optimisations.
it's tricky stuff! :)
> Turning to your main point, the ingenious use of multiplexing to boost
> the available uses of the chip,
it's pretty much standard practice, right across the board, both in
the embedded / MCU world (ST, Atmel) and in the 32/64-bit SoC world:
TI, Freescale/NXP, Rockchip, Allwinner, Samsung, Nexell - any SoC
which *doesn't* reduce pincount (and cost) by multiplexing is...
well... it's going to be cost-competitively on the heavily negative
side.
> I wasn’t able to identify where the mobile dynamic memory would
> be connected (is this redundant in your hardware architecture?)
you mean DDR3 / DDR3L / LPDDR3? that's in
http://rhombus-tech.net/riscv/shakti/m_class/pinouts/ "Fixed Pinouts",
2nd section. it's by far the largest part of the "non" multiplexable
set of pins, some 80 or so just on its own excluding VCC/GND (an extra
20).
> and you must realise that any kind of multiplexing of JTAG with other functions is a
no-no if boundary scan is to work properly.
ah. Allwinner, Rockchip, and many others have achieved it, so it's
definitely technically doable. note the inclusion of "JTAG_SEL" on
the pinouts, which will "pre-set" the pin-mux at boot time with one
preset value to directly expose the JTAG function onto one set of
pins, or another preset value to put them onto alternative pins,
depending on whether JTAG_SEL is hard-wired to GND or VCC (or left
floating / on a jumper header on the PCB, whatevery you like).
so it *appears* that JTAG is not actually multiplexed as far as the
actual internal hardware is concerned. it just means you have to be
careful about the boot process.
as mentioned in the publication i wrote: the advantages are
significant. as both Allwinner and Rockchip (at the very least) have
done: by multipllexing JTAG (4 pins) onto SD/MMC (6 pins) plus a UART
(2 pins), then making sure that that external SD/MMC (6 pins) is an
*EXTERNAL* socket on the PCB, you no longer need to crack open a
production product, breaking or smashing its hermetically-sealed case
for example, in order to debug it, reverse-engineer it or replace its
proprietary firmware (which _will_ happen at some point... *sigh*....)
it's so prevalent a technique that there are even
microsd-to-JTAG-plus-UART break-out boards available on aliexpress, of
all places :)
strictly speaking a JTAG_SEL pin is not actually necessary: the
practice of selecting *either* pin-mux (default) onto SD/MMC alongside
UART *or* pinmux (default if JTAG_SEL=LOW) onto SPI (4-to-4-pin) is
one that is utilised in nearly every Allwinner SoC, but it would be
perfectly fine to drop the JTAG_SEL pin and mux with SD/MMC alongside
UART.
howeverrrr.... if you *don't* do that, and you have to use that
specific SD/MMC for connection to an *internal* peripheral, you're now
stuffed :) you don't have any JTAG capability at all.
sooo... insteaaad.... you'd need to select JTAG_SEL=low, there, and
dedicate the mux'ed pins with the SPI interface.... SPI2 i believe in
this case... and that's why SPI2 has *multiple* exit points, so that
you can, if you need SPI2, put SPI2 out...
... you get the idea, i'm sure: it's actually extremely complex, and
it's really *really* necessary to think about this in advance, planned
completely and comprehensively from the "target markets".
> Any discussion about possible uses needs to start
> with an analysis of market opportunities
aaabsolutely. absolutely, absolutely, absolutely. so that's exactly
and precisely where i started from, in the (very rapid) discussions
with the head of the shakti project, about 10 days ago.
> and riscs (sic) and we had in mind some sort of embedded/IOT/teaching
> computer rather than low-end laptop.
it turns out that, as you can probably see from the example pinmux, a
laptop / netbook (which need not actually be considered or called
"low-end" at all - the Acer Chromebook C201 _vastly_ outperforms Intel
Atom "laptops" 50 to 100% over its price bracket, and it uses a quotes
low-end quotes RK3288 processor), is actually a subset of the much
more complex embedded/IOT markets.
in essence: if the embedded/IOT/teaching planned pinouts *happens* to have:
* RGB/TTL video (opencores vga/lcd controller being the simplest /
quickest way to achieve that: btw i have access to *FULL*
GPL-compliant linux kernel driver source code to match it - you won't
find anyone else in the world who can make that available to you
without some sort of financial / time cost),
* SD/MMC
* I2C
* SPI
* UART
* GPIO
* USB
then... errr... that happens to be the *exact* set functions needed to
create a laptop! :)
interestingly, absolutely every single one of those functions is
available free of charge, BSD or LGPLv2-licensed, on opencores.org
(references in the online document i've published).
so.
key question is at the end.
"embedded" is a very general term, it can cover industrial purposes
(for which CAN bus - patented - and lots of full UARTs, ADC, DAC, PWM
and on-board timers are generally needed) or other markets (you only
have to look at the proliferation of parts from e.g. ST to appreciate
quite how large the embedded market is)
"IoT"... a silly, silly name, but hey, what can you do? :) basically
it means nothing more than "embedded".... :)
"Teaching".... again, quite general: what's the goal, there?
targetting the arduino-level or the beaglebone/1ghz+ embedded
processor level on credit-card-sized form-factor level? [i don't like
the hypocrisy of the rbpi foundation trying to "teach" children that
it's ok to explore and educate themselves so far... but if they want
to explore the ARC-based GPU/VPU they CAN'T... because of DRM,
RIAA/MPAA-sponsored cartelling, *plus* patent licensing issues on
video CODECs, so prefer *not* to refer to the raspberry pi in any way.
bit of a sore point there, you can probably tell...]
anyway: question moved to the bottom.
> Your final point about payment is a tricky one.
"in kind" is perfectly fine, i forgot to specifically emphasise the
"third person nature" of the goals that i seek. whomever or however
achieves the libre and ethical goals i seek to [third person] see
achieved, is completely irrelevant for me.
i've discussed this before with some of the team members (off-list, a
year ago): one of the "concrete", non-financial and indirect ways that
i would not only be happy with but would instead be completely
delighted with would be to ensure that that planned SoC covers - in
full - the EOMA68 hardware specification.
EOMA68 is actually very basic. expressed simply (details and niggles
are on the spec page on elinux.org): 18-pin RGB/TTL, 1x I2C, 2x USB
(via 1x plus a 2-port USB Hub is perfectly fine), 1x UART, 1x PWM, 1x
SPI, 1x SD/MMC, 4x EINT-capable GPIO, plus the capacity to pin-mux the
EINT, I2C, UART, PWM, SPI and SD/MMC over to plain (non-EINT-capable)
GPIO.... errr... that's basically it. it's hardly burdensome, and if
you look at each of the interfaces, i think you'd agree that any
embedded/IOT/teaching SoC that did *not* have those exact same
interfaces as part of a subset of its overall functionality would....
ultimately... not be very well received.
last time i spoke (privately) to the team, i believe that the only
function that they explained they were missing was SD/MMC, and since
then a full SD/MMC interface (non-SPI-compatible) with linux kernel
source driver code has turned up on opencores.org
> But we can’t accept contributions that are non-free
well that's good, because as a software libre developer and advocate
i wouldn't *want* to contribute in a proprietary fashion. no, that's
nowhere near strong enough: *if* i got *one whiff* of any evidence
that the lowRISC team was *remotely* considering turning the project
proprietary, i would IMMEDIATELY terminate all and any involvement,
endorsement and assistance. and would be quite... annoyed. the sole
exclusive reason why i am currently utilising proprietary SoCs is:
there aren't any good libre ones.
in the search for ways to help you, i've already weeded out several
sources of hard macros that are proprietary, and have spent
significant time tracking down one last major piece: a
libre-compatible / libre-licensed DDR3 controller. the PHY
unfortunately is still yet to be done, and i have been made aware that
the Shakti Team has, as one of its goals, to do precisely that:
implement a completely BSD-licensed DDR3 controller and PHY. that's
*in addition* to the other group having already implemented a
license-compatible DDR3 Controller.
> Regarding the date of 2017 for the crowdfunding silicon I
> can confirm that date has slipped again.
it happens :) i'm keenly aware that technical projects require some
form of 100% implemented proof-of-concept before they can be accepted,
and if the proposed interfaces have not been clearly defined and 100%
selected *and proven* (if nothing else in an FPGA), there's *no way*
that it would even be *sensible* to approach a crowd-funding company,
let alone consider starting a campaign.
btw if you're not already in touch with him i am more than happy to
introduce you to joshua, of crowdsupply. they have a much better
technical grasp than the "yeah we don't give a damn unless you're one
of our special mates" kickstarter, they actually *support* and
*empower* you because the team actually care, and they also convert
the crowd-funding page to a "preordering shop" afterwards and much,
much more. since the EOMA68 campaign (and after the fuss with purism,
which i helped them to clear up, particularly with the FSF who were
*really* pissed due to some key misunderstandings), Crowdsupply's
experience and support for Libre Projects has become second to none in
the entire crowd-funding world.
> But you may see lowRISC incorporated into other company’s products
> before we have our own chip, depending on their particular requirements.
i'd be interested to hear, if you have any recommendations (private
off-list or otherwise) of companies that would be keen to benefit from
the increased exposure and market share that could be achieved
through, for example, joint crowd-funding campaigns involving the
simultaneous creation of an EOMA68 Computer Card utilising their
planned SoC.
> Backend engineering is an expensive, labour intensive and somewhat dull task,
> which is made easier by better quality front-end design, which is our focus at the
moment.
ha :) perfectly understood.
so, here's the key question, all the above is background / clarification.
would you and the team be happy to go into details about what the
proposed target markets are? some scenarios would help lock it down
pretty quickly. what kinds of peripherals and sensors are expected to
be connected in classrooms / universities. which segment of the
embedded market is to be targetted. what are the usage scenarios for
the IoT market.
from there, it's a pretty straightforward task to identify exactly
which interfaces (and how many) are required. from *there* it's a
simple matter of iterating around an adaptation of pinouts.py to
create a suitable pinmux, if indeed one is actually needed at all,
depending on the speed / bus-widths that the I/O minioncores could
cope with. the reason i mention that specifically is: if a 200mhz
48/64-bit-wide SRAM bus is required for one of the target markets, for
example, a minioncore may not *actually* be capable of handling either
that wide a bus (without special extension to its instructions), or
have the kind of instruction-set bandwidth to cope with bit-banging a
200mhz bus clock rate, particularly if it's in 45nm and is only
running at say only 500mhz.
this kind of analysis is what i'm good at. some people would
consider it... labour-intensive or simply... far, far too many
variables to cope with: i quite like it :)
in this case however, given the very specific focus that the team
currently has, it would be almost a dis-service to pull them off of
that, i've read the articles about the effect that context-switching
has on human neural structures / brain chemistry. the results are: a
dramatic drop in productivity.
l.
10:41 a.m.
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Mon, Nov 27, 2017 at 12:06 PM, Dr Jonathan Kimmitt <jrrk2(a)cam.ac.uk> wrote:
Dear Luke,
this seems like a lively discussion,
:)
I overlooked in your info that fixed
and multiplexed pins are in separate tables.
ah! sorry, yes i rushed it, i haven't yet added any descriptions of
each section, mostly because it has to be "print" statements inside
pinout.py..... normally one would expect a document's section to at
least contain an introductory paragraph. my apologies for not yet
adding any.
Regarding the JTAG,
my point was that JTAG_SEL would not
be a testable boundary scan pin, if it controlled access to
the JTAG TAP itself,
the usual way is, it simply loads into internal sram/state the
*default* value at power-up/reset for the pinmux for the JTAG tap.
after boot - or even at test time - there's nothing to say that test
mode should not overwrite the pinmux registers to change them...
... one could conceivably consider that JTAG is just "yet another
function amongst many that will need a full test", and it would indeed
be necessary, with a pinmux I/O front-end, to do a full and complete
scan of *all* available functions, via *all* available pinmux options
(4 functions per pin in this particular design example).
in that regard JTAG should not be considered particularly...
"special"? or am i missing something?
but this might
be an acceptable testability loss. It sounds like you have many of the same
objectives as ourselves,
indeed. i'm a big fan of the principles on which the lowRISC project
is founded.
and what would be a useful contribution would be to take a copy of
our
database and patch it using
open source IPs, such as the open source DDR that you mentioned, to
demonstrate a viable
integrated solution which does not require Xilinx IPs.
bear in mind it doesn't have a PHY, it's just the controller, relying
on FPGA SERDES.
At the moment we are
not accepting new GPL and LGPL
blocks because of the uncertain legality of linking these blocks with
proprietary ASIC libraries.
LGPL is absolutely no problem at all. i am extremely familiar with
the LGPL: it's called the "Lesser" GPL for the very specific reason
that you CAN use it in conjunction with proprietary source code.
what you ARE required to do is to release any modifications of the
*LGPL* licensed blocks.... and of those LGPL-licensed blocks ONLY.
you are absolutely absolutely 100% absolute cast iron absolute 100%
without fail absolute competely and totally NOT under ANY obligation,
IN ANY WAY, shape or form, required, compelled or anything else you
can think of that's emphatic enough you're getting the point i'm sure,
required to place ANY PART of ANYTHING that is NOT under the LGPL
license under that same LGPL license.
examples:
* a proprietary test suite associated with a proprietary hard macro
is placed alongside an LGPL component. requirement to release
proprietary test suite under the LGPL: ZERO. NONE. whatsoever.
requirement to release proprietary hard macro under the LGPL: ZERO.
NONE. whatsoever.
* a BSD-licensed design (e.g. lowrisc) is linked together with an
LGPL component. requirement(s) or obligation(s) to release
BSD-licensed design under the LGPL: ZERO. NONE. WHATSOEVER.
* {insert anything you like code, sourced from anywhere you like}
linked together with an LGPL component, and the LGPL component is
modified from its original. requirement(s) and obligations(s) to
release modifications TO THE LGPL COMPONENT and the LGPL COMPONENT
ONLY: full, total and complete.
the GPL on the other hand, yes, absolutely, it is absolutely critical
that under no circumstances should you use GPL hard macros when there
are BSD-advertising-clause hard macros or any proprietary hard macros,
because you will be completely unable to simultaneously fulfil the
obligation(s) of the proprietary "secret' license / the
BSD-advertising-clause license, and those of the GPL license.
it's really important to remember that the GPL and the LGPL are
*completely different* licenses serving totally different purposes.
one can co-exist perfeclty well with proprietary licensing practices;
the other most definitely can not.
in effect the best way to think of the LGPL is as if it was a GPL
license applying to *one* die of a Multi-Chip-Module design. split
out the proprietary parts into their own die(s), keep the LGPL'd
component on its own die, you *still* have to release the source code
modifications to the LGPL'd die, right? but it makes totally NO sense
to say "oh just because you connected this proprietary die to an
LGPL'd die, you MUST forcibly release full source of the proprietary
component in direct violation of the NDA, right??"
... makes no sense whatsoever, does it? :)
the LGPL *specificlally* allows for that scenario.... with
implementations of LGPL and proprietary hard macros *co-existing on
the same die* rather than being in a MCM.
so, summary:
* LPGL: absolutely no problem whatsoever as long as you release all
and any modifications to LGPL-licensed code
* GPL: don't touch it with a barge pole.... unless you're happy to
have literally the entire source code converted to GPL licensing (or
the BSD license is one that's compatible with the GPL). or...
unless... [see several paras down, below] you take a Multi-Chip Module
approach.
hilariously i did actually track down a full set of BSD/GPL-licensed
interoperable hard macros, including an implementation of a DDR3
Controller (another one - a third one - that's GPLv3+ licensed). it's
really DDR3 that's the main pain: everything else really does already
exist (unless you want an on-board USB PHY, on-board ETH PHY, on-board
PCIe or other SERDES, or anything else analog-based....)
This would rule out some of the Opencores designs, and even those
which are
eligible would require adaptation to use
NASTI(axi compatible) bus instead of Wishbone bus.
if the latency associated with conversion is acceptable i believe
there is an AXI-to-Wishbone hard macro on opencores as well. i'm a
big fan of "not having to do unnecessary work when it's not
actually... necessary" :) for low-speed peripherals (UART, I2C, SPI)
the additional latency of a couple of clock cycles *really* should not
be a big problem at all.
We also do not assume that a Minion I/O processor would have a
conventional
Von Neumann architecture, or that
it would have to be a Turing machine. Any kind of state machine that did the
job might be the best solution.
oh! my [mis-] understanding of the minioncores concept was that they
would actually be riscv-32 cores! ha. then many of the engines on
opencores would in fact qualify - loosely - under such a definition.
I find it gratifying that you emphasize the importance of providing
viable
Linux drivers to go with the various hardware
blocks. These kind of details can use up quite a bit of time in getting a
solution going.
yehyeh. why spend time doing things that have already been done??
an example: 5 years ago i managed to add 350 classess with 20,000
auto-generated python functions to webkit in just under 10 days. no
bugs (the code was so complex that any errors *instantly* caused
blindingly-obvious segfaults or memory leaks so large that they caused
near-instantaneous meltdown into swap. and, because it was
auto-generated code, you get it right once, you got it right for
10,000 auto-generated instantiations...).
it was a hybrid combination of select parts of the webkit codebase,
the mozilla foundation *firefox* codebase and an adaptation of the
python-gobject IDL code-generator (!). i plugged all three together
at strategic points, and whoosh, done: python becomes a *full* peer of
javascript when it comes to DOM/HTML manipulation. in under 10 days.
once i'd gotten the mozilla IDL parser to understand webkit's IDL
syntax, then adapted the output engine of the mozilla IDL parser to be
the *input* to python-gobject, then added implementations of the
various specialist datatypes to the python-gobject generator it came
together far faster than it really had any right to do so by "normal"
software engineering standards.
primarily, i set a goal and i don't *actually* care too greatly
(except about inviolate ethical standards) about how it's achieved.
save vast amounts of time, effort and money, and gets the job done.
total opposite of how most companies operate, because one of their
absolute top priorities is: increase profits by "owning" as much as
possible and keeping it as "secret" as possible.
so, anyway, yes: it was ICubeCorp who utilised the opencores LCD/VGA
controller in the IC3128, and wrote the linux kernel driver for it
(under the GPLv2). as is defined in the controller VHDL source, it's
fully-capable of supporting 32-bits per pixel *right* the way down to
8-bit (rgb=332 or 323, whatever you define), even supporting 1bpp mono
output. the only thing is: the actual implementation of the IC was
running at only 400mhz clock rate (55nm fujitsu foundry), and i
believe that was just too slow to allow the internal bus bandwidth to
be fast enough to support the rate at which the framebuffer needed to
be read. i managed to run at 800x600 up to 24bps, but going to
1280x800 i had to ramp down to 8-bit per pixel. i'm almost certain
that this is *not* a limitation of the LCD/VGA controller itself but
is of the design choices made by the ICubeCorp team to run at a 400mhz
clock rate. perhaps by adapting the controller to widen the bus would
help, if the clock rate of the lowRISC SoC is to be at anything
approaching 400mhz?
We have also found that many HDL projects are a work in progress, and
it is
one thing to point to a solution, and another
to understand it and/or update to the point of being able to use it in an
integrated SOC project.
If our first product turns out to be a semi-custom or sea-of-gates
implementation,
not sure of the terminology here, are you referring to the metal-mask
conversion of FPGAs into "ASICs"? the ones where they hard-code the
FPGA logic instead of being programmable as just a "metal mask"?
there will be a performance penalty
to pay for the lower up-front costs, and consequently high-end applications
such as laptops would be ruled out.
... and/or a higher power cost. as a demo on the way to mass
production, and as an opportunity to at least get working silicon out
to developers (fedora-riscv and debian-riscv), it would do perfectly
well.
When I mentioned IoT, I was particularly thinking of Wireless
consumer
devices (Zigbee/BluetoothLE/Wifi interfaces)
which as you say are a subset of embedded solutions with particular
requirements, such as long battery life.
indeed. so, hm, my understanding of (mass-produced, low-cost) IoT is
characterised by low pincount (well below 50 pins in many cases: the
ESR8xxx series for example), integrated on-board SRAM / DDR RAM, and
if practical integrated on-board WIFI. the Ingenic M2000 and X1000
are good examples. MIPS has traditionally been a good choice
(Ingenic, RTL, Mediatek) especially for those SoCs with a heavy focus
on networking. 2 to 5 integrated 10/100 PHYs plus 802.11abgn WIFI.
... the problem being: that's mixed analog + digital territory (which
is a hellishly hard problem to get right), plus proprietary firmware
(not something i'd imagine the lowRISC CIC would wish to be
promoting), and not even Mediatek, one of the lowest-cost (and highest
GPL-violating) companies in the world does it as a single SoC. they
do their "integrated" GSM/3G chipsets as a Multi-Chip-Module, with
separate dies for the R.F. base-band for example.
creating a low pincount IoT SoC which is *easy*, means cutting out
ADC, DAC and anything that's analog (unless it's proprietary and the
mixed A/D problems have been pre-solved). so, no on-board USB PHY
(except a proprietary one), no on-board 4-pin ETH 10/100 PHY (Tx+/-
Rx+/-) unless that's proprietary as well, so the pincount
automatically goes up 8 instead of 2 for using a ULPI, and around....
16 for using MII / RMII / RGMII for ethernet.
unless... you can source a company that's happy to sell bare ETH PHY
dies and bare USB PHY dies, and you make a Multi-Chip Module out of
them. that also cleanly and most obviously solves any potential
misunderstandings over LGPL licensing issues, even GPL ones.
For the avoidance of doubt, my suggestions to you are my own view and
not
the considered view of the while LowRISC team.
not a problem. perhaps a meeting of the team, at some point would
help, to clarify and agree exactly what the target market(s) are. my
only real critical (minimum) proviso to offering assistance would be:
full EOMA68 hardware compliance without requiring significant
additional external PHYs / ICs (nothing above around $3 of extra ICs
vs a standard "integrated" SoC such as the Rockchip RK3288, NXP
iMX6/7/8, the Allwinner A64, or the A20). so, i don't mind a $1
ULPI-to-USB PHY, but if a $5 or $10 USB-to-Video converter IC plus $10
of RAM (e.g. using a DisplayLink IC because there's no kind of video
output on the planned lowRISC SoC) then that would be a definite "no,
sorry, you're on your own" - not least because the SoC would be so
simple you'd not actually *need* my help :)
once that's done it's really straightforward for me to assist the
team by producing a suitable low pincount pinmux that covers all the
clearly-defined target markets.
I can confirm that at no point will LowRISC become proprietary, we
are so
open that everything we have is stored
openly and externally on GitHub, including all our mistakes and also-rans.
Not many companies can say that.
ha. tell me about it. CIC is a really good choice as it sends the
right kind of message: combined commitment to being profitable...
*and* allowing libre community values to be an integral part of the
company charter. i've read professor yunus's book "creating a world
without poverty": he explains it well that profit-maximisation, when
the chips are down, is *the* only priority. in standard companies,
"Corporate Social Responsibility" *has* to be viewed as "Corporate
Financial *ir*responsibility"... and has to be ignored. a CIC allows
for the *true* prioritisation of both profit and ethics.
l.
2018
days inactive
2018
days old
4 comments
2 participants
participants (2)
-
Dr Jonathan Kimmitt -
Luke Kenneth Casson Leighton