| 2 min read

Semiconductor Register Specification: Shadow of a Shadow

So we have been working in the register specification space for a long time. We came out with the IDesignSpec tool around 2010. Five years of constant refinement and evolution based on the customer feedback has created a very mature technology that can pretty much deal with any flow that the customer needs and any type of register that he needs. Well, so you would think. However, to our amazement we still, constantly get new requests from new customers who want to add more features to suit their needs. We of course take these new flows and new register types and new behavior with gratitude and incorporate them in the tool to make the tool more versatile.

Great discussions about Semiconductor Register Specification at DVCon

At our booth at DVCon and visits to several new customers in the Bay area we find that many companies are still struggling with Register data and how to come up with a coherent methodology that satisfies all aspects of register data usage. Satisfying one group of people is difficult, but in this case you need to satisfy many different teams with different goals within these large organizations. And if you come up short, then you will have to revisit this issue in a few years once again.

Some of the requests we received were …

  • How to refer to an IP-XACT or SystemRDL files from a CSV file at the top level
  • Support for plugins for Excel on MacOS
  • Google docs and LibreOffice, just to name a few

There is also confusion

Some people think that with the advent of UVM registers, all problems related to registers have been solved. They are totally mistaken. UVM is a good starting point but their journey has just begun. And some don’t know how to begin that journey. To them, I say, use the Automatic Register Verification (ARV) module to get you started with UVM. Imagine, describing your registers in SystemRDL, CSV, Word or Excel and not just generating UVM model or RTL model, but generating the entire UVM testbench environment, the sequences (positive and negative), the agents, the makefile and even a verification plan to provide a proof that all registers are behaving as expected. We found that on an average UVM standard sequences can provide around 55% overall coverage of the registers when you have a mix of register types, while ARV give upwards of 90%. This is significant as you get this at the click of a mouse!

The other issue we encountered at DVCon and talking to various companies in the area, was the lack of consistent definition about the special registers. These special registers are what makes this field interesting and how to deal with them in RTL and UVM is always a challenge and cause for debate. One engineer came to me and asked about Shadow register only later we discovered that he was taking about indirect registers. Another engineer we visited talked about Aliased registers when really what he meant was two different views for the Software. And one area that has more confusion than any other is Interrupts.  

I’ll be writing about each of these special register types in my future posts

Any college student can write a tool in python for creating registers, its these complex registers that require an industrial strength tool like IDesigSpec.

If you bring IDesignSpec into your semiconductor design flow, you will be creating consistent specification without a shadow of a doubt.  If you are not planning to visit DVCon, then please watch our on-line demonstration video of our semiconductor register specification and verification solution.

Semiconductor register verification automation

Semiconductor Register Specification tool evaluationic designer's guide to automating design through implementation of semiconductors