Author: Steve Wiseman Date: To: balloon Subject: [Balloon] Balloon4 - progress & questions...
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).
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?
One MMC is missing. Anyone care? We've got NAND for fast storage, and USB for I/O.
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.
--------------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?)
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...
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).
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.
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.
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.
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?
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.
(text/plain)