Thanks!  I'll save any more for Tuesday!

On Mon, Aug 30, 2010 at 9:34 PM, <> wrote:

> (2010.08.30)
> > 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 mailing list

Reply via email to