Since my last post, I’ve been beavering away on the SPI interface between the Atmel supervisor chip and the FPGA. The SPI interface is almost ready to share, but not quite. In the meantime, I’ll share the little side project I’ve been working on, replacing the NAND raw flash with an eMMC chip on the CPC2.0 board.

I wrote about raw flash and the challenges of writing a flash translation later in part 16 of this series. After some research, I concluded that the eMMC interface looked exactly like the much more common SDCard interface, albeit that the interface can be run with an 8-bit width. SDCards are limited to 4 bits by the physical pin count. Taking a gamble I created a board to test this new eMMC chip. I created a fake SDCard!

This fake card allowed me to check very quickly if my assumptions were correct both at a hardware and a firmware level. I wanted to be sure that it was possible to interface the eMMC via 4 bits, rather than the full 8 bits and be sure the firmware instructions were the same between these two technologies.

The Atmel SAM4S chip has a hardware interface for SDCards. If the eMMC worked with the SDCard interface, I just needed to hook up the eMMC to the Atmel SAM4S chip using the built-in HSMCI interface. I could then use the libraries provided in the Atmel Software Framework to interface to the card. No effort required and definitely no flash translation layer required!

The first challenge on this build is that the BGA pitch is 0.5mm. You’ll recall from an earlier post that screen printing the solder paste under 0.5mm is difficult. Screen printing a 0.25mm BGA pad would be nearly impossible. To work around this problem, I created a paste mask with over-size 0.45mm holes at a 0.5mm pitch. I uploaded my design and contacted OSH Stencils to check that they could produce the proposed stencil with such fine tolerances. They were both quick and polite in their reply, confirming that they could produce such a stencil in stainless steel. They could produce a stencil with just 2mil between the holes! True to their word, the stencil arrived and didn’t fall apart as soon as I looked at it, as I had feared it might with such a thin mask.

The second issue I had is that the minimum feature that OSH Park can produce is 5mil / 0.127mm and their smallest via is 18mil / 0.4572mm. This means that there isn’t enough room between the BGA pads to insert a via, so I can’t easily get the signals routed out. There is 10mil of space between the BGA pads, assuming each pad is 10mil in diameter. This isn’t enough room to fit a track plus it’s associated clearance between the pads. The clearance + track + clearance is 15mil.

Luckily many of the pads are not connected (NC), so I just cut straight across them. Have a look at the PCB layout here and you can see, for example in the bottom left corner, I cut across several NC pads to escape the traces. The red colour is the top layer and the BGA pads. The white colour is the paste mask and doesn’t form part of the circuit. Note the clearance between the white circles. Due to good design, or just good luck, the critical pads that I needed to escape, such as D0-D3, are accessible without stomping over other critical pins such as power or control. It seemed possible to create a working board.

Just for completeness, I’ve posted the schematic here, but it’s pretty straight forward. There is nothing significant to the square through holes, these were intended to be debugging points if the SDCard access didn’t work out.

The first issue I had during the build was, once again, solder paste bleed. The paste mask holes were just too big. Take a look at the paste result here. Solder paste tends to spread once it’s been deposited, and with only a 0.05mm between the paste deposits, they all bled into each other into a sticky mess. I decided to scrap the stencil and use my blob-n-scrape method of depositing the paste. This involves running the back or side of a scalpel between and along the rows and columns of the BGA, removing paste a few blobs at a time until the paste is extremely thinly spread. It really doesn’t take much paste to secure these BGAs, so thinner paste is better. Keep scraping the paste off, wiping on a paper towel until it’s not spread across pads too much. A few bridges are OK, as surface tension will pull the paste into the balls of the BGA during reflow. Lining up the chip was hard as the outline was a bit too big, and the reference points are not close enough to the chip to highlight any misalignment. I got it about right, placed the 0.1uF cap and baked the board.

I was fully expecting this build to fail as it’s really pushing the boundaries of the minimum feature size of the PCB manufacturer. To my surprise, as soon as I pushed the finished device into my multi-card reader, it was recognised by the PC.

BINGO!

I guess that answers the question of whether it will work with an SDCard interface. Yes, it will. Obviously, the 4-bit interface is not an issue here.

Interestingly, I ran some performance benchmarks to see how it performs. I’ll start by describing the later runs, as this is likely to be typical of the performance of the device once it’s been in use for a while. Here are the Linux performance test results:

What was really interesting was the first performance run. Take a look at this:

The read performance isn’t particularly notable, except for its consistency. A pretty standard 25MB/s. Remember that would be 50MB/s if it were running in native 8-bit mode. What is super interesting is the write performance. It’s a nearly uniform 22MB/s until we get 50% through the test, then it drops off to its current performance level of 8MB/s or so. My best guess is that this is the flash translation layer at work in the eMMC. Around the 50% mark, we have written 4GB of data, which is the eMMC stated capacity. At which point, the flash translation layer would need to start reusing old blocks, this requires the erasure of an unused block, a copy of blocks still in use and only then, writing the new data. One way to prove this theory is to somehow execute the TRIM command on the device for each sector and then rerun the test.

Researching this possibility, I’ve drawn a blank as the internet experts tell me that TRIM isn’t available over USB media. I’ll continue to look into this, because the write performance would really make this worthwhile, giving nearly a 3x performance boost.

Anyway, this wraps up the post for today. Here are some shots of the build and test. I’ve shared the PCB on OSH Park here if anyone wants to look at the board or even if they wanted to order one (thank you, OSH Park). The eMMC chips are available from Mouser.

Footnote: I frequently reference OSH Park and Osh Stencils because they are awesome and I want to ensure they continue to provide their excellent services to the likes of us hobbyists by keeping the work going their way. I am in no way affiliated with either organisation.

Look out for my next post, where I talk about my SPI dramas!