feature article
Subscribe Now

Minimizing the Pain of RTL Design Reviews

Design reviews conger images of engineers carrying reams of code printouts, filing single-file and head down into a room to be judged by others. The positive impact of design reviews has been proven though many studies, but does the preparation and process of the review have to be so painful? This paper provides a practical approach to design reviews that soothes the process and actually results in a positive experience.

The key to a painless design review process is to use techniques and tools as code is developed that contribute to a quality solution, minimizing the time spent in the review. Review time can then be spent on important project debates, such as algorithmic or architecture implementation decisions, instead of drowning in the minutia of line-by-line code discussions. Striving for perfection, automated design review techniques take the place of most manual techniques. In reality, there is always a mix of automated and manual techniques as Figure 1 shows.

20081125_mentor_fig1.jpg
Figure 1: Automated techniques provide the most efficient design review.

The Source Code

Upfront techniques applied to source code provide an excellent platform for painless design reviews. Consider the following ideas:

  • Version management. If a version management tool is in use, make sure the correct version of the code is checked out for review and create a difference report on the code base between the last reviewed version and the latest. If version management is not in place, consider using it on this project before the review takes place.

  • Comments. Designers tend to ignore comments in code, but they can help facilitate a smooth design review. Comments should take a narrative approach, explaining what is going on with the code and why certain choices were made. This approach has the amazing effect of the author finding logic flaws and defects before the review takes place. It also provides a guided conversation during the code review.

  • Layout. The team should agree to a consistent layout of code modules. For example: one module per file, order of statements, and use labels on constructs. A standard layout cuts down on review time because the code flows in a consistent manner from module to module.

  • Checklists. Consider creating a checklist for each code developer that contains a set of common errors to check as the code is written. These items can include particular style guidelines, typical mistakes seen in the past, and known best practices. Each designer can add his/her own items to watch out for, based on past experience.

  • Linting. Consider using a lint tool to automate the checklist process. A lint tool can catch many of the coding mistakes as the code is written, report on code complexity and other metrics, and enforce code layout preferences. Some lint tools can score the code based on violations found. Teams can set a minimum score required before the review takes place. During the review the author can present the lint report and concentrate only on why he/she believes an exception should be made for any remaining violations.

The Visuals

In some cases, a picture of the code provides a better basis for high-level review discussions. Some EDA tools can provide these views automatically or they can be created manually. Consider creating the following visual aids:

  • Reference map. Create a map of all the references to files external to the code under review. References can be: include files, import files, packages, and macros. If the code is object oriented, create a class tree in order to track down inherited methods. The maps often take the form of a spreadsheet or a bubble diagram and they are used to quickly trace back to the source during the review.

  • File map. If the code under review is spread out into multiple files, a simple file map can be useful in order to understand the topography. This map is often combined with the reference map.

  • Requirement trace map. This map shows the relationships between functional and verification requirements and the source code being reviewed. Sophisticated maps also trace to the testbench and simulation results. During the review process, missing requirements can quickly be identified and incorrect implementation of requirements at the code level is evident.

  • Visualizations. A high-level block diagram is useful for hierarchical structural code. Complex algorithmic code is easier to review using state machine or flowchart visualizations.

Review Process Considerations

The team chooses the review process. It can be a manual code review or interactive collaboration over the web. Regardless of the process, consider the following concepts:

  • Website. Consider assembling the code, associated documents, maps, and visualizations on a website. This allows easy access to the material via an HTML browser. Tools exist that automate this process, or the website can be created manually.

  • Scope. Studies have consistently shown that the most effective review is performed in an hour on 200 lines of code or less. Keep this in mind when targeting the code for review.

  • Version Management. Manage code changes using the version management tool.

  • Bug tracking. Record any defects found into a bug tracking system. If the team does not currently use a tool, consider an open source tool such as Bugzilla. Finding defects is not useful if they do not get fixed. Bug tracking tools manage this process.

  • Note template. Establish a template for recording the review feedback. It should minimally contain what was reviewed and discovered, who was involved, and any defect resolutions. Tie these notes into a bug tracking system and the version management system.

  • Review. Review the review process. Were defects found? What worked well? What needs improvement? Address these issues before the next review. Also, update those checklists or linter rules based on the defects that you found.

Conclusion

Implement a few of the techniques presented before the next design review and determine what works. Then, explore ways to automate the process. There are many tools out there that help remove the drudgery of preparing for and performing design reviews. These tools have the interesting side effect of improving the overall design process.

8 thoughts on “Minimizing the Pain of RTL Design Reviews”

  1. Pingback: GVK Biosciences
  2. Pingback: DMPK Services
  3. Pingback: zdporn.com

Leave a Reply

featured blogs
Jun 6, 2023
Learn about our PVT Monitor IP, a key component of our SLM chip monitoring solutions, which successfully taped out on TSMC's N5 and N3E processes. The post Synopsys Tapes Out SLM PVT Monitor IP on TSMC N5 and N3E Processes appeared first on New Horizons for Chip Design....
Jun 6, 2023
At this year's DesignCon, Meta held a session on '˜PowerTree-Based PDN Analysis, Correlation, and Signoff for MR/AR Systems.' Presented by Kundan Chand and Grace Yu from Meta, they talked about power integrity (PI) analysis using Sigrity Aurora and Power Integrity tools such...
Jun 2, 2023
I just heard something that really gave me pause for thought -- the fact that everyone experiences two forms of death (given a choice, I'd rather not experience even one)....

featured video

Synopsys 224G & 112G Ethernet PHY IP Demos at OFC 2023

Sponsored by Synopsys

Watch this video of the Synopsys 224G & 112G Ethernet PHY IP demonstrating excellent performance and IP successful ecosystem interoperability demonstrations at OIF.

Learn More

featured paper

EC Solver Tech Brief

Sponsored by Cadence Design Systems

The Cadence® Celsius™ EC Solver supports electronics system designers in managing the most challenging thermal/electronic cooling problems quickly and accurately. By utilizing a powerful computational engine and meshing technology, designers can model and analyze the fluid flow and heat transfer of even the most complex electronic system and ensure the electronic cooling system is reliable.

Click to read more

featured chalk talk

Product Blocked by Supply Chain Woes? Digi XBee® RR to the Rescue!
Sponsored by Mouser Electronics and Digi
In this episode of Chalk Talk, Amelia Dalton and Quinn Jones from Digi investigate the benefits that the Digi XBee RR wireless modules can bring to your next design. We also take a closer look at the migration path from Digi XBee 3 to XBee RR, the design aspects you should keep in mind when moving from the Digi XBee 3 to the RR and how the Digi XBee Multi-programmer can help you get exactly the configuration you need in your next design.
Feb 1, 2023
16,074 views