STOP Writing RTL for Registers

After almost three decades in the EDA business, it is beyond my comprehension to understand why chip designers still hand-write RTL for complex register maps – chip designs with hundreds of registers and thousands of register fields.  In today’s silicon world where software is the key to chip-based product success, it is the register map that defines the hardware/software interface (“HSI”) that enables the software stack to bring silicon-based products to life and put a smile of satisfaction on the customer’s face.  In the real-world, getting the HSI right is even more important than a few nanoseconds of latency improvement, or a few milliwatts of power savings – if the HSI doesn’t work in the customer environment, you don’t have a deliverable product.  So, why do chip development teams still try to manage complex register maps with manual methods?  If you want to understand why chip development teams should STOP writing RTL for registers, read on.

The register map specification is created by “company visionaries” who are entrusted to imagine how the product will work in the hands of the customer, and the specification should be a sacrosanct single-source-of-truth HSI specification for all chip development team stakeholders – RTL designers, the verification team, the software team, and documentation.  All team stakeholders should strictly adhere to the HSI specification – and observe a disciplined process for negotiating changes to the HSI when necessary.

The RTL should faithfully implement every nuance of the HSI specification because the slightest infidelity can be catastrophic (read “expensive”), and the software team must be pro-active participants in the RTL implementation to enable the richest possible customer experience.  And yes, finalizing the HSI is an iterative process, sometimes extending beyond product delivery – so changes to the HSI implementation must be fast, accurate, comprehensive, and include all chip team stakeholder views.  Human intervention only adds risk, consumes precious resources, and will assuredly impair productivity.

YES, Register Map RTL Is Different

In today’s silicon world, chip implementation is a composition of processor cores, memory blocks, third-party IP, and bespoke RTL – the RTL where a company adds “secret sauce” based on experience and proprietary innovation. It’s challenging to produce a compellingly differentiated chip-based product solely from commercial IP blocks – but it’s no longer economically feasible nor efficient to re-create everything from scratch.  Which should lead chip developers to focus their efforts on unique architectures, unique data flows, selecting optimal third-party IP, the bespoke RTL, and design tool automation – and NOT “waste” design team resources where there is no differentiated value-add.

Register map RTL is different, it should be afforded special attention in the design flow for complex register maps, and because fidelity of the single-source-of-truth specification is so crucial to a successful chip project, this RTL implementation should be fully automated.  Only with full automation can complex register map RTL be managed successfully for today’s silicon development –– production-proven, comprehensive register management tools that automate the generation of all register map views.  This is NOT the place to bet-the-farm on non-scalable, hacked together spreadsheets and scripts.

Do Yourself and Your Company a Favor – Start with A Domain-Specific Register Map Specification Language

There’s a lot of confusion and misinformation about register map specification languages.  This is the language or format used to capture the detailed register map requirements – that becomes the single-source-of-truth HSI specification.

Popular data formats like IP-XACT, and JSON were developed as data exchange formats – they were NOT developed for authoring register map specifications.  They were NOT purposely developed to express the many different, sometimes subtle, property nuances of modern complex register maps.  Maybe better than spreadsheets, but non-optimal for complex register maps.

SystemRDL is a register map authoring language that was originally developed for internal use by Cisco Systems specifically for register map specification, commercialized and branded as “SystemRDL” by Denali in 2006, the specification for which was published by the SPIRIT/Accellera consortium in 2009.  The last SystemRDL update (SystemRDL 2.0) was released in 2017, and according to the Accellera website (https://www.accellera.org/activities/working-groups/systemrdl) – “This Accellera working group is currently inactive.”  SystemRDL is still in use today, but is missing significant market-driven requirements for register map specification.

There is only one commercial, domain-specific register map authoring language available today that was purposefully developed for specifying complex register maps and address the feature deficiencies of SystemRDL 2.0, that has advanced to keep pace with today’s chip development needs – CSRSpec from Semifore.  It is easy to learn and use, is rich in register property expression features, is scalable to millions of registers, and is silicon production-proven over the past 16 years by leading silicon developers around the world.

Automate Register Map View Generation for All Chip Development Stakeholders – Including the RTL.

Once you have settled on a scalable language for your single-source-of-truth specification – let automation do the rest.  There are several register map “views” that are essential for chip project success – RTL (Verilog, VHDL), verification (UVM), software (C-header files), and documentation (Word).  And it is essential that all views stay in sync throughout the chip development cycle – sometimes after product delivery.  The generation of these register map views is not the place to invest precious engineering resources, so automation is the obvious solution.  Automation eliminates human error and reduces the development teamwork-effort – so delegate this part of the design flow to automation tools.

CSRCompiler is a cross-compiler from Semifore that accepts register map specifications in multiple input languages/formats – CSRSpec, SystemRDL 2.0, IP XACT, and spreadsheets – and generates all the required register map views – RTL, UVM, IP XACT, C-headers, and Word documentation.

Final Comments

Now – if you agree with the preceding, why would RTL designers want to, or even be allowed to, hand-write RTL for complex register maps?  Could it simply be because that’s the way it’s always been done?  Could it be because of a lack of awareness that a better way is available?  Could it be because changes to the design flow are hard, and everyone is so busy that they think there’s no time to change the design flow?  If there’s any doubt about the complexity of future register maps – they will only become increasingly more complex!

Whatever the reason, you should consider contacting Semifore for a demonstration of a better automated solution to manage your complex register map implementations. Now you know why chip development teams should STOP writing RTL for registers.

Also Read:

Semifore is Supplying Pain Relief for Some World-Changing Applications

Webinar: Semifore Offers Three Perspectives on System Design Challenges

A Solid Methodology is the Margin of Victory