How working in tandem applies to barbecues, car washing and PCB design.

Whether designing a PCB, cleaning the car or cooking a meal, we all look for ways to do things faster. Of course, at work there’s more at stake than, well, steak. Concurrent engineering introduces parallelism into our design process so that we can shorten, accelerate or recover our schedules. It permits different disciplines to have a positive impact on costs, quality and performance earlier in the design cycle – when it matters. A recent study by the Aberdeen Group found that best-in-class companies focus on improving communication and collaboration. They achieve this by working concurrently and collaborating across the extended PCB development team, and some report up to a 60% decrease in design cycle time.

Concurrent engineering is a widely used term and anyone who appreciates motherhood and apple pie will surely claim to practice it in their design process. I love my mother and enjoy apple pie as much as the next guy, but let’s get a bit more specific.

Consider two approaches to concurrent engineering:

1. A meal consisting of a salad and grilled hamburgers can be created quicker if one person makes the salad while in parallel another grills the burgers. With this approach, the time saved would be equivalent to the shortest time taken by either task. This is an example of independent concurrent engineering across disciplines: The two activities do not affect each other, but the overall schedule is shortened.
2. Two people can wash a car much faster than one person. Each person will not bother to wash what has been already washed by the other, but there will be overlap at the edges. With this approach, two people will not wash the car in half the time taken by one person, but they will definitely be much faster – say, a 40% elapsed time savings. This is an example of collaborative concurrent engineering within a discipline: Each activity is done in the context of the other and requires real-time communication in order to be optimal.

In PCB design, independent concurrent engineering is widely practiced because it can be achieved somewhat independently of a design tool’s capabilities. It is true, however, that a change or problem in one activity can affect other activities. For example, the most common form of independent concurrent engineering is schematic design in parallel with the PCB layout. A change in the schematic netlist requires an update of the PCB netlist. Communicating and managing changes between activities is critical for this approach.

Collaborative concurrent engineering in PCB design is much less common and usually enabled by tool capabilities. Historically, PCB design tools have been designed for use by a single user at a time. Innovative users have figured ways to apply concurrent engineering to single user activities. They do this by eliminating codependency in the form of a partition-and-reassemble approach.

For example, PCB layout can be partitioned into two pieces, effectively creating two new designs. Two or more designers work on them independently, and then reassemble the two designs back into the original design. Next, the boundaries of the partitions need to be cleaned, taking into account placement changes, physical connectivity and constraints. A placement change in one partition could cause a violation with the other partition’s components. Physical connectivity refers to the actual hooking up of traces that cross the boundaries. Constraint violations could occur once the partitions are reconnected, and must be dealt with.

The problems with this approach include overhead of partition and reassemble, risk of error and suboptimal use of resources. On top of this, partitioning by area is not always ideal; it may make sense to assign different nets or busses to a designer, or different layers. On top of these problems, this approach is only useful for the routing portion of the layout design.

Let’s examine how concurrent engineering can be applied in a couple of areas of PCB design, namely schematic design and PCB layout.

Schematic design is sheet-based and can be flat or hierarchical. Usually, different engineers can work on different sheets, with an agreement about the interfaces between those sheets. Mismatches between the sheets would be found through design reviews, schematic checking or, worst case, during PCB layout. Even so, mismatches in connectivity may not be found until a prototype is built. Another fly in the ointment is the increasing need to specify electrical constraints on the nets. Constraints for more than 80% of nets are quite common, hence the need to collaborate on constraint definition. There are currently different approaches to this design challenge:

• Specify the constraints in a separate specification, backed up with verbal communication, several prayers and hope the layout designer gets it right.
• Partially specify the constraints on the schematic using available but limited properties, backed up with written instructions. (Not much better than the first option.)
• Fully specify the constraints on the schematic and use these constraints to drive PCB layout.

This is where concurrent engineering is enabled by the tool’s capabilities. For starters, not all schematic design tools have a constraint management system. Of those that do, most enforce a serial approach such that only one person can edit constraints at any time. This restriction arises from the fact that constraints go across the design and so are held in a single database accessible by one person at a time (back to that single-user architecture discussed earlier).

PCB layout is a tougher nut to crack. Unlike a schematic that naturally is divided into sheets, a PCB layout is a flat representation in a single database. Most PCB design systems can partition a design, creating a new layout for each partition. Normally this would only be done once placement is complete; otherwise, how would you calculate the areas and size of the partitions? Ad hoc rules are put in place regarding the interfaces between the partitions so that they can be reassembled into the complete design.

Troublesome questions arise with this approach. What about nets that traverse partitions? What if a partition needs more space due to fanout and breakout? What if the agreed on partition interfaces are suboptimal? (Bit optimization of busses at the interface present a special challenge.)

The answers involve reassembling the board, making the change and then restarting the partition process. Then, having finished the partition design, the whole design is reassembled. Now we have to clean up the interfaces and complete any of the design that spans the partitions – for example, the global nets, power and ground planes.

As you can see, this approach is complex, and while users and the tool suppliers endeavor to automate and control the whole process, these problems are really just symptoms of the real underlying issue: the architecture of the tools. Many were designed in the ’80s and early ’90s. The only way to achieve concurrent engineering with tools designed for a single user is to somehow turn the problem into one of independent concurrent engineering. Clearly, collaborative concurrent engineering would make more sense.

The problem has been solved in industries such as IT and even video gaming by the use of a client-server architecture. Today’s video games allow multiple players in the same game, played over the Internet. The server provides access to the game’s database for multiple clients, ensuring data integrity and real-time game feedback and communication between the players. There are many other examples, such as video and voice conferencing, instant messaging, financial reporting – isn’t it about time PCB tools took advantage of this technology?

A client-server architecture allows multiple engineers to work on the same design data in real-time. Those engineers can be distributed across organizations, geography, and even companies.

Revisiting our examples, multiple engineers can work on the schematic such that they see their work in the context of the whole design in real time (including the system-wide connectivity model), not as a snapshot. If an interface changes, they see it immediately – no need to wait for a design review or schematic check. They can enter constraints and see where others are entering constraints without stepping on each other’s toes. Need to modify a net that crosses multiple sheets or hierarchy? No problem. They can make the change, and the team sees it in real time. Because there is a single schematic database, there are no error-prone re-synchronization steps.

A client-server architecture when applied to the layout allows multiple designers to work on a single layout design without the need for the partition-reassemble rigmarole. Each designer can see where the others are working; the possibilities are endless and can be applied from placement to routing to power distribution to manufacturing prep. Now, multiple designers can work on different areas of the board, or on different layers. Engineers can join a design session offering advice on critical placement and routing. Note also that engineers could include specialist disciplines such as RF, analog, FPGA, ASIC and IC package. Design consultants could work on the layout without the design data ever leaving the company’s server. 

Unlike the independent workaround approach, there is no duplication of design data, and there is real-time communication of changes and visibility of the whole design context.

The biggest benefit of collaborative concurrent engineering is the ability to accelerate schedules (and to claw back a slipped schedule). Other important benefits include:

• Ability to apply idle resources. (Not to be taken the wrong way! There are peaks and troughs with workloads in many situations.)
• Increased communication across the design team.
• Data integrity – no overhead of disassembly and reassembly; one copy of the design data.
• Promotes a team approach – team members learn from each other.
• Flexibility in management and utilization of engineering resources.
• Leverage of expertise across the team, even if not at the same location.
• If you like video games, it’s kind of cool and fun, and you have more time to barbeque with your family!

Companies are realizing quantifiable gains due to collaborative concurrent engineering. These statistics are not calculated projections, but data compiled by companies using this approach in actual design situations:

• Alcatel Lucent saw a 60% reduction in layout design time, from 13 to 7 weeks.
• Fujitsu Technology Solutions was able to eliminate expensive night shifts.
• Kontron has reduced layout time by 25%, even as designs became more complex.

Collaborative concurrent engineering offers major gains in productivity and design cycle time reduction, made possible by today’s client-server architectures and fast networking infrastructures.

Jamie Metcalfe is market development manager at Mentor Graphics’ Systems Design (www.mentor.com); This email address is being protected from spambots. You need JavaScript enabled to view it..

Figure 1. The partition and reassemble approach is complex, limited in application and error-prone.

Figure 2. A client-server approach allows multiple designers to work on a single layout design with real-time updates and no reassembly required.