Footprints
Component Centers
Where they belong
Is it the same for everyone, or stored locally by user?
Define a width and length for crosshairs
Courtyards
Can silkscreen be outside the courtyard?
Set specific courtyard distance from component outline
Set specific widths for courtyard + component outline
Silkscreen/Top Overlay
General guidelines for silkscreen markings
Pin 1 dot - define radius, thickness, min distance from pads
Assembly
Would be good to articulate exactly what things are permitted here (some components have boxes/other markings in addition to the 3D model
Pads
Establish annular ring convention?
Should we include tolerance data?
Component Outline
Make sure it’s clear that the outline doesn’t include the legs of the component
Currently (to my knowledge) there’s no requirement or procedure to verify the validity of a 3D model of a component downloaded from online. It seems odd to base our component outline off of this without first verifying the 3D model dimensions, since this can in turn affect courtyard and component spacing
How should we handle components which say they’re (for instance) 8-SOIC, but recommend a footprint that’s different from and not encompassed by the existing 8-SOIC footprint?
Proper procedure if you can’t find a good 3D model online
Guide on how to import footprints from Ultra Librarian/snapEDA/etc.
Should define a consistent orientation for footprints (i.e. connectors should face upwards, SOIC packages should have pin 1 at the top left)
Symbols
define standard convention for Mechanical pin designators (M? vs. MNT? or similar)
Remove Mounting and fiducials and such from BOM
Component Parameters
Case/Package vs. Package parameters?
Using typical vs min/max columns. Using recommended maximum vs absolute maximum
Would be good to add a description to Voltage Rating on connectors to specificy AC or DC
It seems like the auto-generated description is nearly always wrong on components, even when part choices is correct. We might want to standardize using the “Detailed Description” from Digikey instead
Do we have a standard for what to do if it lists multiple packages?
We generally need to figure out an approach to how to handle the Package/Case parameter of ICs. Right now we’re using the Package/Case parameter on Digikey, which seems to list standard packages which may be compatible with the supplier device package. But it’s unclear where they derive this from, and whether its trustworthy. Suppliers will also often have their own Supplier Device Package which may differ from standard footprints listed under Package/Case. Example: MAX16998AAUA+
Potential solution: we could just say make the Package/Case field match the footprint we use. And that when picking a footprint, you should exhaust all standard packages listed in Package / Case before using a supplier device package footprint.
Component Revision
Component States
Proper procedure if you review a component then catch an issue
If “In production” part has a minor issue, do you bother tweaking it? And if so, do you return it to “in production” or just make it “Reviewed”?
If this happens, and a new “reviewed” revision is created, do you have to roll back all prior approved revisions to drafts?
Schematic Guidelines
Should we eliminate the units (ohms, Farads) from passives, since its assumed? (i.e. 100n instead of 100nF)
Should we go to a standard of using net labels like “3V3” instead of “3.3V” for improved readability?
Similarly, we could do “4k7” instead of “4.7kOhms”
Should we define standards for use of hierarchical vs. more flat schematic organization?
Setting a max of 3 wires per node to improve readability
Layout Guidelines
Need to emphasize somewhere that component layer pairs should get added to the PCB file as well
Need to emphasize that standard design rules must be added
Design Rules
Design Reviews
Need to have all DRC errors resolved before PCB review