Denali SystemRDL and PureSpecRDL
Today I had the opportunity to meet with Sean Smith, Chief Verification Architect, and Tim Cook, Staff Software Engineer at Denali. Sean and Tim were kind enough to spend an hour and a half discussing SystemRDL, Blueprint, and PureSpec SystemRDL with me. For those of you unfamiliar with these products, they cn be summarized as follows:
- SystemRDL - A specification language for describing control and status registers (CSRs).
- Blueprint – A tool that takes a register set described in SystemRDL and transforms it into the appropriate documentation and data structures required for design, verification, and software development.
- PureSpec SystemRDL – Verification IP designed to allow users to abstract the way registers are accessed and to provide a set of sequences that can be used to test CSRs in a variety of ways.
This was the first chance I’ve had to sit down with the technical folks at Denali to discuss the tools, and I learned a few new things. First of all, I learned that the SystemVerilog models generated by PureSpec SystemRDL are designed to work with the AVM and VMM, and that (for example), the VMM-style implementation is compatible with the Register Abstraction Layer from Synopsys. This means you can use SystemRDL and Blueprint to define registers and generate documentation, and then use PureSpec SystemRDL to generate a RAL-compatible verification IP component for use in SystemVerilog testbenches.
Additionally, Denali has created an Eclipse plugin to provide a graphical way to create and edit SystemRDL register definition files. The plugin includes syntax highlighting for SystemRDL files. Syntax definition files for Emacs and VIM are also included in the general Blueprint/PureSpec SystemRDL releases.
The technology behind the suite of tools was developed by one of Denali’s customers over the course of about ten years prior to being productized, and it shows in the fact that Sean and Tim were able to answer just about all of my questions. The one area where I had some concern was regarding the robustness of support for accessing registers from different masters in a SoC environment. The tool officially supports this type of usage model on paper and in the demo I saw, but I would want to try out the tool suite in a real SoC environment before concluding that 100% of the features I’m looking for are present.
