Instructions for transforming Openmoko's GTA02-MB-A6 PCB design into
the GSM development board (FCDEV3B) desired by the FreeCalypso project

0. Background

In the late 2000s a company called Openmoko produced two smartphone models
called GTA01 and GTA02.  The motherboard of each of these devices consisted of
two major sections: an application processor (AP) subsystem intended for
running Linux, and a GSM modem block based on the Calypso chipset from TI.
Openmoko's PCB design was done in PADS, and we have the original PADS PCB file
for GTA02-MB-A6, one of the last PCB revisions produced by Openmoko.

The FreeCalypso project seeks to produce a Calypso GSM development board whose
core will be a direct reuse of Openmoko's Calypso GSM modem at the physical PCB
design level.  The idea is to create our FCDEV3B PCB design from Openmoko's
GTA02-MB-A6 by loading the latter into PADS, removing all components outside of
the modem section we wish to copy, adding the new components needed for FCDEV3B,
and routing the new net connections between the retained modem core and the new
peripheral components.

1. Netlist and ECO

We do not have graphical schematics for our desired FCDEV3B board; instead the
"schematic" design of this board was done in a text-based design entry language
based on the structural subset of Verilog.  The output of our non-graphical
"schematic" design tool is a netlist that can be loaded into PADS to start a
new board design.

However, in the present case the objective is not to start a new PCB design
from scratch, but to make verbatim reuse of a quite complex section from a
previous design at the physical layout level.  Loading an entirely new netlist
into PADS atop of an existing board would not produce good results; instead
what is needed is an ECO file that instructs PADS to delete some components and
nets from the old PCB, rename the retained ones to fit the refdes numbering and
net naming scheme of the new design, add the new components needed for the new
design which don't originate from the old one, and make some new netlist
connections.

Through some crafty work in our text-based Unix/Linux environment, we have
successfully constructed an ECO file for PADS import that does exactly what we
sought.  After loading this ECO file into PADS atop of the GTA02-MB-A6 PCB from
Openmoko, we get a board that still has the outline from GTA02 (to be changed),
has all of the modem core components and their physical layout and routing
retained (but renamed to our preferred refdes numbering scheme), has all of the
unwanted components removed, and has the new components as not-yet-placed parts,
as well as a bunch of new netlist connections in need of routing.

Now we need a PADS-experienced PCB design engineer to finish our FCDEV3B layout:

* Change the board outline from Openmoko's complex shape to simple rectangular;
* Place the new components;
* Route the new net connections.

1.1. Libraries for netlist/ECO import

Of the new parts which are being added to the board by our ECO, some have the
same PADS part types as some pre-existing parts from GTA02, hence their addition
as part of ECO processing does not invoke a library search.  However, others
have new part types and part decals (footprints), hence a library with these
part types and decals is needed in order for the ECO import to succeed.

We have created such a library in PADS 9.x ASCII library format.  The library
needs to be converted from ASCII to PADS native binary before it can be used.
Instructions:

* Create a new empty library named fcdev3b;
* Import the supplied fcdev3b.d (decals) and fcdev3b.p (part types) files into
  this new library;
* Place this library at the front of the search order when importing our ECO.

Please note that this library has been created by someone who does NOT live and
breathe PADS.  If something looks wrong, please fix it.

2. Board shape and related considerations

Openmoko's GTA02-MB-A6 board has 8 layers and a complex via structure: L1-L2,
L2-L3, L3-L6, L6-L7, L7-L8.  As we seek to make direct reuse of the intricate
physical design of a GSM modem with GHz RF and tightly-squeezed digital
sections, the layer and via structure needs to be kept unchanged from
Openmoko's board.

However, the board outline shape needs to change: Openmoko's PCB was the
motherboard of a smartphone with a complex shape intended to fit into a custom-
molded plastic case, whereas our FCDEV3B will be a development board intended
to be used bare on a lab bench.  Thus our FCDEV3B does not need to fit into any
particular form factor, size or shape - totally free-form.  However, a simple
rectangular shape is desired, both for common-sense simplicity and to allow
some right-angle connectors to be placed along edges of the new outline.

2.1. Panelization

It appears that Openmoko built their GTA02-MB-A6 boards on panels with 4 PCBs
in each.  The PADS PCB design includes a drawing of this 4-board panel, with
all actual PCB layout contained within the leftmost of those 4 instances in the
panel drawing.  This whole setup will need to be removed when converting the
board outline to simple rectangular.  The PADS PCB design for FCDEV3B should
cover just a single board without any panelization: the PCB manufacturer may
use any panelization of their choosing, but I expect to receive individual
boards back from the PCB house, not panels.  The SMT reflow assembly will be
done on individual boards, not panels, as we expect to be building these boards
in extremely low volume, on the order of one board per year.

2.2. Which side is which

The design intent for FCDEV3B is to have all components mounted on one side
only.  However, to confuse matters, the side which we view as our component
side for FCDEV3B is the one that is designated as the bottom in GTA02-MB-A6,
not the one which they designated as the top.  (The side which needs to be our
single component side is the one where the modem section components reside, and
it happens to be the bottom in the GTA02 view.)

Flipping the board over so that L8 becomes L1, L7 becomes L2 and so forth, with
everything mirrored correctly, would be ideal, but I reason that attempting to
perform such a flip in PADS without ripping the to-be-retained layout to shreds
would most likely be impractical.

Therefore, the current proposed solution is as follows: place all new components
on the side which PADS sees as the bottom, remove everything from the side which
PADS sees as the top (it will be our underside in reality), and then flip the
board to the correct orientation after it has been physically made.

Note that this component placement consideration applies to both SMT and TH
parts.  (There weren't any of the latter kind in GTA02-MB-A6, but some are
added for FCDEV3B.)  Although the pins of a TH part pierce the entire layer
stack, the physical placement of the part on the side which PADS sees as the
bottom still needs to be accounted for.

2.3. Gold-plated pads

The original GTA02 board features a few exposed SMT pads with selective gold
plating, either for test points or for components which connect by pressure in
the final assembly with the plastics in place.  No such selective gold plating
is needed on our FCDEV3B.

2.4. Miscellaneous GTA02 remnants

While the ECO process removes all unwanted components and nets, some copper,
silk, soldermask and other features remain from the GTA02 after the application
of our ECO, even though they are in areas of the board far from the modem
section which we are keeping.  These remnants need to be removed.

In particular, *everything* on the side which PADS sees at the top needs to be
removed: none of the things which Openmoko put on that side are applicable to
FCDEV3B.  However, the pattern of little vias that forms the names/signatures
of the original GTA02 designers can be kept: after all, we are keeping the
complete modem section layout from their board.

3. Battery power routing

Cellphone chipsets are designed to run on battery power, and the GTA02 design
from which we are deriving our FCDEV3B was a battery-powered handheld device.
Our FCDEV3B is to have a power input connector that provides battery-emulating
power (VBAT), and this power is to be routed to various VBAT consumers via a
set of jumpers which will allow for current draw measurement.

The modem section of GTA02 has two battery power nets which are renamed to
VBAT_CORE and VBAT_PA in our post-ECO netlist; the routing of these power nets
appears to be retained after the application of our ECO.  Each of these two
VBAT branches is to be connected to VBAT_IN (the power from the connector) via
a current measurement jumper, as codified in the post-ECO netlist.

Power input connector J305 needs to be placed along one of the edges of the
FCDEV3B board outline - doesn't matter exactly where, as we are not seeking to
fit into any prescribed form factor.  The big capacitor C323 should be placed
somewhere close to where VBAT_IN will turn into VBAT_CORE and VBAT_PA via JP2
and JP3.

4. GSM antenna connection

The GSM antenna connection originates from U401 pin 9 and passes through series
capacitor C401.  On the GTA02 it then goes to an MS-147 RF test connector/switch
and then to a gold-plated pad to which that device's internal antenna connects
by pressure.  This arrangement is only suitable for a board which is intended
to go into a plastic case, and not for a development board like ours which is
to be used bare on a lab bench.  Therefore, the GSM antenna connection
arrangement from GTA02 needs to be changed and replaced with an SMA connector
for external antenna or RF test station connection.

I propose that we place an SMA connector (SMT, right angle, part included in the
post-ECO netlist) along an edge of our FCDEV3B board such that a trace from its
center pin can go straight to U401.9, passing through C401 in series, all in a
straight line on the surface layer which PADS sees as the bottom but which will
be our component side.

Notice how the orientation of C401 and the trace going to it from U401.9 is
somewhat "sideways" in the original GTA02 layout - I assume that they had to do
it that way because of space constraints.  It seems to me that it would be
better to re-orient C401 and the U401.9-C401.1 trace such that the entire
connection from U401.9 to J308.1, passing through C401, will form a straight
line.

Also please note that I totally do not understand GHz RF PCB design.  The RF
section of the GTA02 layout appears to have some set of rules as to clearings
in the GND copper pour around RF traces and clearings in the GND plane
underneath them.  Because I don't understand this part myself, I need a PCB
layout person who does understand it and who can make the right decisions as to
how these features should be adjusted for the modified GSM antenna connection
arrangement.

5. Peripheral interfaces

The new circuit blocks being added to the modem core reused from GTA02 with our
netlist ECO are based on the schematics we found for TI's Leonardo reference
board:

ftp://ftp.freecalypso.org/pub/GSM/Calypso/Leonardo_rev05.dsn
ftp://ftp.freecalypso.org/pub/GSM/Calypso/Leonardo_rev05.pdf

In a way, our FCDEV3B board as a whole can be seen as a re-creation of TI's
Leonardo: the modem core section which we are reusing from Openmoko's GTA02 was
originally based on the very same Leonardo.  (Openmoko renumbered the reference
designators from Leonardo's scheme to their own, but our ECO renumbers them
back to Leonardo ones.)

Out of the 5 pages of Leonardo schematics, pages 1 and 5 are mostly decorative,
while pages 2 and 4 capture the modem core which we are reusing from Openmoko's
GTA02 at the physical rather than schematic level.  Thus the Leonardo schematic
page of remaining interest is page 3, which depicts the peripheral interfaces.
None of these peripheral interface circuits are present on the GTA02 board; our
FCDEV3B re-adds some of them, but not all.  Those peripheral interfaces which
we are re-adding with our netlist ECO and which need new layout follow this
Leonardo schematic page 3, so you should refer to that schematic drawing
whenever you need to understand what it is you are laying out.

5.1. UART interfaces

The Leonardo schematics show each of the two Calypso UARTs being brought out on
a 6-position modular jack connector, without any level shifters.  We shall use
a 10-pin (5x2) header instead, with the pinout chosen such that one can connect
to either UART individually by inserting a 5x1-mating cable on either side of
the 5x2 header, or connect to both UARTs with a single cable.  We don't
implement level shifters either, but we do add pull-up and pull-down resistors
which don't appear on Leonardo schematics.

5.2. JTAG interface

Our JTAG interface will be exactly the same as depicted on Leonardo schematic
page 3, with the following two corrections:

* TDO pull-up removed: it's an output from the chip on the board;
* nEMU0 and nEMU1 connections for TI's DSP inside the Calypso added following
  other TI development board designs.

5.3. MCSI interface

Leonardo schematics show the MCSI signals going to test points.  We shall bring
them out on a header instead.  We also add pull-down resistors on input signals.

5.4. Loudspeaker block

Our loudspeaker circuit is a slightly simplified version of the one depicted
on Leonardo schematic page 3.  The simplification is that we connect only to
EARP & EARN and not to AUXOP & AUXON.  The datasheet for the TPA6203A1 audio
amplifier provides some guidance for PCB layout around this chip:

ftp://ftp.freecalypso.org/pub/GSM/part_datasheets/tpa6203a1.pdf

The stipulation stated on the Leonardo schematics with regard to this circuit
block ("Components inside this box MUST be placed inside shieldcan") can
probably be ignored for this FCDEV3B experimental board.  There probably isn't
any spare room inside SH1 where this circuit could be squeezed, but it may make
sense to lay these components out in their own section, enclosed in a footprint
for a separate potential shieldcan.

Our board will provide a header for the loudspeaker connection instead of
putting the loudspeaker part itself directly on the PCB.  This way the choice
of specific loudspeaker part does not have to be made upfront.  (The DTR256
loudspeaker part shown on the Leonardo schematics appears to be forgotten
history: neither parts nor a datasheet could be found.)  The area of the board
where this connector is placed should provide some free space where a
cellphone-sized loudspeaker could be attached with double sticky tape or
similar ad hoc means.

5.5. Microphone block

The microphone circuit on FCDEV3B follows Leonardo schematics verbatim.
However, the actual microphone part once again has been replaced with a header.
Electret condenser microphones generally cannot be mounted directly onto a PCB
because they can't withstand the heat of reflow soldering; the few SMT ECM parts
that used to exist in the past seem to be no longer available.  Hence the plan
is to put the actual microphone on a very short pair of wires going to a little
connector that will mate with the 2-pin header on the board.

5.6. Microphone and loudspeaker placement

The microphone and loudspeaker circuits should be placed a reasonable distance
apart to reduce the acoustic echo during voice call tests.  One suggested
arrangement is to place the microphone circuit on the side of the board near
U202 (doing so will also make the connecting traces short) and to place the
entire loudspeaker circuit (including U302) on the far end of the board.

6. Fixes in the modem core section

Although the modem core section (everything contained within the SH1 metal
shieldcan footprint) is to be retained verbatim from GTA02-MB-A6 for the most
part, there are a few minor changes which need to be made within this section.

6.1. Routing of the V-DBB power net

Look on the bottom of Leonardo schematic page 2.  Note the two "star connection"
points labeled HST201 and HST202.  They were originally intended to be star
connection points in the PCB layout, but Openmoko replaced them with physical
0R resistors/jumpers at reference designators R1003 and R1004.  This change
turns out to have been a bad idea (contributes to the infamous bug #1024), and
we would like to revert it on our FCDEV3B.

Look at the traces that run from C214 (former C1009) through R1003 & R1004 to
the consumers of the two branches of this V-DBB power net.  My proposal is to
remove the R1003 & R1004 components/footprints and to connect the traces
straight through where their 0402 pads used to be.  The star topology should be
retained, so that the two branches of the V-DBB net join only at the C214.1 pad.

Our current ECO does not delete R1003 & R1004 components, as doing so would
cause PADS to rip up the traces going to them, the traces I propose to join.
However, the ECO does contain an instruction to join the 3 formerly separate
nets, so post-ECO PADS sees one net named V-DBB that spans C214.1, both ends of
both R1003 and R1004, and all of the V-DBB power consumers.  One possible way
to fix the layout would be as follows:

* Connect a trace across R1003 and another across R1004, so the connection will
  be there even with no 0Rs populated - this trace connection should not be
  flagged as an error because the points in question are all in the same net
  in the post-ECO netlist;

* After the traces connect all the way through, remove R1003 & R1004 so there
  are no unwanted solder mask or paste stencil openings in that spot.

6.2. 2nd flash bank chip select

The GTA02 modem section includes a trace that connects U301.F9 to U201.C11.
(Leonardified refdes numbering scheme.)  On our FCDEV3B we would like to have
this U301.F9 chip select connected to C201.C1 instead.  The old U301.F9-U201.C11
trace is ripped up by the ECO, and the post-ECO netlist has U301.F9-U201.C1 as
a new connection in need of routing.

6.3. Grounding unused Calypso inputs

Unused Calypso inputs RXIR_IRDA (U201.A8) and DSR_MODEM/LPG (U201.D9) are
unconnected on the GTA02.  On our FCDEV3B we would like to ground them instead.
The post-ECO netlist includes these GND connections; I assume routing them
should be trivial.

6.4. Test points

I would like to add test points to these two critical internal signals which
run from one BGA chip to another:

CLK32K_OUT
NRESPWON

Both signals are in the modem core section and come unchanged from GTA02.  I
leave the location and shape of the test points to the discretion of the PCB
layout engineer.  Placing them on the side opposite from the components (i.e.,
the otherwise unused side which PADS sees as the top) would be fine.
