Finding design errors before it’s too late

What are Design Reviews?

Design Reviews are a service offered by Arm whereby expert engineers visit our partners to perform a detailed review of a particular stage of the design cycle. Based on that review they can provide feedback, best practice advice and propose solutions to any issues identified. These differ from training in the sense that they can help to guide partners during the implementation of Arm technology in line with specific project goals.

Most silicon failures are caused by issues related to:

  • Connectivity: polarity, connection or synchronisation;
  • Specification: IP specification, integration errata, IP specific needs;
  • System integration: system consideration, bus topology, cross-IP integration

This blog will show some real-life examples of how Design Reviews were applied and saved Arm partners time and money.

 Arm Design Reviews graph

Design Reviews are designed to address project 'Hot Spots' in a typical SoC design flow

Case Study 1: Architecture Design Review

During a single Design Review on a customer project in 2014 16 errors were identified, some of which could have resulted in a partial or complete failure of design and therefore required a re-spin. The issues were identified and guidance was presented to the customer which allowed them to address those errors, saving significant time and lots of money. The diagram below lists all the errors identified during that review.

  Diagram of issues identified during an Architecture Design Review

Issues identified during an Architecture Design Review

Case study 2: RTL Design Review 

In some cases, the requirements of the IP can mean that the connections needed as part of the integration are not obvious. Within the GIC-400, the registers for each CPU interface are banked, meaning that accesses to the same address need to access different physical copies of the registers if they originate from a different master. This means the GIC needs some way of identifying which core is making an access, which it does by having a value driven on the AxUSER signals corresponding to the core performing the access. 

In many cases, system integrators will tie the AxUSER input low, as they believe it to be unused. This causes all accesses to appear to be coming from core 0. Instead, the integrator needs to realise that the originator of the transaction is signalled in some other fashion, and to tie those to the AxUSER input. Tying AxUSER incorrectly effectively makes the GIC unusable to all but one core. This kind of integration error would be spotted during an RTL Design Review.

 Registers for each CPU within the GIC-400 

Registers for each CPU within the GIC-400

Case Study 3: RTL Design Review

Processors can have very specific power down sequences, which can vary from design to design. Partners may not follow these either because they do not notice the difference, or they do not believe it matters – it’s preferable for them to port software across without having to make the changes. 

In this example, the Arm Cortex-A73 requires nCPUPORESET to be asserted before the clamps are applied, as asserting nCPUPORESET for a specific core has a side effect of preventing snoops being sent to that core.

If the clamps are asserted before nCPUPORESET, then a snoop can be sent from the SCU to the core being shutdown which will never complete as the clamps prevent the core from responding. This means the system can potentially hang every time a core is power down.

 Cortex-A73 MPCore power down sequence

Cortex-A73 MPCore power down sequence

Case Study 4: Architecture Design Review

In AXI there’s an ordering requirement between the AW (write address) channel, and the W (write data) channel, which requires that the first item of write data must arrive in the same order in which the write addresses arrive. This can cause a potential deadlock in an interconnect network with multiple switches and registering components, such as in the below example. Each of these transactions has a requirement on the progress of another transaction, which forms a deadlock loop. This can be seen visually as loop that traverses a number of a different interfaces.

The challenge here is that integrators need to be aware of the potential AXI deadlock, and they need to be able to perform their own analysis to find potential loops as these require knowledge of the system. A deadlock prevention mechanism can be applied at the points of divergence in order to solve this issue. These issues would be analysed during an Architecture Design Review.

Potential deadlock in an interconnect network with multiple switches and registering components

Potential deadlock in an interconnect network with multiple switches and registering components 

How do Design Reviews work?

In general, each Design Review has three stages: preparation, on-site visit (not applicable for Implementation Assist) and report. The preparation stage is necessary to ensure the best use of time spent in the main on-site visit phase. Typically, the preparation phase takes a few weeks, followed by an on-site visit of around three to four days. A report is then prepared within two weeks of the visit and contains a summary of the project and a detailed account of the issues, recommendations and observations made during the review.

Areas typically checked during a Design Review are shown in the diagram below:

Areas assessed during a typical Design Review

Areas assessed during a typical Design Review

Why did Arm start offering them?

Arm experts have already performed 86 Design Reviews for 43 different partners. One or more serious issues were identified in 75% of Design Reviews. Those issues would have resulted in partial or complete functional failure of the device.

SoC design is becoming ever more complex, and that combined with the pressures to reduce cost and time-to-market at the same time as increasing performance, is pushing the drive for higher efficiency. This rise in complexity of the modern design process flow requires many steps, multiple tools and diverse expertise. Using Arm Design Reviews allows our partners to catch critical design errors while they can still be fixed, thus reducing the risk of delays, expensive re-spins or a compromise in product quality. As an example, a re-spin of a 40nm design would cost approximately $200K, however that can vary significantly depending on foundry process.

Why do I need Design Reviews?

Our experience shows that the majority of designs contain serious errors which would result in delay, extra cost and reduced functionality. Many of these errors are caught by an in-depth Design Review.

They can accelerate time to market by reducing the time spent in checking and verifying designs. They can also avoid the need for further iterations and repeated tape-outs.

Design Reviews can highlight potential bottlenecks early in a design, helping you to achieve your design goals quicker. Arm IP can be configured, combined and used in many ways. Design Reviews help you determine the optimal use of the IP to meet your product goals within design constraints.

Please share your questions and thoughts in the comment section!