(2010.08.30) jboo...@gmail.com:
> Ok, I've looked over what I understand to be the latest GFE layout a few
> times.  This would be node5-frontend.*
> 
> Question Barrage Commencing:

Great, let's see if i still remember anything ;)


> Is there an assumed ground plane a-la "polygon", and if so, would this then
> be done as the last thing before producing the gerber and other production
> files?

So, i typed 'git pull' in my now ancient repository, and wudya know! I'm
now up-to-data :)

Looks like the g.p. is there (command 'rats;').

 
> How many layers are available?   I saw something I assumed to be a jumper to
> be soldered later, but it is in layer 15.  It appears that traces may be run
> in layers 2 and 15, in addition to 1 and 16, thus a 4 layer board.  We are
> currently using 3 layers, are 4 available?  How far should I leverage 2 and
> 15?  And what's with all the loose vias all over?  Are they tied to
> something spooky I can't see?

Hmm. Command 'drc' in the board editor, check the 'layers' tab. There
are 4 layers defined. Doesn't look like any traces are defined on the
inner layers (command 'di -1 -bot 2 15'). This is mostly intentional
where the inner layers serve as power planes. The big plane on layer 2
is called 'GND' and the big plane on layer 15 is called '3.3V_HAP_OUT'.

Putting a few traces on a power plane is often acceptable but should be
done thoughtfully wrt noise and EMI impacts.

Commands 'di -1 -2 -15 -bot; sh gnd 3.3V_HAP*", light up a lot of vias.
Perhaps these are the vias you refer to?


> Pins and Parts.  I note that many of the LPC pins are currently dangling.  I
> see that many of them lead to "con_itty_bitty_pad" things.  What's the
> scoop?  Do we want these to have leads going off to the "right hand" side of
> the board, or is there something else going on where we'll use these
> "pads"?  Also, it looks like there are some heavy traces for unmarked parts,
> or some other connection.  What's going on with these?

The 1st part of this question i actually know the answer to ;) The node
is 'generic' in the sense that it's the starting point for a "real"
node. The idea being we'd point a contributor to the generic node and
say, "Go forth and layout your application circuit toward the right-hand
side, you know, in the blank space." When the application is connected
to the generic node, only the useful signals need to be brought "across
the divide" between generic node and application. What those useful
signals are is of course application dependent.

In the old generic node, all the signals from the PIC microcontroller,
plus power traces, were routed out to the right-hand edge of the layout.
The idea being that a contributor could just delete the ones they had no
use for, and then have plenty of space to route the remaining traces
around without having to figure out how to loop everything around inside
the generic node layout.

This made a lot of sense in the old generic node because the complexity
in the frontend was pretty high, and there were noise, and robustness
issues to handle in the layout sufficient not to want the non-savvy, or
the forgetful, having to delve into the frontend. However, the PIC also
had relatively few, fairly specific, I/O pins. The LPC has many more
pins, and it's pins are a lot more generic. So i could see an argument
for routing a reasonably useful set of LPC pins out of the node-5, but
not having to route all of them.

Finally, it's useful, if possible, to bring the LPC I/O pins, even the
ones not routed to the right-hand edge, out to vias of at least 15 mil
drill diameter. That way it's easy to probe the signals and to solder a
wire in.  Just in case a previously overlooked pin suddenly becomes
important later on.

--

About the heavy traces and unmarked parts. I don't know. All the parts
should at least have internal part numbers e.g. U2201 for the LPC.
'sh *$* ?' in the schematic editor show one generically named IC and 8
generically named nets. These should be fixed.


> Design Rules.  Do we have a design rules file floating about?  Do we have
> different files for different purposes/fab options?  Where would such a
> thing live, or where would be the relevant data to correct my design rules
> file.  Also, PSAS custom parts library.  I think I saw that floating about.
> I bet I even have it.  I can't reach my personal PC just now, but can
> someone point out the filename(s)?

Hmm. Eagle design rules are conventionally '.dru'. Doing a search in my
git repo. for these only turned up one:

  lv2-fc-carrier/sunstone_4lr_rules_v1.3_modifid.dru

All board houses have their own rules. Sometimes they offer Eagle .dru
files for download. They _always_ have design rules posted on their
websites. If you don't push things too hard, it's feasible to have a
generic .dru that specifies near to the lowest common denominator, which
these days is maybe 8/8/20/50, meaning 8 mil wide traces, 8 mil wide
clearances, 20 mil minimum drill diameter, and keeping traces at least
50 mil away from the board edge. (Thats mil as in 0.001 inch.)

I suspect we have some old .dru files lying around. But really, they
probably should be updated, and consideration taken for which board
house we're really going to use. This is something we can help you with
at one of the meetings.

On my mountainous todo-list is, "Something about Eagle libraries." The
situation is not good. Our generic library is called
"psas_eagle_library", and is located in the git repo in
libraries/psas_eagle_library.scr . This is an Eagle script file. to use
it open an Eagle library editor with an empty library and use the
command 'script <path>/psas_eagle_library.scr'. the resulting library
can then be saved under the name psas_eagle_library.lbr .

Unfortunately i can see that there are about a kazillion libraries used
in the frontend. Nothing to do about that right now, but if you notice
that there is a part imported from a library you can't find, let us know
and we'll try to find the correct library and add it to the repo. (I
wonder if gEDA is ready yet...)

 
> What more does this board need?  It looks good and the parts are all there.
> I heard something about Refactoring and re"Repacking".  Is the implication
> here to condense the listed parts further to the "left hand" side of the
> board to maximize available node space?  Should I smash labels, and what
> should remain and what should not?  I'm guessing strip part labels out
> almost entirely, and replace them with Human Readable debugging info "USB
> goes here"  "Positive 5V here" "Wet Paint" "No Trespassing" etc.

Sounds right to me :)

- Make sure usable signals are routed to the application side
- Check silkscreen as you say
- 'erc' gives 25 warnings. These should be fixed
- 'drc' passes with 29 approved warnings. If you're not the one who
   approved them, it's worth a quick look to at least see what they are.
- Check that the dru that the drc is checking are actually in
   compliance with the PCB fab we will be using
- Make somebody give you a reasonable answer as to how small the frontend
   really has to be. When it's at least that small, don't try to
   condense it further.
- Find out how the board is to be mounted. This is the only real mistake
   i see in this board. My method is to figure out the mounting before
   getting very far along with the layout, and to put the mounting
   elements in first, not last. I highly recommend this method.

--
That's all i got. Questions? (I should be around Tuesday as well.)


_______________________________________________
psas-avionics mailing list
psas-avionics@lists.psas.pdx.edu
http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics

Reply via email to