Advertising

> (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
>