This is a technical posting for the firmware readership.

One of the most elegant ways of expressing register bit-fields in C/C++ firmware is using a union of a struct with a register word.  The problem with this is that there is no standard way for representing the bit field packing/ordering in C/C++, which restricts portability across compilers and architectures.  For the simple traffic light controller (TLC) example with the register-map shown here, the LightState Register’s Green, Amber and Red bit-fields can be represented as shown below, assuming most to least significant bit packing.

    struct {
        volatile unsigned : 29;
        volatile unsigned green : 1;
        volatile unsigned amber : 1;
        volatile unsigned red : 1;
    } fields;
    volatile u32 reg;

If the bit-order packing is reversed, then it needs to look as follows:

    struct {
        volatile unsigned red : 1;
        volatile unsigned amber : 1;
        volatile unsigned green : 1;
        volatile unsigned : 29;
    } fields;
    volatile u32 reg;

The reversal of the bit fields can be done using auto-generation based on a bit-ordering condition with a register automation tool like SpectaReg.  For non-generated static code, it can be accomplished using #ifdefs, and sometimes compiler pragmas.

The most portable way to deal with register bits in C/C++ is NOT to use this struct/union fanciness — instead do the required masking (and possibly shifting) using bitwise operators.  SpectaReg produces both the struct/union format and also the shift/mask format. How does the RegisterBits readership do it?

EDA Veteran Paul McLellan recently wrote an entry in his EDA Graffiti blog entitled SaaS for EDA.  Being a vendor providing the only real SaaS tool for register automation, I was naturally excited. I was a bit less enthused when McLellan indicated on twitter (he tweeted) that he didn’t think SaaS for EDA would fly.  Upon reading his blog posting, it seems his position is more along the lines that SaaS for EDA will not fly for the traditional, EDA bread and butter applications.  He did indicate that SaaS for EDA does have a chance for the front-end of chip design and for FPGA flows.  This is good to hear because it aligns with our coordinates at PDTi, where we focus on the firmware/software register interface.

I started to write a comment for McLellan’s posting but soon realized that I had a lot to say - more than should really be put in a comment.  Hence I decided to write this RegisterBits blog entry.

In general, I know about the front end of EDA tool-flows and not much about the back end.  That being said, having worked with complex IC development flows at Intel and a smaller startup, I understand how there is a common back-end flow and files are large.  At the RTL level and above it’s not so clear cut, there are often many different point tools, files are small, and each project can use a different set of tools and scripts.  Whether a point tool runs on the local machine or remote machine really makes no difference in this case, with negligible files sizes and local scripting environments that can access remote point-tools using web APIs.

McLellan assumes a tool/hour pricing model, and claims that using a metered usage pricing would not cause prices to go down.  With SaaS, however, there could be many different pricing models that better align the value between the user and vendor.  Pricing could be based on a project, per-user, or per unit of complexity (register, gate, area, …).  If the fabs were to take hold of the SaaS model and offer EDA tools, since they know the production output they could even use a royalty based pricing model.  If you look at the current EDA floating seat model, the longer jobs run for the more seats sold, and the more money for the EDA companies.  Could it be that EDA vendors using a per-seat model don’t have the incentive to improve runtimes as much as they could?

Another objection is that SaaS doesn’t work well with highly interactive software.  This has been true in the past, but is less and less true all the time with AJAX rich-client applications like Google maps.  If Google maps can do the magic that they do then I would argue that place and route and graphical waveform viewers are reasonably possible today.  For the most part, though, there is very little graphical instructiveness in EDA.

Perhaps the greatest SaaS for EDA benefit is the opportunity to reduce the maintenance and infrastructure costs that are so high for the traditional on-premise tools. Installing, patching, and upgrading EDA tools is a huge cost that must be considered into the total cost of ownership.  SaaS ends the customers’ maintenance of the application and enables the customer to focus more on value added differentiating work while the vendor manages the maintenance.  This is much more economical and cost effective. CEO Marc Benioff circulated an internal note related to the “End of Maintenance,” which is an excellent read on this very topic.    Then, there is always the argument that chip designers want to control what version of the tool they are using so everything is repeatable.  There are ways this can be built into the SaaS offering, and at PDTi with SpectaReg, we’ve got a way to do this.

Referring to the Innovator’s Dilemma and the way disrupted the CRM market, McLellan states that EDA is not like CRM since there is no “non-competition” - under-serviced users who don’t currently have access to a tool due to it’s cost.  “EDA is not like that,” he said.  I, however, think there are certainly aspects of EDA that are like that, especially with new and innovative tools.  Register automation, where we at PDTi are focused, is one such area.  We often encounter customers who don’t have any solution (in-house or commercial), who could certainly use a solution.  There are a number of users in developing economies starting to work with EDA tools for ASIC and FPGA, who are waiting for better “legal” access to tools.  There is the embedded software industry that is starting to realize that they can use FPGA embedded processors platforms and build custom (multi) processors chips for their specialized application.  This is a new underserviced market for EDA.  It amazes me how the EDAC is so hyped up about trying to stop piracy of EDA tools, which seems futile since the hackers will almost always be able to crack or cheat the next attempt to stop them.  SaaS, however, does provide a solution to the piracy issue.  To expand into these highly price sensitive markets, EDA will need to compete on price, like it or not.

While competing on price is not ideal, SaaS has the potential to afford a better cost structure for both the producer and consumer.  More than the tool price needs to be looked at to get a true picture of the total cost of ownership.  The traditional EDA sales channel is super expensive and unnecessary in today’s Internet age.   The evaluation processes are too lengthy and difficult, the tool version release milestones are too long, onsite tool support is expensive, and the customer’s maintenance and infrastructure is very costly.  The cost of having CAD engineers worrying about tool setup and maintenance is more than just the associated labour cost - there is an opportunity cost of not focusing as intensely as possible on core competencies. A SaaS tool can evolve better based on aggregate vendor observations of usage patterns.  Also, it’s easier for the customer and vendor to work together to identify, reproduce and fix bugs.

There is much knowledge in EDA that is not packaged in an automated collaborative way.  Lincoln Murphy from 16 Ventures and Ken Boasso of Keychain Logic predict that 80% of SaaS success stories in the future will not be the CRM or ERP leaders of today’s SaaS, but rather productization of knowledge.  There is a lot of knowledge in EDA and chip design that has yet to be productized — the kind of stuff you find in the scripts, processes, procedures, emails, spreadsheets, and documents at a typical chip design company.  This could potentially be formalized into SaaS tools with a user community and network effect.

Utilizing the power of native web-applications, SaaS can bring about a new class of tools for EDA that use the Internet to help managers manage, and engineers collaborate across teams and locations.  Perhaps like a social networking application, but not social, instead it’s engineering workflow networking around the project work, tools and flows.  This is something that we’ve had good success with for our tool.  Memory mapped registers are collaborative and we tie all the stakeholders together in a formalized way.  This isn’t traditional EDA - it is a work-flow automation for electronics design, perhaps a new class of EDA that productizes what has traditionally been un-productized knowledge.

If you’re interested in EDA for SaaS be sure to join the EDA SaaS Enthusiasts LinkedIn Group.  If you are doing firmware/hardware addressable register maps, try a free demo/evaluation of

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.

SoC Hardware/Firmware register interface pain poll

Snapshot of LinkedIn poll graph

That only 2% voted for firmware is surprising to me since when asked where greatest value was received, a 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 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 postings so stay tuned.

Did you know that LinkedIn allows users to create polls?  I discovered this today and created my first poll to ask my network of SoC developers where their greatest hardware/software register interface pain lies.  Is it the firmware, RTL, hardware verification, documentation, or is it synchronizing all the different perspectives around the common specification?

Click on the below image or link to have your say!  Tell your colleagues too, and of course if you have a comment for discussion post it here.


LinkedIn SoC Register Interface pain poll.

Update: Someone mentioned that they don’t understand the poll because they have an in-house solution that solves these pains. For those with an in-house solution, read the poll as “where is the greatest value from your in-house solution?” I suppose a sixth option, “my in-house solution is the biggest pain” should have also been an option too, especially now that there are commercial solutions available.

In engaging with companies about register-map automation, it amazes me how many engineers think that because they have an in-house register solution, or because they could build one, that this route makes the most sense. Although there are some people that get it, quite often engineers fail to take opportunity cost into consideration (sunk costs too, but I’ll cover that in another posting). I’ll explain via an example…

Picture this; an engineering team needs a register automation tool for developing a new ASIC that is the highest performance XYZ. Their options are:

  1. License one of the commercially available register tools
  2. Build a register generation tool from scratch, or
  3. Do the registers manually

The engineering manager estimates the costs of the different options using an hourly rate per engineer vs. the licensing costs for the commercial tool. Due to the fact that the commercial tool is shared among several companies who subsidize its ongoing development, it’s priced lower than the cost of creating an in-house solution. For argument sake, though, let’s assume that somehow the manager estimates that option 2 is cheaper by some accounting magic. Forget about option 3, the ASIC has way too many registers to do manually, so that’s out of the question.

The engineering manager chooses option 2 because, in this strange, imaginary, upside down world of magical accounting, the cost of building an in-house tool is less than the cost of buying a commercial one. Reasonable right?

Wait a minute, maybe not…

The company’s core competency is building high-performance XYZ products, not building, testing and supporting tools. That tool building dilutes focus. What is the cost of forgoing the opportunity to focus as intensely as possible on building the best and highest possible performance XYZ? That’s a bit harder to quantize, but it is a cost. That’s the opportunity cost!

What happens if the competition chooses option 1, and smokes the company in terms of performance? How much does that cost in the long run?

If the manager had decided to go with option 1 — licensing a commercial register tool — that would enable the team to focus more effort on building a better, higher performance XYZ product. That extra focus would enable the company to be more differentiated from their competition, ensuring their dominance and their ability to demand higher profit margins. It’s this differentiation that provides competitive advantage in the marketplace.

One other way to think about it is that differentiating value-added efforts have a greater return on investment (ROI) than non-differentiating efforts.

Something to think about, next time you have an option that would enable more intense focus on differentiating core competencies.

Stay tuned for more postings on the economics of build vs. buy engineering decisions.

This posting examines how object-oriented typing of BitFields abstracts implementation details, and provides extensibility and simplicity.  This is the second in a series of postings.  The first posting provided background info on using object orientation for register specification and code generation.

With SpectaReg, one of the questions that always comes up is “how do I specify the type of register?”

How does one specify that a particular BitField is a read-only status bit, vs. a read-write flop-based control BitField vs. some other type?  With the SpectaReg register generation tool…

  1. Register type selection is easily done using the web GUI (or through XML)
  2. Register typing is generally done at a BitField-level of granularity
  3. Types are defined in an object oriented hierarchy
  4. Types can have custom attributes including references to other instances
  5. New types/classes can easily be added with some open Python
  6. The code generation layer works at the most abstract level that is applicable, to maximize core reuse (thanks to inheritance and polymorphism)

A clarifying example:

To keep things simple, assume an SoC team only uses three types of BitFields in their register maps as defined by the following table.  In reality there would be many more types.

Type Name Type Description
ExportedFlopBitField A basic read/write control BitField.  This is implemented with flip-flops and has an output wire/signal from the register module that goes into the application specific logic.
WatchedExportedFlopBitField Same as the ExportedFlopBitField except this has an additional output wire/signal that goes into the application specific logic and pulses high when a write transaction is decoded.
ExtDrivenBitField A basic read only status BitField.  This is an input into the register module from the application specific logic.

Now, in SpectaReg’s Specification Object Model (SOM) these types of BitFields would be mapped into the following class hierarchy, all inheriting from the BitField base class (i.e. the IP-XACT field element).

Register BitField Class Hiearchy

Register BitField Class Hierarchy

The WatchedExportedFlopBitField is a specialized type of ExportedFlopBitField, which is a type of ReadWriteBitField, which is a FlopBitField, which is a type of BitField.  As is typical for object orientation, “is a” represents inheritance relationships.

Say the user wants to create a new WatchedExportedFlopBitField in an unused bit-space of an existing register.  The user would create a new BitField and tag it with the specific WatchedExportedFlopBitField class using the GUI widget shown in the following screen shot.

BitField Class/Type Selection Widget

BitField Class/Type Selection Widget

At the code generation layer, such inheritance-based typing really simplifies things.  For creating the synthesizable Verilog and VHDL RTL code, the generation layer needs to know specific class typing to create the implementation of the WatchedExportedFlopBitField.  For the firmware and documentation generation, such detail is not required, so the code generation can work at a more abstract ReadWriteBitField classification level.  This is the beauty of polymorphism — the code-generation templates that need specifics can get into the details whereas the ones that don’t can keep it simple.  Keeping it abstract leads to more re-use and less complexity.

Of course, SpectaReg supports many different types/classes of BitFields other than those dicsussed here.  What Register and BitField types do you use in your design?

looks like an engineer styled it

A customer, generally happy with the user experience and beneficial value of the register-map tool, indicated that if we want to win more customers, we should think about improving the styling.

Looks like an engineer styled it.

Before restyling.

“It looks like an engineer styled it,” the customer said.  “It needs more rounded corners.”

Being a practical engineer, all that really matters is functionality… right?

Well, not entirely.  To get that first date, one needs a bit of style.  Certainly, a company like Apple spends a good deal of time and money on style, and they get results.  In the world of snowboarding, skateboarding, and surfboarding, style is paramount — executing the most difficult move doesn’t earn street credit without style.

“There were surfers with good style… and there were surfers that we would call cockroach style, or no style,” said Jim Muir in the legendary skateboard documentary Dogtown and Z-Boys. “If you had a bad style… right there you had one mark against you…”

Our user was telling us that we had one point against us, so a web style consultant was challenged to help improve SpectaReg’s style without requiring radical changes to the underlying code.

After Restyle.

After Some Restyling -- rounded tabs, new icons to replace text links, etc.

A little time and effort on style really made a big difference — we don’t want cockroach style and we’re improving on it more and more.

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, Aristotles hand level to the Earth symbolizing his realism view of Nature; Platos 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.

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

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 without requiring the user to write or install any software or feed any code into the register automation tool.

SaaS & Cloud for EDA Presentation

The following presentation was prepared for the first SaaS and Cloud Computing round table at DVCon 2009.  Thanks Harry for organizing and coordinating!

It was strange to prepare this and not be there to engage with the audience for Q&A. Let’s get some comments and discussions going here using the comment feature.  What do you think about SaaS in general and for EDA?

Cloud Computing and SaaSHarry the ASIC guy, has organized a meeting at DVCon for discussing the inevitable way forward for application deployment and computing infrastructure — SaaS and Cloud computing.

The incumbent EDA overlords, being a conservative bunch with an arsenal of tools that haven’t been architected for such deployment, have been slow to catch on.  That is understandable, why would they want to change the way things are done and disrupt their entire business models?  They would need to completely change their core competencies, values, sales channels, and architectures if that’s even possible.

The EDA users, well … , it seems many are trying to figure out what the heck SaaS and Cloud Computing are. Here are my definitions for these terms:

SaaS — Software as a Service, whereby the user does not download or install any software.  Instead, the software is hosted by a service provider and available on-demand, as a subscription or pay-per-use over the Internet.  Some (like Cadence) consider the case where a VPN client is downloaded by the client and configured for accessing hosted software a SaaS too.  My definition of a “Pure SaaS” is that it must run only in a web-browser, as our register-map tool does.   Poster children for SaaS include:

  • Google Apps
  • TurboTax (QuickTax for Canadian readers)
  • Oracle
  • SAP

Cloud Computing — The concept of having massive common compute infrastructure, offered over the Internet, and shared and optimized between  many different users and services for many different purposes.  The Cloud host maintains the compute infrastructure and essentially leases compute resources (like CPU nodes, time, memory, bandwidth, and disk space) or specialized services based on some level of granularity.  The Could essentially abstracts all the hardware, services, and related back-end work.  Amazon has a big initial presence in this.

At PDTi we’ve been working towards building our SaaS for more than 4 years.  At first we didn’t call it a SaaS, we just knew that we were building a web-application.  When we first heard the term SaaS, we hated it and were reluctant to use it.  One of my business advisers put me onto the term WebWare which I think would have been much better.  Unfortunately WebWare didn’t catch on but SaaS did.

Anyhow, Harry has been following PDTi for a while now, and is very keen on SaaS, cloud computing and how these can be applied to EDA.  Harry invited me to present at the DVCon roundtable, and I am honored to accept.  Being a web-based company, though, remote to the Silicon Valley, we’ve decided not to attend DVCon or even have boths at most conferences… for us that is old school EDA and leads to a higher cost structure.  Using the web, wherever possible, instead of costly business travel, we can achieve a lower cost structure and can pass along the savings to our customers.  So if PDTi isn’t attending DVCon, how can I present?  We’ll I’m going to pre-record my presentation, send it Harry over the web and take questions as comments on this blog, as twitter messages, and via email.  I’ll post the recorded presentation online for all to see, after the event.  Wait, actually, we will have someone live at the event, one of my business advisors from the Valley, Michale Sanie, will be in attendance.

Here are the details of the Details of the SaaS & Cloud Computing EDA RoundTable:

When: 6:30 - 8:00 pm on Wed Feb 25th

Where: Monterey/Carmel rooms at the San Jose Doubletree Hotel


More details are available at Harry the ASIC guy’s blogMany thanks to Harry for or organizing this exciting event!

If you’re wondering how this relates at all to design verification, well does auto-generate SystemVerilog Register Abstraction OVM and VMM RAL SystemVerilog from the common register Specification.