NAND Flash

The system is equipped with a Micron MT29F4G08ABADAWP:D 4Gb (512M X 8) NAND Flash. This memory functions and the primary boot and program storage memory. For whatever reason Micron has the most NAND flash available on Digi-Key but none of them have a datasheet attached. The datasheet wasn’t too hard to find and ironically I found a link to it that is hosted at Digi-Key… Not sure what is going on there but either way this chip is a reasonable price, is in stock, and is listed as one of the tested compatible memories in Texas Instruments document SPRAB41F. This document is technically for the OMAPL-132 and OMAPL-138 devices. Both of these devices are pretty much equivalent to the TMS320C674x devices with an added ARM926EJ-S RISC MPU core added. In fact I am sort of planning, once development is done on this first version, to use the OMAPL-138 instead of the TMS320C6748 and take advantage of the ARM core to play around with a simple Linux operating system. Both of these parts are pin for pin compatible so it shouldn’t take any major changes to the rest of the system.

The boot mode pin selection for booting from 8x data bus NAND Flash is BOOT[7:0] = 0XX0 1110

 DDR2 SDRAM

For system memory the DSP has 256 MB of SDRAM in the form of a Micron 2Gb (128M x 16) DDR2 400MHz SDRAM. The part happens to be relatively pricey at $13.69 in single quantity but it has two major things going for it. The first being that it is listed in the datasheet as a known tested compatible SDRAM chip. The second is that it has a pretty high quantity in stock on Digi-Key (around 2,500) so there is not as much risk of it being sold out by the time I am ready to build the board, unlike some of the cheaper options that only have 50 parts currently in stock.

One thing that I was worried about would be needing termination resistors as I have very little experience with them. I understand why they are used but when it comes to choosing them I have no experience with it so I would probably spend a good while trying to figure out the best way to simulate it in QUCS or LtSpice or something. So I was giddy with excitement when the datasheet said none were needed. They also give a real handy guideline for a range of values to choose form if you want to add them for a bit of EMC mitigation. I have elected to go without them to help ease the PCB routing of the DDR2 interface.

This is also my first time really using the bus feature in Diptrace and I am still not too sure how I feel about it. I will have to play around with it some more before I make a final judgement.

The TMS320C674x datasheet has a very nice section about all sorts of different routing guidelines to help me along when it comes time to layout the PCB. I have always been sort of weary of DDR interfaces because I don’t have access to any high end PCB signal integrity simulators. While they would be nice I don’t exactly have ~$10,000 laying around to drop on a new EDA package like Altium or Cadence. I have put some thought into maybe looking into OrCad since you can get a standard license for somewhere in the $3,000 range but that is still triple the price of Diptrace so it is a hard sell.

 Boot mode selection switches

The DSP defines its boot process using 8 boot pins. Below shows the boot mode depending on the BOOT[7:0] pins. The only issue with this is that all the boot pins are multiplexed with other functions. So at the positive going transition of the #RESET pin the DSP latches the values of the BOOT[7:0] pins and then gives control of the pins to other peripherals. This makes it tricky to deal with because you have to actively pull the pins high or low (the internal pullup and pulldown resistors are off until software configures them) while also making sure you aren’t messing with anything else on the buss. To add insult to injury the peripherals that are on these pins happen to be some of the higher speed ones I intend to use, namely the LCD interface and the Universal Parallel Port.

I am still unsure which one of these I want to use, since I would like LCD and VGA video outputs for a sort of off pc basic HMI, but at the same time I would also really like to use the Universal Parallel Port to connect with the FPGA. Maybe I will use the parallel port and just use the FPGA as a display controller as well. Either way I digress, the point is that at the moment of doing this I am not sure how the added resistors will effect anything else later on. Because of this I have elected to use the SN74CBTLV3245A Octal FET Bus switch.

With this set up I can just switch the resistors in and out as need be. There is two ways this happens, automatically and manually. The automatic method uses the RC network consisting of R34 and C134 to add some delay to the #RESET signal. The datasheet for the SN74CBTLV3245A states the high level input voltage to be 2V minimum. The time constant for the RC network (TC=R*C) comes out to be just a smidge over 1ms and that puts us right around 2V on the #OE pin. At the same time the 4.7KΩ input shouldn’t draw enough current (~700µA) to upset any other reset circuitry. I also intend to connect up a GPIO pin to the #OE pin once I know which GPIO pins I have available. That way I can have software disable it when the boot process is done.

One last thing to note is that the DIP switch only has 5 positions connecting to BOOT[4:0]. I did this mainly to try to shave off the slight cost of a larger switch and added resistors since all of the boot modes have BOOT[7:5] as either 0 or do not care. There is some uses where these pins control special things like special PLL configurations and whatnot but none of them are anything I plan on using.