Saturday, 20 August 2011

Advice for PCB assembly

At work I've been developing two new PCBs. These are both eurocard size boards with a high component count and some tricksy BGA and QFN parts. For prototype builds we typically use an external company to assemble the boards. I've been through the process of getting boards assembled several times before, but this current project is by far the most complex and the assembly process has been far from straight forward.

A three working day quote turned into a six day turn-around. Consequently, I've learned a few things about how to manage this process and I want to share what I have learned.

Lesson #1 Make the assembler's life as easy as possible. If you don't, they will make your life as hard as possible. An extra couple of hours of your time spent preparing the data files will speed up the build, reduce the number of component placement mistakes and curry favour with the assembler.

Lesson #2 Supply good assembly drawings. CAD programs are really good at auto-generating this kind of output, but left unchecked they will produce accurate but unhelpful drawings. A good assembly drawing will be a PDF showing each component layer (separately) and all the component designators for that layer. If the board is very compact, enlarge the print so it is more than just a 1:1 print. Use layer colours which are easy to read and which have high contrast.

For prototype builds, it is very unlikely that an assembler will use a pick and place machine to populate the board. It just isn't worth their time. Unless you are supplying parts on reels, the time taken to re-reel components and load the machine is crazy. This means your boards will be placed by hand and so providing clear, human readable drawings is essential.

Lesson #3 Carefully prepare the components This is mainly common sense. If you are getting multiple boards assembled, keep the parts for both in separate boxes. Order spares of inexpensive components. An extra few pounds spent on passive components is preferable over having to leave them off the board or delaying the build to buy more. If you order your components from Digikey, during the checkout process you can enter the component designators corresponding to each part. These will be printed (space permitting) on the component bag label when your order is prepared. This makes it much quicker to find components.

Lesson #4 Check the BOM carefully Again, this is pretty much common sense. Make sure that any no-fit components are removed from the BOM. Failing to do this can mean the assembly is delayed while they look for the missing parts.

Lesson #5 Keep track of your changes This one really caught me out. It is common to purchase components as soon as you have the first draft of the schematic ready. This means you have time to sort out long lead time components while you are revising the design. Inevitably, changes will need to be made to the BOM after this initial order has been placed as issues are discovered during the review/layout stages. If you don't keep track of these changes and order the new parts you will have problems during assembly. One method is to compare the first BOM with the final BOM and spot the differences, but this is tedious and prone to error. It is better to generate an Engineering Change Order (ECO) for each of the changes as you make them. This can be a simple spreadsheet listing the designators affected and the nature of the change. This may sound time consuming but it will save you a lot of lost time later on.

Lesson #6 Get progress updates It is worth checking in on the assembly process every couple of days. A short phone call to check everything is going O.K. may help you spot and resolve parts queries/shortages before they add half a day's delay to your project.

Lesson #7 Remember its a prototype I think most assembly companies acknowledge that during prototype builds there will be problems with the BOM and the odd component shortage. From my experience, they are happy to put the build aside for a day while you fire off a Farnell order to get hold of the missing parts.

This may all seem pretty obvious, but in the hurry to get your prototypes made and meet your next milestone, it is easy to let some of these points slip.

Thursday, 11 August 2011

Modelsim fail

This isn't a blog post about all the things that I think are wrong with Modelsim, nor about the shortcomings of VHDL as a hardware description language. Instead it is a reminder for me (and possibly others) of what to do for when I see this Modelsim error in the future:


# Fatal error in Process line_78 at C:/.... line 82
# HDL call sequence:
# Stopped at C:/... 82 Process line__78

I wasted about 15 minutes searching the internet for typical causes of this ambiguous error message and searching line 82 for syntax mistakes. In the end I found out that in this case, the 'fatal error' was caused by trying to write a 17bit vector to a register defined as std_logic_vector(15 downto 0) and therefore only 16bits large. I cannot believe that what must be a common mistake was not picked up by the VHDL compiler (not even as a warning) and also not assigned a more descriptive error message. It was only when running the simulation that Modelsim complains.

To reiterate, the following code will generate a fatal error when you simulate it but will probably compile without generating an error:

signal bees : std_logic_vector(15 downto 0)

bees <= X"1234" & '0'; -- 16bits + 1bit = 17bits > length of 'bees'