Interesting "Competitors" for the Raspberry Pi

Got a quick email update from the Cubieboard folks ...

Intial 200 prototypes sold out. 1,000 users in the forum, 4,000 subscribed to the notification list, growing about 100 per day.

To meet demand they are crowd funding via http://www.indiegogo.com/cubieboard

Estimated shipping was end of Nov.

-J

Hey jamodio

I liked the sound of cubieboard's specs - so I just "contributed". It could be fun since I have several sata drives.

Peg

Do you mean the base board is like a backplane (maybe just lots of wires and hardly any components at all) perhaps connected to (say) some high-speed 16-bit parallel bus? If so, then It would be nice for that board to have a full mesh at that point between the 4 processors (should be feasible since the BGA has lots of pins). But I'm no expert in multi-processor designs. Maybe that is overkill. Maybe virtually it could look like three Ethernet connections from each processor to the other three, if someone wrote some nice drivers.

Or, are you thinking of a base board with a CPU, that is like a dispatcher, that can choose each of the 4 processors to send tasks to? Then the results from each processor are somehow queued (maybe a FIFO) and fed back into the base board processor to pull out the results as quickly as possible.

Or, I suppose a set of processors could communicate to other sets using GigEth, although then it needs an external switch unfortunately.

I don't yet have a scheme for the interconnect within each quad-SoC board, as the exercise so far is just to imagine a board that can be used either standalone as a quad computer (with a connectors board attached) or as a building block for assembling larger systems.  This would make it a viable product to have manufactured, since the market for quad boards will undoubtedly be much larger than for a 4x4 machine, let alone an 8x8 one or a pyramid of 4x4's.

The only essential requirement so far is that the quad board has to be expandable by stacking 4 of them together to yield a 4x4 processor stack.  The reason for choosing stacking instead of a backplane is twofold, firstly because backplanes are much more expensive than stacking connectors, and secondly because the signal path is longer on a backplane and varies more from shortest to longest.  (Memory is of course local to each processor.)

I still have no good solution for the interconnect controllers though.  I guess one could put a 4:1 gigabit Ethernet switch IC next to each SoC so that each core has 4 links, but that would be pretty expensive and the aggregate bandwidth is 1X or less, instead of 4X.   One could also route all 4 SoCs into a single 4:1 switch IC and use the upstream port for routing off-board to the other 3 boards in the stack, but that's even worse, 1X or less instead of 16X.  The communications bandwidth of a mesh with point-to-point links is directly proportional to the number of nodes and can increase indefinitely, whereas with full-duplex Ethernet buses shared through switches it can only decrease.  The technical term for this is "bad".

So, I still don't know what to do about scalable interconnect, other than to call on ARM to add links and controllers to the ARM architecture.

PS. Since in all likelihood nothing suitable exists, using an FPGA plus 4 gigabit PHYs may be inevitable.  Hooking that to the SoC's DMA is going to be tons of fun.  Only fully documented SoCs need apply.

Oh! I see. I had misread, and thought each board had one processor. Agree, each 4-processor board could have a full-mesh (since there are lots of pins) (and they could still look like very fast virtual ethernet interfaces with some clever coding). The interconnect between boards - I can't think of good, cheap ways either : (

At some stage a dispatcher and FIFO to store up results would be pretty neat, and allow the 4x boards to

take tasks and process in their own time, and allow the base board to collect the results in its own time, but I guess would be extremely expensive to implement, with expensive FIFOs and probably some fast CPLD or FPGA.

I'm not very knowledgeable on multi-CPU designs.

shabaz wrote:

 

Oh! I see. I had misread, and thought each board had one processor.

Well, a single SoC on a modular board is already covered by Rhombus Tech , assuming that it sees the light of day.

However, that module is not intended for tightly coupled integration, because (AFAIK) DMA is not brought out on the EOMA-68 connector because they want to be able to switch SoCs as technology evolves, and DMA operation is not standard between manufacturers.  That is sensible of Rhombus Tech given their design target, but unfortunately it offers no opportunity for enhancing the SoC with DMA-operated links.

what about using an FPGA with a LVDS interconnect between boards or would that be more expensive than the gig switch?

George Ioakimedes wrote:

 

what about using an FPGA with a LVDS interconnect between boards or would that be more expensive than the gig switch?

That's probably the cheapest way to do it, and probably necessary both for signal robustness and to avoid radiating from here to China.

A TI SN75LVDS387 provides 16 x 630Mbps LVDS drivers for £8.01, so it's not prohibitive to have two of them for the 4x4 bidirectional links, driven by the FPGA which will need to handle message transfer through the drivers and DMA interfacing with the SoC.  I've not investigated further though.

This would not be a simple project.

and i'm fortunate to get favorable pricing from TI since we tend to buy a bunch of their stuff. so did you already jump ahead in the design cycle and are thinking about another board (the low cost i.MX6 competitor to RPi) or are your thoughts that this is a better product to produce?

No no, it would be an unmarketable product to produce, far too niche. 

I suspect that only researchers in parallelism would be interested in such special interconnect, everyone else wants one Ethernet per host.  Even the single 4-SoC board is likely to appeal only for DNS round-robin web serving and hence most purchasers would be expecting one Ethernet per host.

I think what I'm describing is what ARM should be knocking up in their R&D lab in order to determine what route to take for ARM clustering.  I doubt that a user-level product implementing similar concepts would be anything like the above in terms of actual implementation.  It's more an engineer's prototyping platform.

Stick with your first idea of a barebones i.MX6 RPI price competitor, I don't think you can lose with that.

In other words, this continues to be just "thinking aloud", although of course I'd love everyone's input to help it along.

At the very least this is tempting me to grab a couple of small FPGAs and LVDS drivers and experiment with message passing.  Since it'll have to be asynchronous and rate-adaptive, that's quite enough to chew on for a while.

OK, so the low cost i.MX6 will continue, hopefully I'll get a meeting with Freescale early this week and can update more after that. Still would be nice to have a bullet list of questions/requests that I can present to them.

I think the FPGA/LVDS is a decent enough approach to at least look into more. I haven't done any FPGA work but I go interested enough to buy a few development boards, all Xilinx so hopefully if things progress it can go with a Xilinx based solution.

OK, so the low cost i.MX6 will continue, hopefully I'll get a meeting with Freescale early this week and can update more after that. Still would be nice to have a bullet list of questions/requests that I can present to them.

I think the FPGA/LVDS is a decent enough approach to at least look into more. I haven't done any FPGA work but I go interested enough to buy a few development boards, all Xilinx so hopefully if things progress it can go with a Xilinx based solution.