Following my last post, I’ve updated the board layout to correct the mistakes of my previous work. Let’s start with the board renders from OSH Park.

While the layout is quite different from the previous version, the schematic is quite similar. I’ll talk through the changes in this version and the method that I used to build this layout.

Start with, why?

(credit Simon Sinek for the title)

The premise of the new board is simplification and moving the complexity into software. This not only reduces the cost and build effort, but also is reconfigurable. The replacement of the FT2232 with an Atmel microcontroller will allow some sophisticated interfacing with a host computer for configuration, and reprogrammability. We can do smart things like take an over the air update and and present the microcontroller as a composite device, being a config port, a TTY serial port and if worthwhile, a small read-only USB drive for the TTY drivers.

The microcontroller will program the FPGA through it’s 8-bit passive parallel port, drawing the bitstream from the flash memory chip. Atmel has an amazingly sophisticated software framework for handling both USB and Flash media and I intend to use this to manage the interface with the storage. Incidentally, the Atmel Software Framework (ASF) is the reason that I switched from Microchip to Atmel as I spent literally months trying to make their USB software stack work for a composite device and failed. Within an hour of trying the Atmel ASF stack, I had a working composite device. Despite being a Microchip customer for over 20 years, (PIC16f628 anyone?) and a change of vendor means a lot of relearning, Atmel software solutions won my loyalty and I won’t be changing back. I guess it’s no longer about the hardware – maybe a lesson there? Anyway, I’m getting off topic.

The final connections between the microcontroller (MCU) and FPGA are the SPI connection. This will handle two way communication between the two chips. It can run at up to 40MHz in DMA mode, so the OS will be able to offload the moving of data between the chips off the CPU to the DMA handler. This will allow the FPGA to make requests of the MCU for things like data storage and the MCU respond with packets of data, such as when the CPC requests a disk sector to be read or written. This also isolates and protects the storage from accidental erasure or corruption as the FPGA image is likely to change frequently while I’m developing it and I don’t want to keep reflashing the images if I break something as this will reduce the life of the flash storage.

So that’s the principal behind switching the FT2232H for the Atmel MCU. The first thing I did was scrap the old PCB layout (after archiving of course!). Then I updated the schematics to remove all non-essential components such as the pull up/down resistors on the FPGA JTAG lines.

My rationale is this: the only line that is sensitive to float prior to these lines being driven is the clock line, so only this line needs a clamping resistor. The advantage of clamping resistors on the other lines is lower noise and lower power use because floating lines can cause the chip functions to oscillate between high and low state and use up power. The time these lines will be unconfigured is milliseconds as the microcontroller will start up and hold these lines to their inactive state. These components only make the build harder to assemble and don’t add to the functionality.

In addition, the replacement of the FT2232 with the Microcontroller allows each IO line to be clamped high or low according to it’s programming, so pull up resistors are not needed on these lines. Compare the nConfig, Conf_Done and nStatus lines between the old and the new schematic for an example of this.

The power supply requirements of the microcontroller are much simpler than the FT2232, requiring just an inductor and couple of capacitors, so this simplifies the build again. All of this simplification should make the board a little easier to put together.

Note that I also omitted the ESD protection for the HDMI outputs. This is probably not a great idea, but both the placement and routing of these tiny ESD protection diodes was a major issue in the previous build. I found an integrated chip on Mouser that would do the same job, but be much easier to incorporate as it’s a single ‘place’ rather than 12 or 13 discrete devices. This chip also handles back current and signal conditioning so I might include this on the next version if the ADV7513 chip becomes unreliable in use.

Approach and method

Starting this build, I wanted to avoid the big-mess-of-wires that I had in my last layout, so I built the schematic and the PCB layout at the same time. The idea behind this is I would pick pins on the FPGA that were easy to route based on it’s proximity and “ordering” to the source pins. The FPGA doesn’t have fixed functions on it’s IO pins (generally) so I can pick pins that are easiest to get to. Unfortunately, I can’t know this in advance so I have to build the schematic and PCB at the same time. I also lay out the board starting with the high speed components first so their routing is simple. Lower speed devices are not so sensitive to track placement and vias, so we’ll try to route all high speed lines on their originating layer.

First up I lay out the Atmel SAM4SD32CA as I’ve used this chip in previous successful projects and I can reuse the schematic to ensure I don’t make a mistake. This goes onto the board first and is routed for power. The flash memory is next, as this is fairly high speed and required the minimum of vias and sub-plane routing, so I give it priority by placing and routing next.  Next comes the USB and clock connections as the USB port needs to sit at the edge of the board. Finally I place and route the MRAM below the MCU and this gives me my board width. Width is 37.7mm and seems to fit with the idea of a ‘key-fob’ shape. I finish routing the power and regulators on the left side of the board. At this point if the board was manufactured and assembled, the MCU would run and I could build the software to manage the interface to the Flash memory. However, I press on.

Next I place the FPGA in the vertical center of the board about 5mm from the MCU, giving me room to route the MCU-FPGA connections in this space. I route the ground and power for the FPGA so that I know where the boundaries are and where I need to use vias. I then place the SDRAM in the bottom right of the FPGA, intending to run all lines on the top layer to accommodate the high speed. The left side of the SDRAM is routed to the bottom outer two rows of pins and the right side of the SDRAM to the right side of the FPGA. All lines were routed without needing vias except for the GND and 3.3v lines. Unfortunately, it took up a fair bit of real estate, but it was worth it for clean routing of these high speed lines.

Next I’m routing the lines for the video output as these will be high speed, up to 148.5MHz for 1080p. It’s a little harder to route these all on the same layer, so I’ve had to split these across two layers. about half are routed on the top layer, consuming the easy to reach pins, the rest need to go deeper into the ball array, so I place these according to ease of reach. The inner pins on the BGA must be accessed by via because it’s not possible to route more than one signal between the balls. For this reason, it’s normal to route on another layer. Once the high speed lines are routed, we can route the lower speed lines for this device and some of these go across more than 2 layers to avoid crossing the high speed lines. You’ll note that for the first few main parts, we’ve only really used 2 layers which is great for simplicity and signal integrity. This leaves the other layers for lower speed lines where the signal path is not so critical. You might notice a couple of wiggles in the signal lines for the 1.6GHz HDMI video. This is to ensure all the signal traces are the same length. At 1.6GHz the wavelength is 18.75cm, which means that in a track of 18.75cm in length, the signal will only just propagate to the end before the next transition happens. If the difference in track length is 18.75cm (unlikely, but an illustration) then there could be an entire bit width difference between one trace and the next. This would obviously be bad and cause data corruption in the TMDS transmission.

Once I’ve routed the high speed signal lines for the video, I’ve place and routed all of the power lines for the video also, including the 1.8v regulator. Finally the USB interface chip is placed. USB2 full speed only runs at 12 MHz, so is not sensitive to placement or routing. After some reading since I finished the board layout, I decided that this chip probably wasn’t necessary. The differential buffers in the FPGA would probably be able to handle the 12MHz full speed USB but it’s done now, so I’ll go with this set-up.

There’s a few components on the bottom of the board, mainly optional components and test points. Unlike the previous FT2232 version, this version won’t be able to program the FPGA out of the box with standard utilities such as URJTAG, so on the bottom layer the JTAG connections are very important to test the FPGA configuration before the microcontroller software is ready.

Also on the bottom is the programming point for the Atmel microcontroller. This is useful for development but won’t be needed for normal operation as the initial program can be sent over the USB port for an unprogrammed part. If re-programming is needed without an Atmel programmer, then shorting the ERASE and ERASE_G pins will wipe the device and allow reprogramming through the USB using the Atmel USB programmer software.

Also on the bottom is a TX/RX pair for the microcontroller. I don’t have any plans for these, but they don’t occupy any real space and don’t require assembly, and it may be useful during debugging, so it’s a no-cost inclusion.

Fixing mistakes of the past

I also created a special paste mask with enlarged openings for the small pitch memory and Flash devices. This should fix the main issue I had with the last assembly and that was getting the solder paste on the 0.4mm pads through a 0.3mm aperture in the stainless steel paste mask. As I’ve said before solder paste is essential to the process and lack of paste on the pads was the cause of the short in the last attempt.

The board ended up with a slightly smaller area at 88.9mm X 37.7mm, due to the simpler track layout but slightly longer. It fits the outline that I am looking for in the specification, being a ‘key fob’ size (if you have large keys). The only way to make this smaller is to create two sided boards, and I’ve done this before, but the second side must be hand assembled rather than using the IR oven, and this makes the process a little less reliable. Components on the top side only is much easier to handle.

Belatedly I noticed a couple of issues, such as a lack of V3P3 test point on the bottom for the FPGA JTAG programmer and I forgot the legend referencing this blog! Anyway, there will be later versions that I’ll be able to correct these issues. Nothing earth shattering.

What’s next?

I sent the board away a week ago and it’s been manufactured and is on it’s way back to me. I have a new plan for assembly that will hopefully will avoid the issues I’ve seen previously. I’ll go into that next time.