Challenges in CSR Design and Verification Signoff

 

By its very definition, developing a system-on-chip (SoC) device involves both hardware and software. SoCs contain at least one or more embedded processors, often many running software that controls the hardware. Even an individual IP of any significant complexity is also likely to contain processing elements. In addition to the embedded code, there may be additional software, such as device drivers, that runs on a host system and also interacts closely with the hardware. Designing, verifying, and validating the hardware-software interface (HSI) is a key part of IP and SoC development.

CSRs are the Key

The embedded code and drivers form the software side of the HSI. The hardware side is composed of control and status registers (CSRs), architecturally-visible registers that are defined as part of the IP or SoC design specification. Software writes to the CSRs to initialize and configure the hardware, program it for its intended tasks, and provide input data. Software reads from the CSRs to gather output data and status information from the hardware. Of course, these two types of operations are intermingled; the status or results may lead the software to reconfigure or reprogram the hardware.

Registers may not sound complicated. The general-purpose registers (GPRs) that hold program data are simple indeed. But CSRs are much more complex. They often contain multiple registers of very different types, each with a precisely defined collection of fields. These registers, fields, or even individual bits may have special properties. Typical special register types include indirect, indexed, alias, lock, shadow, interrupt, counter, paged, virtual, external, read-only/write-only, and read/write pairs. There may also be FIFOs, queues, stacks, or other special register sets.

Tackling CSR Design

Designers can’t just use an off-the-shelf memory or register array macro to implement their CSRs. Different registers and fields must be handled differently. CSRs usually interface to a processor bus, so the interface for that also needs to be designed. This may bring in the need for clock domain crossing (CDC) logic between the bus clock domain and the interface clock domain. On top of all this, for safety-critical applications the CSRs may require safety mechanisms such as parity, error-correcting code (ECC), cyclic redundancy check (CRC), or triple module redundancy (TMR) logic. 

Clearly, manual CSR design is a significant task. Fortunately, the Agnisys IDesignSpec™ Suite provides a complete, automated solution. IP and SoC architects can define their CSRs using a range of standard formats. From these executable golden specifications, IDesignSpec generates the RTL design ready for logic synthesis, including:

• CSRs, with all special register types supported
• Bus interfaces such as APB, AHB, AHB-Lite, AXI4, AXI4-Lite, TileLink, Avalon, and Wishbone
• Any required CDC functionality
• Any requested safety mechanisms
• Documentation suitable for user manuals or programming guides

CSR Verification Challenges

Regardless of whether the CSR design is done painfully by hand or effortlessly with IDesignSpec, the next step is functional verification. As many studies have shown, verification consumes the largest share of the schedule and resources on an IP or SoC project. Verification effort scales non-linearly with the size and complexity of the design. Thus, the complexity of CSR designs has direct implications for the verification effort. Each special register type requires special tests in the verification suite. For example, it is important to verify that read-only registers cannot be changed arbitrarily.

Virtually all SoC and IP projects rely on the Universal Verification Methodology (UVM), which is very powerful but not easy to learn or use effectively. Object-oriented programming (OOP), constrained-random stimulus generation, and functional coverage are central features of UVM, but the concepts can be tricky and the language constructs are non-intuitive. Verification experts are required, and there are never enough available. UVM is very good at supporting reuse across projects, but a lot of additional manual effort is needed to move from standalone block and IP verification to the SoC level. 

The Coverage Hurdle

Even expert UVM programmers who can develop testbenches and tests quickly face a major hurdle when it comes to achieving verification signoff. With modern methodologies such as UVM, verification completeness is defined as hitting high coverage ideally 100% with self-checking tests running in simulation. Coverage points show how well the design has been exercised, and checking is intended to detect any bugs in the design. High coverage with an error-free regression test run is one of the key criteria for design tape-out.

There are many challenges in achieving verification signoff (and hence RTL design signoff) for CSRs. Manual coverage point specification often leaves gaps, so the verification team doesn’t know that some key functionality is never exercised by any test. Even if the defined coverage is perfect, hitting anywhere near 100% is tedious and time-consuming. When some coverage has not been hit yet, the verification engineers must review this carefully. They may waive some coverage points, for example if there is functionality in an IP that is not used in the current project.

For coverage points deemed essential, the team must try to hit them by tweaking stimulus constraints or modifying the tests. In many cases, this involves writing new test sequences to exercise the design in new ways. Doing this by hand is challenging indeed. It often takes multiple iterations through the verification process just to hit a single coverage point. Achieving coverage closure takes weeks, or even months, delaying CSR signoff. In practice, many projects tape out anyway, counting on at least one chip turn to fix any bugs that slip through. This is obviously a painful trade-off.

Tackling CSR Verification

Verification engineers ask if there’s a better way. They may look at their designer colleagues, who were able to generate their complete CSR RTL design at the push of a button. Whenever the CSR specification changes, as happens many times on every project, they can simply re-generate the design and supporting documentation. Verification engineers might wonder why they don’t have a similar solution. IDesignSpec generates a CSR UVM model, which is a good start, but that doesn’t fundamentally improve the coverage convergence loop.

Fortunately, Agnisys IDS-Verify™ is available to help. It generates a complete UVM testbench with coverage points, plus all the UVM tests to achieve 100% coverage. The next blog post in this series discusses this solution in detail.