[Arm-netbook] Allwinner outsells Intel

[Vladimir Pantelic]

On 05/10/2013 12:21 PM, joem wrote:
> On Fri, 2013-05-10 at 11:45 +0200, Vladimir Pantelic wrote:
>> On 05/10/2013 09:40 AM, joem wrote:
>>> The first attempt was the dual CPU ARM board
>>> http://www.gplsquared.com/SoM1/SoM1.html
>>>
>>> Then I realize the bit rates for LCD is best
>>> served by CPU with built in LCD controller, and even better with Linux
>>> running to manage and use cheap A10 as the CPU and the even
>>> higher pin counts matter. Could instead use USB/USB links as well,
>>> but the overheads might cripple data transfer rates.
>>> Current idea (which may change) is 32 bits for image in, 32 bits
>>> for image out and a few control lines for hand shaking.
>>
>> so you want to use bitbanged GPIOs to pipe data from one CPU to the
>> other? do you plan to poll the control lines thus hogging the CPU or to
>> get an interrupt for each 32bit word?
>
> pass (because the boards have not been built yes - this conversation is
> way too forward looking in a market that is constantly changing) - you
> got around 16ms per frame, or about 16 million CPU instructions you can
> execute before you must do something about that frame.
>
> Dropping a frame or part of a frame has no terrible consequences.
>
>>> So an n stage image pipeline can be built fairly easily.
>>
>> sure, the throughput will still by abysmal...
>
> Numbers?
>
> In what way?

You assume you can transfers one 32bit word over GPIO for every CPU 
instruction, but as you wrote you need some kind of control logic around 
that, so at best you will need 10-20 instruction per 32 bit word. So now 
you are using 20-40% of your CPU for this data transfer and as you want 
to chain CPUs, you need that done twice.

Also, on existing SoCs most GPIO HW blocks are not even able to reach 
that high data rates at all.

Look at modern SoC and realize that all high speed data transfer units 
are using dedicated HW blocks and not the CPU and bit banging ...