[OLPC-devel] Re: Software action items and status

[David Woodhouse]

On Fri, 2006-06-09 at 14:51 +0100, David Woodhouse wrote:
> 4). Our own CPLD/FPGA
> 5). Our own ASIC
> 
>     I'll bundle these together since I'm not in a position to make a
>     distinction between the two. That's about the up-front costs vs. 
>     the per-unit costs, and the scheduling (and testing) constraints.
>     The technical issues from my PoV are very similar.
> 
>     Basically, the idea is that we attach our own NAND flash
>     controller to replace the one in the CS5536. It's relatively
>     simple -- just a FIFO and some Reed-Solomon ECC calculation.
>     Thomas has a working implementation of this in a CPLD which 
>     is freely licensed, and would just need adapting to interface
>     to our board. Getting it all working in a CPLD and then transferring
>     that to an ASIC should be relatively low-risk.
> 
>     We ought to be able to get _very_ close to the full 26MiB/s read
>     speed of the chip (and also to its write speed) by doing this, and
>     I think it's the option that I'd prefer; cost permitting.
> 
>     One question which I hope the AMD guys can help us with is _how_
>     we interface to the CPU. Do we do it as a PCI device? A GeodeLink
>     device? Something else?
> 
>     One possibility is that we could follow on from Tom's idea of
>     abusing IDE. Except that with our own CPLD/FPGA/ASIC the whole thing
>     is far less Heath Robinson; we can have proper 16-bit transfers, we
>     can still have hardware ECC, etc. One advantage of this is that the
>     OLPC board is already laid out to allow a chip to sit between the
>     IDE interface and the NAND chip. We can even do UDMA -- Thomas says
>     that "it should be no big deal to hack the VHDL glue for that".

Followup from IRC conversation on this topic, for the record...

GeodeLink isn't possible; it's basically PCI or IDE. Pros and cons of
each...

PCI needs more pins.

PCI would mean a more intrusive board rework; there's already a set of
pads for a chip which connects to both the IDE port and the NAND flash,
and we can bypass the existing connection to the NAND flash to use that.

PCI (with burst reads) would be more complex, although not necessarily
_harder_, since it's a fairly standard interface. More gates though,
probably.

IDE would need to work around assumptions made by the CS5536 IDE
controller about what happens on the bus -- it may snoop the IDE bus,
and we may need to 'fake' something about normal IDE transfers in order
to use IDE bus mastering.

In that context, PCI might be easier to implement on the grounds that
it's a known standard and we don't need to know anything specific about
the CS5536 implementation.


I'm still leaning towards connecting it to the IDE bus, I think. If we
could get some feedback from AMD silicon folks on precisely what form
their 'IDE snooping' takes, and what we'd have to do to use MDMA and/or
UDMA for simple data transfers, that would be extremely useful.

/me wanders off to study an IDE spec...

-- 
dwmw2