Re: [Balloon] Balloon4 - progress & questions...

Here is an update on where we are in the discussions surrounding Balloon4.

Steve and I have decided on a number of design features following a meeting last week.
At this stage I have to take a conservative view on the design.
It is important at this first stage we end up with an easily manufacturable working board that uses readily available parts that can be obtained with low MOQs.
Once we have proved the core design then we might well iterate with some "riskier" features.

We have made the following decisions:

a) To have only one RAM bank of 2Gb x 32b x 2 chips, these are readily available and comparatively cheap.
b) We will fit a PMIC BUT not the recommended one as we do not wish to shift the PCB complexity up a gear, we are trying to keep this simple. This may present some performance limits but not ones that most will notice.
c) In addition we will bus out all the relevant PMIC signals to a header so that a micro based solution can be implemented but board bring up will not depend on this.
d) We will use Spartan 6 (The footprint is yet to be decided but we will pick within the capability of the free tools and the availability of small part quantities and PCB complexity).
e) There will be no HDMI converter, but there will be DVI over an, as yet, undecided connector.
f) We are reviewing the exact pin allocations (but not anticipating any significant changes).
g) Basic peripherals, console, USB and Ethernet from the hub, will be available on the board as connectors. All other IO will be passed over a single large board to board connector.
h) We will ignore all exotic flash storage, for now, and simply put down some good old fashioned NAND. Obviously we will review this in time.

I will review the block diagram, update it with more detail and publish a first draft on the Wiki.

There are still quite a number of design decisions outstanding.

One of the more notable ones is the provision of WiFi/Bluetooth, either on-board or off board.
I am concerned that USB based devices do not currently survive suspend resume cycles well and given the intended low power footprint of Balloon this is a critical issue.
If we use non-USB devices (off board or on) then we need to provision the interfaces for them and identify devices.
To add to this we also need to choose pre-approved products as approvals costs are prohibitive.
If this design is to be taken up by small scale product manufacturers as an embedded solution then we need to address this issue.

All comments are, as always, welcome.

David.