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

Great stuff!
Comments in line below...

On 23 May 2011, at 19:27, Steve Wiseman wrote:

> Hi, all. Some progress report, some questions, and no doubt some sidetracks:
>
> Progress: Good
> Architecture - done
> Parts: Mostly chosen. See below.
> Datasheets: Read. Thousands of pages of tedium. Obviously ongoing.
> Schematic - about 80% done. All non-trivial library parts done, some plumbed together.
> PCB: Started. Some footprints done, DDR routing done, before the choice of DRAM became a vexed issue.
> (6 layer board looks fine. Nice & cheap & manufacturable).
>
> --------------Pinmux decisions complete. ----------------
>
> We have:
> Camera (including MIPI modes, although I haven't seen these work in anger)
> DSS (LCD/display)
> Small number of GPIOs
> GPMC (memory bus for NAND, FPGA, other_stuff)
> HSUSB0, 1, 2 (Woo, 3 channels of High Speed USB)
> HW_DBG (debug)
> I2C 1-4 (Woo, 4 i2c buses, although one is dedicated to the power manager)
> MCBSP1, 2 (but not 3, 4 or 5) (MCBSP1 is the spiffy one)
> MCSPI1 (but not 2, 3, or 4)
> MMC1 (4-bit databus mode)
> MMC2 (4-bit databus mode)
> SDRAM controller
> SYSTEM stuff (boot, jtag, clks, reset)
> UART 1, 2 3 all with RTC/CTS flow control. There's no inherent support for more complex control, use GPIOs for that)
>
>
> We do not have:
> ETK (trace)
> GPT outputs (PWM channels)
> HDQ (single wire IO)
> MMC3
>
>
> Contentious:
> Not many SPIs. Do we care? Anyone use them, except for audio?

We were thinking that this was the way forward for internal interconnect within products.
So much small stuff uses SPI (light detectors, ADCs, keyboards etc.).
However as long as we've got one and some chip selects that will probably do fine.
The FPGA tends to mitigate for a lack of OMAP IO, which is the whole point...

> One MMC is missing. Anyone care? We've got NAND for fast storage, and USB for I/O.
No

>
> I can share the spreadsheet of what clashed with what, if people care. Also pinmux files.
> Note that generating the library part for the OMAP was tedious. Pinmux alterations will need to be justified.
It would be nice to have for the record and will stop people asking endless questions of the "Why can't we have SPI47 and MMC53 the beagle-blah-blah has both" kind.

>
>
> --------------Concerns: ---------------------
> Power.
> The mission for Balloon4 is to have it manufacturable, which means that TI's Power Management ICs (PMICs) are, in general, tricky. The best ones are in 0.4mm BGA packages, which is _not_ good for PCB costs. They're also notoriously fragile. Expensive. Single-sourced.
> The ones in packages we can use aren't rated to drive the OMAP at its highest speed profiles. (The OMAP counts its toes, then checks its process geometry, temperature, phase of moon, then chatters over i2c to the PMIC to pick a supply voltage that will probably allow it to work without failing unreasonably quickly. This is explicitly defined in the datasheet - we don't have to use a PMIC, we could build a little micro to listen to the i2c, and set the voltage as requested. But, if we're having a little micro, what else would we want it to do? Boot stuff? RTC in ultra-powerdown? Battery Charging? Keyboard Checking?)

Having a small low power micro that can allow the system to shut down to micro amps and wake up on an external event is a big win.
Once we have a full architecture diagram I guess it will be easier to see what else it could do, but all you mention above sounds like a good idea.
My only concern is debugging the software, if we screw up we blow the chip and given the number of software debug cycles is usually >100 (for embedded) thats a fair number of broken boards.
So this will need careful design and a solid debug/test strategy to minimise the damage. (I'm guessing this is mine...)

> The spiffy PMICs also tend to have handy stuff like USB OTG PHYs, which can be used to boot. If we don't have the exact same phy, I'm unconvinced we'll be able to boot from USB. I don't think I care. Does anyone? We can still boot from (at least) serial, NAND, MMC...
I don't see that as a real problem, as long as we can boot from at least one pluggable device (assume SD) that should be fine. There is also the possibility that it isn't as picky as we think.

>
> DRAM:
> Oh good grief. Been round this a dozen times. Anyone know what LPDDR devices actually exist? 1 or preferably 2 Gbit. (although I'll take 4GBit if they exist). Not POP package. If there's a sweet spot, I have yet to find it. Anyone with access to purchasing channels, anything that says 'LPDDR' is fair game. DDR, DDR2, DDR3 are not acceptable. 'Mobile SDR' is not acceptable. 'Mobile DDR' may be. x16 or x32 are both of interest (although x32 may or may not be acceptable to run 2 banks. The POP packages run with 2 banks of x32, but with short buses. The datasheet says not to, so, if we want a low-risk 2-chip solution, we may need x16 chips, but I'll take what we can get).

OK, chuck me some pointers to potential parts and I'll see if we can find them, John is on holiday this week so it may take a few days to talk to distributors.
I'm guessing the problem is that every mobile phone manufacturer sucks up the entire output and we are left to pick up the droppings when they have a short month, as usual....

> NAND:
> Likewise. We want 1.8V, which means BGA package. Which seems to be non-catalogue. What's out there, and how much NAND do people want? I can design for x8 or x16 widths, and pretty much any page size, although, if the OMAP bootloader is to be involved in booting from NAND, there are some restrictions on device ID and page sizes (maybe - inconsistent data).
> I've got more sources of NAND than LPDDR, though, and we can, if necessary, run without NAND. LPDDR solutions are more urgent.

My guess would be x16 and 2 chips, assuming BGA NAND has a well defined footprint and we'll keep seeing size doubling in the same footprint every 3 years that should be fine.
We've never used more than 2 on Balloon except in a few cases where a USB stick would probably do the job just as well.
The PCB area needed for 4 is probably unjustifiable.

> HDMI:
> Licensing. Lawsuits. Compliance. Generally being a pain.
> Given Nick's great success today in ramming an X display down USB, does anyone still want HDMI? We don't have the hardware (or software resource) to play video. HDMI will only bring us woe, and I say that as a seasoned HDMI designer-inner.

I'm not in favour of supporting HDMI on OMAP3.
OMAP4/5 may be a different game.
This is supposed to be embeddable and the PCB/IO space that will have to be dedicated to it may not be justifiable.
On the other hand this rev of Balloon 4 is supposed to be a generic Balloon 4 and Challenger (The TCL instantiation of Balloon 4) will shrink from this and won't have HDMI, ('cause I won't spec it unless there's a really good Use Case I've not heard yet...)
So there is a small argument that says this rev of B4 should have HDMI so we've spec'd how to do it just in case someone, like CUED, really wants to do a instantiation with it on.
It could always remain as an unimplemented schematic (this fits with the new open source strategy).

> Xilinx:
> Spartan-6, still not decided on the device of our dreams yet. It partly depends on what we can get in a package that doesn't compromise manufacturability - and I won't know that until I know what design rules other components force us into using.
Last time we looked the small volume pricing was prohibitive but we should recheck.
Send me a few part numbers.

> All packages will have more pins than we can sanely use. Once we've strapped some DDR to the chip, attached it to the OMAP through the GPMC bus, camped it on the camera bus and a serial bus or two, how many pins are people thinking they want? Tens? Hundreds? Enough for a couple of LEDs and a few motors / i2c buses / Samosa-style parallel buses?

50ish GPIO? Start bidding guys...
There needs to be enough to replicate SAMOSA, and have some dedicated IO.
Or repurpose as general bit IO, or have a more conventional address data bus (of limited address range say 4096).
But these can all be mutually exclusive to a fair degree.

> Everything else: Easy.
>
> Administrivia: I'm too dumb/busy/overloaded to strap Altium's release management to TCL's server. I also don't care enough.
>
> Anyone who wants a huge pile of schematics, spreadsheets, annotated datasheets and pinmux data files, let me know.

If you chuck me a tar file I'll sort out an archive, and have a squint at it at the same time...

>
> Basically, good, tedious progress. Discuss.
>
> Steve

Further questions....

We also talked about low end LCD panel support via a CPLD, Chris Jones had some doubts about this approach, do we have any support for QVGA/VGA bog standard LCD panels.
Some of us don't need real time video but do need OMAP levels of processing power.

Do we still have the backplane connector, have we spec'd whats on it yet?

Regards

David