battery life is not somthing we can really do anything about (that includes incresing AND decreasing battery life, in the end it comes down to the battery)
[div align=\"right\"][a href=\"index.php?act=findpost&pid=134960\"][{POST_SNAPBACK}][/a][/div]
Hi,
This is absolutely not the case, if you are serious about producing this then please allow me to highlight how design decisions can affect the final product. None of this is intended personally so please don't take it as such.
I have followed this thread and have quite a few qualms but I will choose 1 to illustrate. You are placing down NAND flash on the NANDFC.... why? why are you placing so much and then making it useless by crippling it to 8 bits. I know you have it in your mind that it multiplexes onto the memory bus and will slow it down.
If you have a cite for this then can you please post it. I am working from the docs on the Freescale website and it is made clear that the PCMCIA/WEIM/NANDFC share pins, but it also states that the arbiter will chuck the NANDFC off the bus at the end of the transaction if a higher priority master wishes it ( and this includes all mem busses ). This means that you will not pay the penalty that you believe.
BUT this is not the most important point. Use burst NOR instead on the WEIM bus. The NAND bus tops out at 50MHz... slow... The WEIM can clock at 133, even tho it is still multiplexed you can use this to your advantage if you are clever about it and have an external DE-MUX address munger so you can interleave the 16 bit access on the half clock, this means you can use half speed ( and therefore lower power ) devices. If you want to be really cool you can use DTACK ( anyone else remember DTACK grounded? boy that takes me back! ) mode to stretch T1 to 2T and then burst at 1T using 2T access times for the flash. This will allow for a highly optimised flash interface. Although it would be a lot simpler just to use burst or sync modes.
Now to how this will improve battery life. The nature of the system use and locality of reference means that the external bus should be inactive for a large portion of the total time. It makes sense therefore to keep this time as short as possible.... so even tho the higher clock speeds will mean that there is marginally higher power useage per beat, you are keeping total accesses shorter in time so will reap the power benefit ( slightly higher power for a shorter period is better than lower power for a longer period). Also the more efficient flash interface will give you a fighting chance of XIP which Linux is coming to terms with. This will help because the SDRAM is the real power hog in the system, so you want to keep that in low power refresh as long as possible.... so a design decision made at this stage will give you a win-win on the finished product. It will be both faster and more power efficient. In fact, loading from flash will be about 5 times faster and 3 times as power efficient.
There are a few other things that can be improved upon, such as if you want to use "standard" FR4 without impedance control etc etc then I would consider buying in an external USB phone rather than placing on board ( also writing the software will be an "impossible" task ). Don't whatever you do put down an FPGA if you want it to run from batteries. Those who would want to use it will more than likely have an external board to play with anyway. Just pinout an LVDS connector, possibly using a serialiser/deserialiser on a max clocked WEIM bus. This can interface directly to any modern FPGA anyway. Anyway, enough for now I'll carry on following the thread and heckle from the sidelines occasionally
nemuri neko
