Register Bits

For the system designer, the platform is a complex supply chain of internal/externally developed hardware/software intellectual property (IP). It’s a complex set of risks and trade offs that must be analyzed in the decision making process. The winning platform provider will go above and beyond, to provide a whole solution, including a programmers guide to the register map, driver code and maybe even an executable specification model.

There are many different requirements that the System Developer may have for the IP deliverables, including:

• a programmers’ guide on interfaces, interrupts, registers, and so on
• example/reference firmware for driving and testing the IP in a standard configuration
• inter-operable models of the IP in various different languages, at different levels of abstraction (firmware, ESL, HVL, RTL, XML, etc.)
• ability to integrate and even re-code firmware in a system-specific way across all IP in the system
• ability to easily integrate and brand IP documentation across the entire system in a consistent, professional way

A good approach to the modelling and abstraction of the hardware/software interface can help to achieve these requirements for both the IP producer and the system integrator. The SpectaReg register management tool’s approach is to generate the different deliverables from a common, single-source specification model. This provides opportunities for “bottom up” and “top down” approaches to firmware abstraction and system documentation preparation.

Abstraction by the IP Provider - Bottom Up
The IP provider should provide a memory map document of the different memory mapped elements and registers. Better yet, they may additionally provide a device driver code that abstracts the registers to provides a higher level view of the IP. Since the abstraction is created by the engineers specializing in the IP rather than engineers specializing on the overall system we call this “bottom up” abstraction.

Abstraction by the System Integrator - Top Down:
The IP consumer may have their own special way of doing device drivers, system memory testing and diagnostics. They might be targeting a specialized processor or interconnect architecture, language or operating system. They might be optimizing for throughput, power, or memory. They might have custom monitoring, programming and debugging systems. For these reasons the IP consumer might choose to create their own firmware. This “top down” approach to hardware abstraction requires that both the IP provider and consumer have excellent and inter-operable register management workflows.

The Register Supply Chain:
Something we are seeing in our extensive work with registers is that there is a supply chain of register specifications from the different IP providers. For example, the provider of a SPI core may have several registers that they code in Verilog, VHDL, C/C++ and publish in HTML or PDF. Then, the consumer of the SPI core may want to integrate the registers of the SPI core into their overall register map and C/C++ driver code in a way that is consistent across the entire system. Within this process there are various different teams and perspectives that need to consume the specification and produce work based upon that. This is the Register supply chain.

A Semantic Register Specification and the Supply chain:
Ideally the IP developer captures the registers into a semantic specification model that can be used as a single source of the register interface specifications. With SpectaReg, this is done through a browser based GUI and imported/exported using IP-XACT (and many other formats too). The underlying model specifies all relevant information relating to the registers, including typing information relating to how the register’s bit-fields are implemented and how they function. The model also includes inter-relationships between register fields. For example, a certain bit may be defined as an interrupt and it may be associated with a trigger and mask bits. The firmware programmer knows how the interrupt will operate and the RTL developer knows how it is auto-implemented in the Verilog and/or VHDL, based on the typing of the bit. From the semantic model, the related RTL and firmware code can be auto-generated to target different bus interface protocols and different coding and presentation styles that suit the needs of the system integrator.

Simply throwing the semantic register specification over the wall to the IP consumer (say in an IP-XACT XML file) does not solve everything. There are opportunities for the supply chain to get out of synchronization and for non-formalized communication of information to get lost. The flows for making changes and feeding back information from the different parts of the supply chain are not well defined. Using a dynamic web application to manage the specification model and manage the dynamic and collaborative work-flows of the register supply is part of our vision. We see this as the best way to simplify the overall process and address the needs of all stakeholders. What do you think?

Twitpic from S_Tomasello "How's the attendance at #46DAC today? Umm..."

Last week at the Moscone Center in San Fransisco, the 46th annual Design Automation Conference (DAC) took place.  I’ve attended this conference for the past 4 years and decided not to attend this year.  This year I attended virtually using the web.

In the EDA media and for EDA trade shows, as Bob Dylan sang, the times they are a-changin’.  It’s no secret that the incumbent media is struggling to find a business model that works in the uncharted waters of the future.  As history repeats itself, the “hidden hand of supply and demand” will no doubt fix some shortfall with the traditional model — a shortfall that may not be fully understood until it is solved.

With the electronic media shedding their top writers, the coverage of DAC by trade publications is diminishing.  At the same time, new media, such as blogs, Twitter, and LinkedIn are picking up some slack.  For example, Richard Goering and Michael Santarini who historically covered DAC for EETimes and EDN now write for Cadence and Xilinx respectively.  Some of the best DAC summaries that I read were blogged by:

• Peggy Aycinena’s on her Thursday’s Child (R U a Wizard of Management Warcraft?)
• Mike Demler on his “The World is Analog” blog (Highlights from the Design Automation Conference, #46DAC - Day 1)
  
• Richard Goering on his Cadence blog (Ten Takeaways From the EDA CEO Panel, 8 Design Managers Reveal Top Concerns, GPUs Or Multicore For EDA Applications?)
• JL Gray’s Cool Verification (The Past, Present and Future of the DAC)
• Paul McLellan on his EDA Graffiti blog (day 1, VC Panel, denial computing)
• Sean Murphy at SKMurphy.com (provides a great index of blog postings on the 46th DAC)

Additionally, on Twitter, the #46DAC tag provided useful information about what was going on at the tradeshow.  For me, some tweeps who provided informative DAC coverage via Twitter included:

• Dark_Faust — editor in chief of Chip Design & Embedded Intel magazines & editorial director of Extension Media
• harrytheASICguy — ASIC consultant & blogger, did a Synopsys XYZ conversation central sessions at DAC
• jlgray — Consultant with Verilab, photographer, coolverification.com blogger, conference presenter
• karenbartleson — Sr. Director of Community Marketing at Synopsys and blogger on “The Standards Game.”  Karen won “EDA’s Next Top Blogger” at DAC.  Karen did a lot of tweeting to inform people about the #46DAC and Synopsys Conversation Central had a “Twitter Tower” that displayed the #46DAC stream.
• MikeDemler — Tech industry analyst, former marketing insider (from Synopsys), blogs at “The world is Analog”
• paycinera — EDA Confidential editor Peggy Aycinena broke her cryptic series of gobbledygook biography tweets, the EDA Town & Gown Twitter Project, to provide some of the best Twitter coverage from DAC
• S_Tomasello — Marketing at Sonics, the providers of “On-chip communications networks for advanced SoCs”

Based on the various reports and summaries from DAC, there is an apparent need for collaboration (as mentioned by keynote Fu-Chieh Hsu of TSMC) and productivity (as mentioned by the CEO panel). The same forces that are changing EDA trade media and conferences — the power of the Internet, coupled with economic forces –may enable the solution to better collaboration and productivity. Cloud computing business models like Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS) are starting to prove themselves in other industries and will continue to find their way into commonplace. Exactly what the “hidden hand of supply and demand” has in store for EDA and cloud computing has yet to be revealed and we are just in the early stages now.

From various blogs and Twitter, without having attended DAC, I understand that:

• there continues to be a need for better collaboration, productivity, and higher levels of abstraction
• today’s current economic situation, spurred by the US credit melt-down, has affected EDA
  • the traditional trade media is struggling
  • new chip design starts are down
  • Magma design Automation, released that they are re-negotiating debt as a result of an audit report regarding their solvency, just as the conference was kicking off
  • traffic on the trade floor was questionable: some said it was above expectations while others said it was below
  • new VC investment in EDA start-ups is pretty much non-existent
  • TSMC is becoming more and more of an ecosystem heavyweight
  • there is optimism about the future and the recovery of EDA — with change and crisis, there comes opportunity for those who see it
• the media landscape is changing
  • there is a struggle between the blogsphere and traditional press to cover EDA
  • blogs are gaining acceptance and playing more and more of a role
  • filtering through and connecting disperse info is a problem
  • John Cooley dismisses the utility of blogging, LinkedIn and Twitter and critics say Cooley just doesn’t get it (or virtual platforms and virtual prototypes for that matter)
• there are big opportunities for Software design, and EDA can play there
  • Embedded software has the possibility to double EDA, says Gary Smith, who has pointed to software as the problem for several years now
  • embedded software seats are growing but market is fragmented
  • software IP is of growing importance in the differentiation of SoC platforms
  • the programming models need to change for multi-core
  • multi-core and parallel computing programming models are still pretty low level, like assembly and micro-code
  • Mentor Graphics announced their acquisition of Embedded Alley Solutions, a leader in Android and Linux development systems, unveiling their new Android & Linux strategy
• System Level is big, particularly for SoC virtual platforms, architectural optimization and IP
  • the SPIRIT Consortium and IP-XACT has merged into Accellera, and there continues to be a need for better standards
  • IP still has a lot of potential and the business model is becoming clearer
  • Despite the importance of ESL, much work is still done at lower levels of abstraction
  • ARC International, the IP and configurable processor provider, is rumored to be under acquisition
• FPGA
  • Companies are moving to FPGAs and away from ASIC
  • ESL is big for FPGAs
  • Not nearly as much FPGA discussion at DAC as there should be
• Cloud computing opportunities are being underlooked by EDA (let’s start with the on-site private cloud then look at multi-tenant ecosystem clouds)

In conclusion, I was able to absorb a lot of details about DAC without attending thanks to all the bloggers, Tweeters and trade media.  EDA is changing in some exciting ways that scream opportunity for some and failure for others, and that’s what makes the future so exciting.

A quick snapshot on the poll described in my previous posting: “for System-on-Chip developers, where is the greatest hardware/software register interface pain?”

Of the 71 votes thus far, 59% indicated that synchronizing the firmware, RTL, hardware verification, and documentation was the greatest pain.  Then 16% voted for register documentation and 16% for hardware verification (like SystemVerilog, Vera, e, SystemC).  The RTL (like Verilog & VHDL) for coding the register-map hardware logic was a pain for 4% of voters and firmware was a pain for 2%.  The live version of the poll is available here, and below is a screenshot of the graph.

Snapshot of LinkedIn poll graph

 
That only 2% voted for firmware is surprising to me since when asked where greatest value was received, a SpectaReg.com register-map automation customer indicated that 50% of the value was provided to the firmware developer.  As a result, I would expect that anyone without a register code generation solution would experience a lot of firmware pain.  Perhaps that’s a synchronization pain and the proper solution provides more value for firmware than any other aspect as a result of cross-team synchronization.

For the 41% that did not vote for synchronization, perhaps they have no register map code generation solution, whether it be commercial or homemade.  Perhaps their solution does not sufficiently provide enough value for the option that they voted for.

For the 59% that voted for synchronization, I wonder:

• How many have a common machine readable data format for specifying registers that can used to generate code?
• How many auto-generate all deliverables from a common source at the same time using the same code generation (metaprogramming) engine.
• How many have an in-house vs. commercial solution (like our SpectaReg.com/SpectaReg Onsite or Duolog’s BitWise, Delani’s Blueprint, or Semifore’s CSRCompiler).

Many more polls could be created on these topics.

People are very passionate and opinionated when it comes to in-house tools, open source, register specification file formats, and register-map methodologies in general.   There was heated discussions on LinkedIn about the following topics, which make for good future blog posts:

• Open source tooling for register address maps, could it work?
• Is SystemRDL really needed in addition to IP-XACT?
• Which comes first, the code or the spec?
• With an in-house register solution, where’s the pain? (relates to Opportunity cost in build vs. buy decisions

If you have thoughts to share, be sure to leave a comment for discussion.  There is some good meat here for future RegisterBits.com postings so stay tuned.

Register interfaces are an essential pattern in chip design. They provide a way for sequential software to get information into and out of parallel hardware using memory address reads and writes. At conference many years ago (can’t recall if it was DAC or DesignCon) a panel was asked “what is the best way to measure the complexity of a chip?” One proxy mentioned was “the number of pages in the user documentation.” The register section is often the majority of the firmware programmers’ manual… confirming what you probably know… register interfaces are complex in a variety of dimensions.  For the average hardware RTL coder, the register interface is typically not viewed as an object oriented model.  We believe that IT SHOULD BE!

In the center of the `School of Athens' by Raphael are Aristotle and Plato, Aristotle's hand level to the Earth symbolizing his realism view of Nature; Plato's hand pointed towards the heaven symbolizing the mystical nature to his view of the Universe. This image symbols the sharp change in the meaning of how `natural philosophy' or physics will be done for the 2,200 years.

Object Oriented Programming (OOP) is well known for its ability to abstract complexity. A quote from Grady Booch (co-founder of Rational Software, IBM Fellow, and widely respected authority on software methodology) puts this into perspective:

… objects for me provide a means for dealing with complexity. The issue goes back to Aristotle: do you view the world as processes or as objects? Prior to the OO movement, programming focused on processes — structured methods for example. However, that system reached a point of complexity beyond which it could not go. With objects, we can build bigger, more complex systems by raising the level of abstraction — for me the real win of the object-oriented programming movement.[source]

If you took CompSci 101 you may have learned about the following principles of OOP:

• Inheritance - Classes of objects can be extended and specialized to reuse and override existing code.  For example, an InterruptBitfield inherits from BitField to extend it to have specific attributes and behaviour.
• Encapsulation - Classes of objects have data and methods that they encapsulate.  For example, a BitField has a bitWidth attribute.
• Polymorphism - Specific classes of objects should be able to play general roles.  For example, an InterruptBitField instance can also play the role of a general BitField

Certainly most SystemVerilog users for design verification will be familiar with OOP, but I’m not sure about the RTL camp.

In building a data structure for modeling the hardware register interface, an OOP language is preferred. We chose Python since it’s interpreted with decent object orientation.  It’s encouraging to hear that python is one of the 3 “official languages” at Google, alongside C++ and Java.

Another consideration with register automation, is how the specifications get persisted and exchanged? We were asking ourselves this question in 2004 when we learned of the SPIRIT Consortium which has a standard now know as IP-XACT, a XML Schema Definition (XSD) for SoC and IP metadata.  For OOP based register specification, we infer from IP-XACT the classes of objects shown in the following SpectaReg Specification Object Model (SOM) diagram.  The diagram is a UML class diagram that uses UpperCamelCase for defining the classes.  We’ll use this convention for referencing classes in this blog.

Specification Object Model (SOM) base classes from IP-XACT

This diagram of the SOM doesn’t show the new RegisterFile class of object which we’ll talk about another time.

In English the diagram reads as follows: A Component is composed of MemoryMaps which are composed of AddressBlocks, which are composed of Registers, which are composed of BitFields.  Or in the other direction BitFields exist within Registers, and so on.

There are many different “types” of Registers in the universe of hardware/software Register interface specifications. The type of a Register’s contained BitFields specifies how the Register behaves in software and hardware. Such granular typing permits BitFields in the same Register to have different types.

We’ll continue this discussion in an upcoming posting to illustrate how the SOM simplifies the complexity of register implementation for both RTL and software engineers.  This exists today at SpectaReg.com without requiring the user to write or install any software or feed any code into the register automation tool.

I met Gary Stringham, an embedded systems consultant, at the 45th DAC SPIRIT Consortium meeting in Anaheim where we demonstrated the SpectaReg web-app using IP-XACT.  Since then, I’ve been subscribing to Gary’s excellent Embedded Bridge monthly newsletter, which provides best practices for the hardware/firmware divide.  Gary is a big proponent for register module generation tools like SpectaReg and he recommends such tools as one of his best practices.

Issue #26, of the Embedded Bridge newsletter discusses level-triggered vs. edge-triggered interrupts and makes a good case for using edge-triggered interrupts. Why?  Well, because level-triggered interrupts are painful for the firmware engineer.  Level-triggered interrupts cause extra complexity, extra CPU cycles, and create a possibility for missed interrupts.

Consider the following example…

Imagine you are creating a packet receiver (PR) hardware component. When the PR processes an errored packet, it asserts a status signal (pkt_err_stat) until the next packet comes in. The following table shows the PR’s register bits, which are mapped into addressable registers and are all one bit wide.

When pkt_err_stat is asserted, an interrupt is generated (if enabled).   The interrupt causes firmware to vector to it’s interrupt handler, where it identifies that PR has an interrupt (since has_int for PR is asserted).  Firmware then reads PR’s interrupts to discover that pkt_err_int is asserted.

Level-triggered case: In the case where pkt_err_int is level-triggered and the next packet has yet to be received, then pkt_err_stat will still be asserted.  To exit the interrupt handler, the firmware must disable then clear the interrupt by writing one to it.  The issue now is… when does firmware re-enable the interrupt?  With the interrupt disabled, how does firmware know if the next packet is errored?  Answering these questions from firmware creates un-needed complexity.

Edge-triggered case: If pkt_err_int is an edge-triggered interrupt, then the firmware is simpler and less prone to missing back-to-back errored packets.  To exit the interrupt handler, the firmware simply clears the interrupt.  When the next packet comes in, if it’s errored another interrupt is generated and there is less risk of missing this event.

One objection to edge triggered interrupts, as Gary points out, is that they take up more logic gates.  When I read Gary’s level vs. edge triggered Embedded Bridge issue, I decided to look at SpectaReg’s generated VHDL and Verilog to see how we did our interrupts.  It turns out that we originally only had level-triggered interrupts.  To add support for positive edge-triggered interrupts, the RTL was pretty much identical to the level-triggered, it just required sampling the last value of the status (pkt_err_stat in the example) and using that to determine when to generate the interrupt. If the current value is 1 and the last value was 0 then the interrupt is generated.  This results in one additional flop per edge-triggered interrupt and a little more combinational logic.  The cost is insignificant compared to the benefit.

So…. all you Verilog and VHDL RTL developers, next time you go to create an interrupt bit do the firmware developer a favor and make it edge triggered.