Re: NAND technical review

Jonathan Larmour wrote:
[snip]
>> We also prefer R's model of course because we started with R's model 
>> and use it now.
> 
> You haven't done any profiling by any luck have you? Or code size 
> analysis? Although I haven't got into the detail of R's version yet 
> (since I was starting with dissecting E's), both the footprint and the 
> cumulative function call and indirection time overhead are concerns of 
> mine.

In a first step in mitigating the 'footprint pressure', I have added CDL 
options to configure in/out support for the various chips types, to wit: 
- ONFI chips;
- 'regular' large-page chips;
- 'regular' small-page chips.
It is in r678 on my download page 
(http://www.cs.vu.nl/~rutger/software/ecos/nand-flash/). As I had 
suggested before, this was a very small refactoring (although code has 
moved about in io_nand_chip.c to save on the number of #ifdefs).

One more candidate for a reduce in code footprint: I can add a CDL 
option to configure out support for heterogeneous controllers/chips. The 
ANC layer will become paper-thin then. If this change will make any 
difference, I will do it within, say, a week's time.

As regards the concerns for (indirect) function call overhead: my 
intuition is that the NAND operations themselves (page read, page write, 
block erase) will dominate. It takes 200..500us only to transfer a page 
over the data bus to the NAND chip; one recent data sheet mentions 
program time 200us, erase time 1.5ms. I think only a very slow CPU would 
show the overhead of less than 10 indirect function calls.

Rutger