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

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Hector Oron
Date:  
To: steve
CC: balloon
Subject: Re: [Balloon] Balloon4 - progress & questions...
Hello,

Yesterday I had the opportunity to attend to Silica seminar with
lots of manufacturers (ARM, Micron, Xilinx, TI, Freescale, ST, ..) and
very interesting people (Wookey was there too :))

2011/5/23 Steve Wiseman <>:
> Hi, all. Some progress report, some questions, and no doubt some sidetracks:


> --------------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...


Discussion is still open on whether use TI PMIC or uController to do
the job, for which we do need to write firmware for. Someone needs to
carefully review specs, datasheets and make _very_ sure of what he is
doing is going to work and do it as soon as possible. Currently this
is most critical point in our current status. If someone feels
confident on doing proper work on this, please step up and do it.

> 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).


I have had discussion and talking with Silica, MSC and Micron
representatives, we are probably safe to get samples and get orders,
safest bet might be using VFBGA 60 pin (for x16) or 90 pin (for x32).
According to MSC representative some parts can be interchangeable
between manufacturers so we can select many providers, not just one,
as in Micron, Elpida, Samsung, Hynix and Nanya.
Having a talk to Micron representative, they have a product longevity
program but LPDDR parts have not made it there yet, according to
Micron FAE they had planned to include LPDDR in the longevity program
this month (June 2011).

As a summary, using Micron is feasible and it narrows down the
availability of chips to:
<http://www.micron.com/partscatalog.html?categoryPath=Products/DRAM/Mobile%20LPDRAM/&497=3&494=1&79=1&43=2>

It is on the TODO list check compatibility with other manufacturers.
I'll try to find out information about it and update.

> 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.


NAND can be brought to us from Micron as well, it might worth to look
the longevity parts (MT42):
<http://www.micron.com/support/plp.html>
which are SLC chips 1.8V 1-4Gb

Complementary there is what is so called "Automotive eMMC" which might
be interesting as well and they plan to start production on those
parts 3Q2011, but again those are not in the longevity program (PLP)
yet. Q: Would it be interesting to fit both technologies down, then we
mount whatever we are more interested on?

> 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.


Bike shedding still open topic?

> 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?


Spartan-6 now in production, it is probably no problem to get those
parts, do we still want highest in line supported freely by ISE
webpack?

Extra, miscellanea and curiosities:
 * TI OMAP3
    Parts can be shipped with or without GPU, do we want it? (it is
just $3 difference) I would say we should go for it.


 * Display
    Might we want a TFT panel, LCD or some short of display for a
breakout or main board, so I could start having a look to components
availability.


 * eUSB memory in the pipeline
    USB memory that one can solder into the PCB, it sounds very wrong
technology for low power concerns and it is still too experimental.


 * Cortex-M Microcontrollers
    Freescale has its Kinetis (Cortex-M4) line which they release a
free of charge and licensing RTOS, MQX, which makes life easier as it
provides TCPIP stack, USB drivers, CAN libraries, etc... the pity is
that is mainly works with CodeWarrior tools which about £3000 for
licensing. They have a Tower Development Kit, where they have
backplane boards on the sides connecting main board with edge
connectors and easily extendable by adding breakout boards on the rest
of slots. It might be worth to play with that technology.
    ST was also there an they have the STM32 (Cortex-M3) line of
products which are also nice components and could be used as a
replacement for the TI PMIC.


So, if more or less all this is fine with you I'll start sampling
and trying to get parts for revision 1, which quantity do we need for
rev1 and do the hardware bring-up part? At least 10 boards? 5 with
FPGA/ 5 without it? Sounds about fine? Once I know part numbers I'll
let you know. I guess we are fine on the commercial grade.

Lead times varies between 6-8 weeks to 20 weeks (on some TI OMAP
components), so we should be starting the sampling process right away.

On best effort terms and highly optimistic approach Nick Bane was
wanting to take with him a board to DebConf, which it is last week of
July, could we try to meet this deadline, please? :-)

Let me know if you want further information or if I am missing something.

Cheers,
--
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

<free spam>
-- Would you like to make a donation for Debian Conference?
   ** http://debconf11.debconf.org/payments.xhtml **
</free spam>