Concurrent design: one team, one virtual location

As electronics design becomes more complex, it is increasingly important to find ways to enable large teams with diverse skills to work together on a project. With design schedules shrinking, high-level work has to start across all the relevant disciplines as soon as the design requirements begin to be clear.

Highly interdependent circuits should be designed concurrently using one set of shared design data. This avoids artificially serializing tasks and extending design schedules. For your EDA software to accommodate parallel design, it should approach concurrent design in the same way that computer scientists have achieved parallelism, with concurrent access to shared memory. With well-defined rules, many designers can share and modify the same design data in a productive and simultaneous environment. If this becomes possible, work dependencies between disciplines disappear, the need for ‘follow the sun’ design operations disappears, and design schedules can be reduced, limited only by the conceptual separation of tasks.

The problem of big designs

As electronics designs become more complex, many design specialties get involved and the scope of the overall task results in lengthy schedules. Co-design, designing together and at the same time, addresses these issues. Concurrent design goes further, by implying that a group of designers can work on a design at once and all their design inputs are accepted. That is a little trickier to implement.

Without implementing concurrent design, you’re left with a linear design flow, (Figure 1) in which each step has well defined inputs and outputs, and one step has to finish before the next step starts. Each step is an isolated task done by a specific designer. Each handoff involves a released output, a file and a printed schematic. Each designer has to wait for the previous designer to finish.

Competitive companies have invented ad-hoc versions of concurrent design to compress schedules. Implementing certain design practices can enable limited concurrency, but these companies are only really using work-arounds for the limitations of their current tools and techniques.

Problem to solution

How can we improve the situation? The first step is to reject the artificial limits imposed by the way that current EDA tools work and the design techniques that sprang from those constraints, and instead to think about what an ideal solution would look like. The next step is to find a tool that can work that way.

Benefits of a cohesive design team

The best way to get a design done quickly is to have a large team in one place whose members can all work on the design at once. Some companies use a ‘follow the sun’ strategy, passing responsibility for a complete design to teams spread out around the world so that it can be worked on 24 hours a day. This can work, but takes a lot of effort to manage multiple teams in multiple time zones, with different languages and cultures. True concurrent design would enable these design teams to be in the same office at the same time working on the same database. This would remove the hidden inefficiencies of managing a world-hopping design, and enable the team to discuss priorities, clear up misconceptions and share problems and solutions in real time.

Benefits of collaboration

Collaboration should mean that many people work together in a way that is more effective than any of them working alone. Take a PCB design task as an example. If each person’s view of the schematic, PCB design, and its constraints were updated live and without conflict, a specialist could work on a circuit at the same time as a junior designer in order to explain design concepts in real time on the real data.

The tools enable mentoring and the spread of internal expertise. A common database also means instant design visibility by all. Instead of waiting weeks for a formal design review, a designer can ask for a spot check of an issue. Any reviewer can open the database to look at the design in progress, rather than wait for a weekly report to know how far a particular effort has progressed. With universal visibility of the actual designs, barriers to communication evaporate.

Benefits of a cohesive design repository

So far I’ve described one big happy design team sharing and designing. Sometimes design develops a regional focus, for example when an RF group that won’t budge from the central California coast and a chip design team is equally entrenched in Silicon Valley. Although it might be better for the two groups to be in the same place, what really matters is that each specialty can work well in its group, and that the two groups can work together effectively despite being physically separate. Using a single shared design repository, accessed remotely, means that it doesn’t matter where each designer is located. The team can get on with doing their design work, safe in the knowledge that they are working with the live design data – and encouraged by the fact that they won’t have to sit through design review meetings made necessary by software tool limitations.

The ideal solution: maximum parallelism

Design engineers have developed concurrent design practices to work around the limitations of current tools. Although they are an improvement over pure linear development, some of these approaches just add complexity while providing limited gains.

Partitioning and reassembling a PCB layout, for example, is complex. It also takes time to coordinate multiple designers to work on subsets of a design database. True design parallelism would be much better acheived by software programs running in parallel, accessing the same data and using the concurrent memory access techniques developed over the past few years to share one data set to many users effectively.

This means developing techniques so that all users can write to the database. To avoid conflicts, each write access is defined as a small event, is achieved as quickly as possible and writes as small a piece of data as possible. The boundary of the data must be known, and the minimum sub-set of data is locked while written.

This approach has already been implmented successfully – think of the shared databases that enable millions of users to play fantasy football in real time. The soltuion, discovered thanks to countless hours of testing by NFL fans, is to use a transactional server. Carrying this across to the world of PCB design, our approach has been to use a transactional server in-between the PCB database and its pool of users.

The ideal solution in practice

Mentor Graphics is not the only vendor to choose this approach, and the XtremePCB product is its implementation of a true concurrency solution. This means using a common database that all the designers can access, held on a networked server that is also running the design-access transaction service process (see Figure 2). This approach makes the issues of design partitioning, snapshots and archive handoffs a thing of the past.

In practice, each designer begins by joining as a member of a session in progress. The design server should have fast network access and plenty of free processing capability so it can handle lots of transaction requests easily. Once a designer has joined a session they can see the work in progress but do not stop other designers doing their work. Mentor has extended concepts originally developed to avoid conflicts and maximize access to shared memory in computer architectures to shared design activity, so that incremental changes are accepted into a design without blocking other users. This means that all designers’ inputs are equally valid so that conflicts, and areas of influence that can be used to avoid conflicts, are immediately obvious on screen (Figure 3).

Conclusion

Some of today’s design practices are encumbrances that have evolved because design tools are unable to handle many designers working on the same design at the same time. Borrowing techniques from computer science has enabled us to build a truly concurrent design environment that enables many designers to work on a design at once, simplifying design management and enabling the kind of easy collaboration and open communication that helps shrink design schedules.

Author

Randall Myers is a technical marketing engineer with Mentor Graphics, focused on FPGA tools, Myers’ experience has alternated between designing with FPGAs and enabling and teaching FPGA design. In his current role Myers is bringing together the EDA tools involved with FPGA design and Mentor’s I/O Designer software.  Randall’s MSEE from the University of Colorado at Boulder in 2010 was in computer engineering, and computational parallelism in FPGA architectures.