A Blueprint for a Bug-Free Register Map
December 19, 2005
Back in August, Denali launched Blueprint, a tool to automate "the generation and management of the hundreds, and often thousands, of control registers used in complex chip designs as a source for efficiency improvements in system-on-chip (SoC) design."
According to Denali, "Blueprint is used by chip design teams to automate the creation and management of control registers, and all related models, design views and documentation. From a register description language (RDL) input, Blueprint generates views for hardware and software development, verification, and documentation. Supported output formats include Verilog, C, C++, OpenVera, e, OVL, Frame, HTML, SPIRIT-compatible XML, MS-Word and more."
I haven't had the opportunity to try Blueprint yet, but I've used similar tools at other companies. A common concern among engineers who are introduced to such a tool is that using the same code as a starting point for both the design and verification leads to both environments having the same functionality, implying they will also have the same errors.
I disagree that automatic register generation lessens the verification process. Just because the encapsulation of the description of the registers is done in an automated fashion doesn't mean the actual verification is done that way. The last time I used a tool for auto-generating registers, the software, design, and verification teams were all involved in the creation and testing of the register map, but from different perspectives:
- The Architects were looking at the registers from a systems point of view to make sure the registers were created in a way that furthered the goals of the top level architecture.
- The Design team had to then fill in any missing gaps in the register map and make sure they were actually using all of the registers they were supposed to.
- The Software team was blasting through the register descriptions and were frequently finding problems in areas where the registers did not give the software team the flexibility it needed to configure the DUT.
- The Verification team was reading the documentation and writing testbench features to verify all of the functionality described by the registers. The fact that the data structures used to describe the registers themselves were automatically generated was irrelevant. It just saved us the trouble of debugging typos as we copied from a (potentially) incompletely specified register map.
From the perspective of a verification engineer there are four main benefits to automatically generating registers. First, all of the team's energy is focused on debugging one version of the specification (not 3 or more). Second, changes are forced to be specified fully and can be sanity checked for many types of errors by an automated process. Third, everyone is seeing the same database, which means any changes in the database by one party are seen by all parties concerned (this means they are forced to communicate and coordinate much more closely than they would have otherwise). Fourth, it is relatively easy to automatically generate code to capture functional coverage of registers in any number of languages (PSL, SVA, e, etc). A tool that can automatically generate CSR data structures could also be configured to generate a basic set of functional coverage for those registers.