Designing alone allows the autonomy and flexibility that all engineers value. Adding team members to a design project typically limits freedom and can actually add complexity to the project. Implemented correctly, a team design environment can facilitate creative design and minimize tedious and repetitive tasks that can lead to mistakes and missed deadlines.
Implementing a team design environment can seem a daunting task comprised of hundreds of details. A new project could employ a new, complete team-based environment or phase individual processes to avoid too much disruption to the designers. Regardless of the phasing, up-front planning and an organized rollout is required. Planning is personal and varies from team to team.
However, the key to a successful deployment is to consider the elements represented by Figure 1.
Figure 1: Key elements of successful team design environments
Team members informally meet and discuss design issues on a regular basis either in person or via electronic means. A minimum set of formal communication processes should be in place for success, including:
- Design reviews: periodic reviews of the design at various levels of abstraction; from conceptual diagrams down to the actual RTL implementation and verification results. The review content, format, and milestone criteria need to be planned and implemented.
- Issue tracking: a formal process and storage system for bugs to which every team member has access. Often, regular reviews of incoming bugs are required by the team in order to set priorities and to balance tradeoffs against schedules. The level of known bugs acceptable for production also needs to be established.
- Documentation: a chain of documents from requirements, design descriptions, reports, to comments in the RTL implementation, adequate documentation is necessary for communication of the design implementation between team members. This documentation serves many purposes; from communication within teams, management, and customers, and to facilitating reuse of the design in future projects.
- Metrics: typically dreaded by engineers because these numbers are often used as a management hammer. Managers aside, teams can benefit from knowing how much work is left in a project in relation to the schedule. These metrics can include: code quality scores from linting tools, lines of uncommented code completed, outstanding bug count, verification suite completion reports, or any report from tools that shows design status.
Standards and Processes
Before a project starts, a collection of agreed-upon standards and processes should be defined so that all team members work within a common environment. Typical standards and processes to consider include:
- Infrastructure: when designers are using a mix of operating systems, time can be lost due to version incompatibilities, problems with remote login using middleware software, and licensing issues. One standard operating system across the team minimizes environment issues.
- Language dialects: some engineers are more familiar with VHDL versus Verilog making efficient coding difficult, but pick one IEEE standard dialect (such as Verilog 2005) and stick with it for the project. Engineers using their favorite construct from a yet-to-be approved version of HDL can cause problems in the tool flow. You might be forced to use an IP block written in a different language, but avoid this if possible as some tools do not efficiently support mixed-language design.
- Coding standards: as the code is written, use automated lint tools with your own set of rules to enforce best practices, downstream tool checks, and standard coding techniques. Code written to a standard is easier to review, prevents mistakes when the blocks are assembled, and eases code reuse.
- Tool flow: each engineer’s block of code must get consistent and repeatable results. Decide on the tool chain and associated versions that are employed in the design process and lock them down for the duration of the project (unless a show-stopper bug exists in a tool that requires an upgrade). Decide which tool options and switches should be consistently used and write a very simple script that the team can use to configure the tool flow.
Even small projects can generate a great deal of data. Large, team-based projects can spawn an overwhelming number of files. If a chaotic approach is taken to team data management, a project can regularly fail throughout its lifecycle due to missing or incorrect files. Common factors to address for data management include:
- File organization: establish a simple directory structure for the project and a file naming scheme so that all the files can be quickly found and used by each engineer. Name each file using the name of the module or entity and only place the source for that module or entity in the file. House common files, such as packages or includes in a central location. A defined file organization also facilitates archiving and reuse.
- Version management: is the key to successfully building the correct version of a design and for backing out changes that cause issues. Choose one team member to “own” the top level of the design and all team members follow the chosen version management process. To get started, investigate RCS or CVS which are open source and commonly used.
- Reusable verification environment: consider developing a standardized testbench using industry-standard techniques such as the Open Verification Methodology (ovmworld.org). This allows teams to get up to speed quickly in a familiar environment and to save time on a new project.
- Design repository: provides a method to store completed designs for reuse later. A simple web page linking to available designs within the company can save the team significant time by not re-inventing the wheel.
Team design requires planning, structure, and discipline – all concepts that can strike fear and loathing within the engineering community. A careful balance of the process and concepts in this paper can keep engineers creative and happy and result in a successful team-based project. Start by choosing at least one technique on the next project and phase in other processes over time to enable successful team-based design.
Tom Dewey is a Technical Marketing Engineer for the HDL Designer Series product line at Mentor Graphics. Tom has over 20 years of EDA experience, contributing to ASIC and FPGA software products used for creation, synthesis, verification, and test. Dewey holds a B.S. in Electronics Engineering from the Oregon Institute of Technology.
Send your comments to firstname.lastname@example.org and our Editorial Director at email@example.com.