[Arm-netbook] [review] SoC proposal

[lkcl luke]

On Thu, Feb 9, 2012 at 11:41 AM, Gordan Bobic <gordan at bobich.net> wrote:
> lkcl luke wrote:
>> On Thu, Feb 9, 2012 at 7:41 AM, Vladimir Pantelic <vladoman at gmail.com> wrote:
>>
>>>>   we evaluated the possibility of coping with 1080p30 video decode, and
>>>> worked out that after one of the cores has been forced to deal with
>>>> CABAC decode all on its own, the cores could then carry out the
>>>> remaining parts of 1080p30 decode in parallel, at about 1ghz, quantity
>>>> 4.
>>> I would not recommend fully loading the cpu while decoding video, HD
>>> video is becoming a commodity and people might soon use it as an "animated"
>>> wallpaper while doing other CPU intensive stuff
>>
>>  last year the target speed was 1.5ghz, 4 cores.  this time we
>> envisage 8 cores at over 1.2ghz, and the cores can be made to support
>> VLIW which can result in 3x the effective clock-rate.  so i don't
>> think that CPU horsepower is something to worry about.  the only thing
>> that's of concern is to not put too _much_ horsepower down so that it
>> goes beyond the gate-count budget.
>
> I think you need to look at this from the practical standpoint.
> Specifically:
>
> 1) Is there GCC support for this SoC's instruction set,

 yes.

> including VLIW,

 don't know.  tensilica have a proprietary "pre-processor" compiler
that turns c and c++ into VLIW-capable c and c++.

> SSE,

 what is SSE?

> and all the relevant CPU extensions?

 yes.

> How many man-hours will it
> take to add reasonably well optimized support for this, and how long
> will it take to stabilize it for production use (i.e. good enough to
> rebuild the entire Linux distro including kernel, glibc, and other
> packages that resort to assembly in places)?

 already done. http://linux-xtensa.org/

> 2) How long will it take to add Linux kernel support for this new SoC
> and all of it's features?

 98% already done. http://linux-xtensa.org/ - that just leaves porting
of the new SoC's hardware, which will deliberately be picked to be as
close to pre-existing drivers on other SoCs as possible (by licensing
macro blocks that are already used by other SoC manufacturers and have
linux kernel drivers already written).


> How many man-hours will that take before it is
> sufficiently tested and stable for an actual product that the end
> consumers can use?

 don't know.  tensilica have proprietary software libraries for audio
and video CODECs already (obviously)

> 3) How long will it take to add support for this SoC to all important
> packages that use assembly in places?

 don't know, but to do so would not be smart unless it's _really_
critical, simple and has a big pay-off.


> You might have the hardware out in 18 months' time, but I would be
> pretty amazed if you managed to get the OSS community enthusiastic
> enough about this to get the whole software stack ported in an amount of
> time that is less than years - by which time the SoC will be thoroughly
> deprecated.

 98% of what's needed is already in place.

 the goal is: to design the architecture in such a way that the
remaining 2% can be done quickly and simply.

 there's enough examples of how _not_ to do this out there such that i
think it would be possible to find a fast route to market in amongst
them.


> Look at the rate of progress Linaro is making, and they have a
> multi-million $ budget to pay people to push things along, and an OSS
> community that already has ARM well boot-strapped and supported.

 yes.  that just adds to the cost of the CPUs, which is unacceptable.

 i'd like to apply a leeetle bit more intelligence to the task, namely
for example to add instruction extensions that will help optimise 3D,
and to say... find out how much effort it would take to port llvm and
to evaluate whether gallium3d on llvmpipe would be "good enough" if
optimised to use the 3D-accelerating instructions etc. etc.


> I think you are underestimating the amount of effort required to make
> this a success.

 noOoo, i'm asking people to help submit intelligent ideas to help
_make_ it a success.


> Much as I would really love for it to succeed, I don't
> think it plausibly can - at least if you start with an ARM or MIPS core
> you already have the basic things like the kernel, gcc and glibc sorted.
> Having said all that, I'd love to be proved wrong.

http://linux-xtensa.org/
http://wiki.linux-xtensa.org/index.php/Xtensa_on_QEMU
http://wiki.linux-xtensa.org/index.php/Boot_Loader
http://wiki.linux-xtensa.org/index.php/Kernel_Build_Instructions
http://wiki.linux-xtensa.org/index.php/Buildroot_Build_Instructions
http://wiki.linux-xtensa.org/index.php/Toolchain_and_Embedded_Distributions

hmmmm.... the page referring to the patches doesn't exist.  i'll just
send a quick note to their mailing list.

l.