[Arm-netbook] The future of EOMA-68

[Luke Kenneth Casson Leighton]

On Sat, May 2, 2015 at 5:24 PM, Manuel A. Fernandez Montecelo
<manuel.montezelo at gmail.com> wrote:
> 2015-05-02 17:00 Paul Boddie:
>>
>> On Saturday 2. May 2015 17.07.57 Manuel A. Fernandez Montecelo wrote:
>>>
>>>
>>> Speaking of openness/FSF-endorsability, and having into account that the
>>> current focus is to go ahead with what is already planned like the A20,
>>> with which I fully agree (so please don't take this as a demand, just as
>>> showing interest) -- would it be feasible in the near future to have
>>> OpenRISC or RISC-V (or RISC-V-based lowrisc, when ready)?
>>
>>
>> I imagine that it depends on things like availability of hardware versions
>> of
>> CPUs for these architectures. I recall that there was a board for OpenRISC
>> that used an FPGA, and there was also a fundraising campaign for an ASIC
>> version of, I think, the OR1200 which didn't succeed. So it may be the
>> case
>> that an FPGA solution is the only remotely near-future option, and that
>> brings
>> a lot of other issues.
>
>
> Basically, the underlying question of what I was wondering (because I don't
> have
> any idea about hardware manufacturing), is if instead of asking companies to
> manufacture EOMA-68 A20 CPU cards, they could be asked to manufacture the
> same
> but with OpenRISC or RISC-V cores instead.

 yeeess...  but to do so requires those steps (1) through (6) i told
you about.  you can't just drop a processor onto a board and hope for
the best, you actually have to custom-design the *entire* PCB - 300
components usually, thousands of individual wires (each one with
rules).... it's not as straightforward as "yeah just put a processor
down, it'll work".

>
>> There's also the distinction between plain CPUs and SoCs. I don't really
>> follow what goes on around these things, but I recall that the people who
>> were
>> developing the Milkymist One hardware were aiming to deliver an SoC
>> solution
>> based on the LatticeMico32 core:

 plain CPUs are just that: a Central Processing Unit - nothing more.

 it means that you then have to have a monstrously-fast (meaning
"power hungry") I/O bus, which was fine back in 1986 when it was an
8-bit 8mhz bus called "XT", but now, peripherals are so f****g fast
you need about 2 watts just to drive the damn I/O signals up and down!

 i don't know if you're aware, but a *single* I/O pad on a SoC is
*bigger* than the RISC core itself.  it's completely mad.

 so to avoid that, SoCs integrate all the I/O onto the chip, so that
the "communication cost" can at least be cut out of the system's
equation.

 the problem then becomes that SoCs end up being extremely specialist.

>>
>> https://en.wikipedia.org/wiki/M-Labs
>>
>> I don't know what the situation is with OpenRISC and SoCs.
>
>
> I also don't know much about this, but there are efforts in that direction
> (both
> in OpenRISC and RISC-V camps), for example:
>
>  http://opencores.org/or1k/ORPSoC
>
> lowrisc themselves want to go ahead with a SoC based on RISC-V, with
> additional
> CPU features.

 *sigh*.  academics.  absolutely no clue about the real world.  the
cost of getting the chip made is by far and above the largest part of
the exercise of getting a chip to market.  so they're going to make
something which has no graphics, no video acceleration - nothing.  why
would *anyone* want to buy such a chip???  madness...

 anyway, good luck to them - they have a lot to learn.

l.