[Arm-netbook] Allwinner outsells Intel

[joem]

On Thu, 2013-05-09 at 13:29 -0500, Troy Benjegerdes wrote:
> > You are going somewhere I do not wish to follow - HPC - its a completely
> > different subject.
> > 
> > Lots of IO port pins are available, and first target for me at least
> > is simple low cost assembly of images in a conveyor to replace
> > proprietary graphics cards. So if product has to play video and do some
> > simple game like functions, then copy and paste two CPUs, interconnect
> > some IO pins to compose images and transfer images between CPUs to
> > destination CPU that has the LCD. At $20 per A10 chip + 1GB RAM +
> > components, no one batter an eye lid if the solution works.
> 
> DO it. Show me a Kicad file. You still need to move all that image
> data to a display. That actually starts to look like a HPC problem.
> (I started https://bitbucket.org/dahozer/infiniband-fpga, for HPC,
> but it might work for collecting all those images in the way you
> are talking about above)

The evolution of ideas (in parallel with other on going projects) is as
follows:

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 an n stage image pipeline can be built fairly easily.

Once built its game over for graphics IP trolls and their NDAs.
But if they were to release documentation it may never get built.


> > > ...and even THEN it  will be highly different from "just a multi-core
> > > processor", it will probably look like several independent nodes with at best
> > > shared access to a RAM area, and this will help you only in specialized
> > > computing tasks specifically programmed for it (or via some more standard HPC
> > > layer like OpenMPI).
> > > 
> > > Not as simple as copypasting some KiCAD around.
> > 
> > As I say wait and see.
> > As the copy/paste experimentation begins, new techniques will evolve.
> > KiCAD for example is all text based, so in theory it is possible
> > to write a script where you enter number n of CPUs, and out pops
> > a fully formed text file with n CPUs fully wired up!!!!!!!!! :)
> > There are already scripts available for various features and
> > functions already. Its again a case of wait and see, or even
> > participate and do!
> 
> **TRY** it, and let me know when you've got some kicad files that
> pass https://www.my4pcb.com/net35/FreeDFMNet/FreeDFMHome.aspx and
> I might even pay to have them fabricated.

All the files released are GPL'd, anyone may take the files, repair,
modify, extend and fabricate as needed at any time.


> In theory, there's no difference between theory and practice.
> In practice, there is.

As I say wait and see.

The script takes *pre-routed* and tested sub-PCBs and track sets
and glues them together, changing net names and filling in missing
interconnect as needed, in a way that doesn't require autorouting.
Its not terribly difficult as all KiCAD is text file.
I know how to write autorouters, but as evident from the
method, the script will attempt no such feat.


> When I can do something like Topological routing automatically
> ( http://www.toporouter.com/ ) with KiCad, then it might, indeed,
> be almost as simple as 'cut&paste'.

Very nice.

> 
> 
> _______________________________________________
> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netbook at files.phcomp.co.uk