3
\$\begingroup\$

I'd like to continue this conversation here: CAD Schematic pin arrangement approach

Basically, there are 2 major ways to do schematic symbols, either with true pin order or by grouping pins by their functions. More people seem to advocate functional groupings over true pin order because of the clarity it can give your schematic.

The first PCB I did a few years back I used functional groupings on the schematic, then when I switched over to do the PCB, the number of crossings and vias made it a complete mess. Since then I've made every single schematic symbol true pin order, then focused on making sure as few lines on the schematic cross, meaning minimizing the crossings on the PCB. This has produced very clean and efficient boards, however, I don't think my method will scale well when doing very large boards.

For those of you that use functional pin groupings, how the hell can you produce an efficient PCB without too many crossings or vias? For instance, PORTB on an ATmega could be spread out on all 4 sides of the IC. If you group them together as a functional block you may assign them to one device then have an absolute nightmare when you switch over to do the routing. This easily could've been avoided if you noticed: "Hey, PB0, PD7 and PD6 are all right next to each other, maybe that'd be the better choice."

So I'm not trying to convince anyone of anything, I just recognize that the more professional route is functional pin groupings, but I simply don't know how to translate that to an efficient PCB.

I've included one of my schematics as an example of how I do it. This board was 1 square centimeter and so every single via was major real estate.

Thanks in advance.

enter image description here

\$\endgroup\$
2
  • 1
    \$\begingroup\$ FYI, the purpose of this site is not to hold conversations. It is to get answers to specific questions. \$\endgroup\$
    – The Photon
    Dec 22, 2014 at 17:30
  • \$\begingroup\$ You answered your own question. Since the parts don't change, if you are able to minimize crossings on your schematic, you can also do it on the PCB layout. \$\endgroup\$ Dec 22, 2014 at 22:20

5 Answers 5

6
\$\begingroup\$

This is a great example of why the same engineer that designed the circuit should do the layout and routing. The schematic is for communicating the circuit, so pins should definitely be arranged functionally without regard to physical pin order. This is much better for most uses of the schematic.

However, layout and routing is not one of those uses. The solution is to see this as part of the layout and routing problem, not something to be pushed back on the schematic. Most of the time, pins of a port of a microcontroller for example, are near each other. But sometimes not. You have to look at the ratsnest when doing layout, and see if there might be ways to simplify that without impacting the circuit. Yes, you might end up going back and forth between the schematic and the layout, and moving nets around between pins.

Fortunately, this sounds like a bigger deal that it really is. Most of the time, arbitrary connections can be accomodated well enough. Sometimes you have a really tight board with few layers that is really cost-sensitive. In that case, you spend the extra engineering effort to swap things around to simplify the board. Again, that's the unusual case. Most products aren't high enough volume to justify this level of optimization during engineering.

Added

I should have mentioned this earlier, but for dense designs I take some care assigning pins up front. I recently put a 64 pin microcontroller on a 4-layer board. With so many connections in a tight space, routing within a inch or so of the chip is a serious issue. It's easy for signals to get blocked in, requiring significant re-routing of other signals.

What I did was print out the pinout diagram from the datasheet as large as possible. Then I wrote labels around the chip indicating in what directions the various other subsystems would be on the board. For example "EEPROM" at top right, display processor at top left, service port at lower, left, etc. I also created a list of all I/O signals required by each block.

To assign pins, I first crossed off those that had to be fixed. Some of the subsystem positions were suggested by the fixed pin assignments. Yes, this is a iterative process. Once that was all set, I started assigning nearby pins to the I/O lines of the various subsystems. You want to do this in pencil since this is also somewhat iterative. For example, you may find that you should have started assigning the UART pins more to the left, since other things have higher demand to the right and you are running out of pins there.

For a micro this complicated, I dedicate a whole sheet just for the immediate connections of the micro. This shows the power, ground, bypass caps, crystal, programming header, and the like. The I/O connections are just named lines that go to other pages in the schematic. This page is labeled something like "Main controller". The next page perhaps "Main controller peripherals", which shows the things connected to I/O lines that don't need to go anywhere else in the schematic. Examples might be the external EEPROM, the status LED, a relay with contacts brought out to a customer connector, etc.

Note that the above method requires some idea of the layout before assigning pins. Again, this is a iterative process. In this case, I left the flexible I/O signals unconnected to the processor when starting layout. I chose locations for subsystems according to where they connected to the external world, where they would be out of the way when their location didn't matter, etc. The processor was then oriented based on where the fixed things around it, like the crystal and load caps, could fit best. That's when the process described above was started.

This was a rather extreme case. Most of the time I don't need to be this deliberate about assigning I/O pins. For smaller processors where there is less routing congestion, I usually just assign pins in the schematic, then deal with it in the layout. That may mean a few extra vias, but for many boards that's not a big deal.

\$\endgroup\$
2
  • \$\begingroup\$ I'll trust your experience then. I need to just make the switch to functional pin groupings and deal with the possible headache of having to rearrange and optimize things in the layout phase. Thanks a lot. \$\endgroup\$ Dec 22, 2014 at 17:44
  • \$\begingroup\$ thanks for the update! I've since gotten a LOT of PCB experience in and I've found pretty much what you've described to be the best method. When I lay a microcontroller down I'll route all the unchangable signals first, IE: clocks, SPI, DAC, etc. while leaving all the IO undefined. At the end I'll come in and see which IO pins are left and which are in closest proximity / would require the least number of crosses. It ends up flowing very well this way! I took your advice and have since then done everything on the schematic in functional, modular blocks. Thanks again for the advice! \$\endgroup\$ Jul 24, 2016 at 14:10
4
\$\begingroup\$

For those of you that use functional pin groupings, how the hell can you produce an efficient PCB without too many crossings or vias?

One word: Iteration

After drawing up the schematic (usually in conjunction with the firmware) I forward annotate the PCB. If the routing starts to get stupid complicated for some signals I'll go back to the schematic and move the signals around to a port that is physically better situated on the chip. Then update and route more traces. Continue until either all the signals are routed or you can't find a more optimum arraignment... then you can start dropping vias.

I don't feel that physical information should be part the schematic. The schematic is what defines the electrical connectivity: I have this resistor and it's connected to the anode of this diode. How far apart they are, where they are on the board, or the orientation of the components are irrelevant to the schematic.

\$\endgroup\$
1
  • \$\begingroup\$ That's a really good explanation. Thanks a lot, buddy. \$\endgroup\$ Dec 22, 2014 at 21:27
3
\$\begingroup\$

I guess I would say that's why you should work closely with your layout people (or yourself :) So when you see in a design that you are having trouble you can go make those tradeoffs. Or if you want to go this route you can use pin swapping where you take a group of say GPIOs that you don't care which ones you use from a schematic design point of view, then give them a pin swapping attribute. In your layout tool you can then do pin swapping at the rats-nest level to make things cleaner.

When you're finished you can back annotate your netlist into your schematic to get the updated GPIO connections. That's pretty common practice I think although some people don't like it if they want a purely everything driven from the schematic process. It's also useful in routing DRAM where it's OK to swap data bits inside a byte lane for instance.

\$\endgroup\$
2
\$\begingroup\$

The general rules for schematic design apply to "typical" design scenarios.

  1. Concern for crossings really only applies to very low layer count designs. If you have enough layers to have separate horizontal and vertical routing layers, there's little added cost for crossings.

  2. Many PCB design tools allow pin-swapping during layout, with back-annotation to the schematic, if they're set up correctly.

This board was 1 square centimeter and so every single via was major real estate.

This is a scenario where doing the schematic with mechanical pin ordering might make sense. Really any circuit that fits on this board will be simple enough that reading the schematic won't be particularly difficult, even with mechanical pin ordering.

\$\endgroup\$
1
\$\begingroup\$

Old thread, but more useful wisdom...

When designing symbols, good tools let you add hints and structure that make this iteration easier. Using Eagle as an example:

Pin labels (in, out...) help keep you honest (ERC/DRC checking). Use them.

Attributes, BOM management and variations are worth exploring if you have a design that can be built in different ways or with variations in component sourcing. Think about tying into tool chains and automation (revision management, orchestrated CAM builds, parts databases,...) if you are a multi-person or multi-design shop...

Pin groupings (swaplevel...) let you reassign signals to pins and swap orientation when doing PCB layout. i.e., it doesn't matter which signal goes to what input on that AND gate, and by setting swaplevel=1 in your symbol, the person doing PCB layout can easily change things. I use this for all the pins in a MCU port group, inputs to simple logic gates, unpolarized passives and the like.

On a complex part, make the symbol(s) match the logical function of the device, not the physical pinout - which often (always?) changes depending on the packaging chosen for the component (DIP / SOIC / QFN / ...), an is worse than useless in practice.

Break up complex components into logical independent symbols. On an MCU, create a symbol for just the power and reset pins, others for clock, I2C, Ethernet, ports, etc.

This leads to the next item - use multiple schematic sheets, one for each logical grouping in your design.

Create schematic pages for power management, inputs, outputs, high speed, analog, etc.... This lets you have a schematic page just for your voltage regulation and power distribution, and is where you place those power symbols for your major ICs. You can also note constraints here for component locations and layout, referencing app notes and external docs for important stuff. Your I2C subsystem with pullups, muxes and expanders all get a space of their own for you to pass on that design knowledge that is so easily lost between the schematic designer and the layout prima-donna - even if they are both you!

Finally, use a FRAME for both your schematics AND pcb layout, and use the DOCUMENT, tDocu and bDocu layers for identification, version info, assembly and testing notations. Silkscreen goes on t/bPlace, along with (optional) Name and Values. If you choose to have a silkscreen, put as much energy in the placement of things on it as you do with those copper layers. Personally, I only put component values on my prototype silkscreens; my production boards presume automated fabrication, and only have functional user-focused info on them.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.