Register Bits

Working for the past 6 years to build, grow, and sell SpectaReg, a tool for on-chip register management, I’ve discussed registers with a wide range of people. In explaining the underlying problem of registers and memory address mapping, whether the audience be technically lay or literate, I enjoy a good concrete analogy that people can relate to.

Here are some analogies that can be made for register management, each a potential topic for exploration in a future blog posting.

Register management has similarities to…

• order management in a restaurant — synchronizing order info between many different workers, each using common info in different ways
• building a house — different workers maintaining and working from a common blueprint, which may need to change or be revised over time
• the human nervous system — millions of finely identifiable/controllable sensory inputs and motor outputs wired to the brain

Undoubtedly, there are many other analogies that could be made.  I hope readers can leave some comments with other ideas.

Everyone in chip design uses a browser - there’s little doubt in that. I’d wager that most chip designers spend more time in a browser than in any other tool, including the command line, emacs or vi text editor, the Eclipse IDE, and the logic simulator.

Today, chip designers are likely to use a browser for:

• Looking at various indexes of technical documentation in HTML and PDF, including IP and register map specifications and document control
• Viewing development reports, test coverage data and analysis
• Researching suppliers, IP, algorithms, technical standards, how to articles, …
• Managing bugs
• Collaborating through a Wiki
• Accessing various other information on the corporate Intranet
• Reading EE Times and Slashdot while waiting for that long test-case, simulation or synthesis job to complete

Though not a chip designer anymore, I’ve been spending more time working in a browser, especially now that I’ve warmed up to Google Apps. And I’m not alone. I’ve even heard of some chip design companies using it too. Now that the word is out that Google is building chips, there is a good chance that they’d use Google Apps. Let’s face it, there is a lot of spreadsheet work in chip design and Google Spreadsheets is quite powerful, especially in a collaborative context. There is also a lot of block diagram work too and Google’s new Drawings tool offers hope there. Whether you like web-apps or not, I think most chip designers would agree, the browser is increasingly used for legitimate work.

There are many areas in chip dev where the browser can play a bigger role, especially in a collaborative context. One recent example, is Synopsys’ Lynx Design System which appears to have a browser GUI for it’s Management Cockpit. At PDTi we’ve been pushing the limits of using the browser for all things register management, for capturing and modelling the executable specification and generating dependent code and documentation.

Google has been pushing the limits of what is possible in the browser. The impressive video showing Quake II running in a browser is mind-blowing and highlights the possibilities of HTML5 and the next-gen browser. This supports the argument that graphical EDA tools such as the simulation waveform debuggers and graphical layout tools are possible and could be supplied as a web application; perhaps even under the SaaS model.

Are the naysayers missing something here - could the browser be the ubiquitous platform for everything, even EDA tools and Chip Design?

Meeting and talking with customers about their register needs and requirements is one of my favorite things to do.  Not too long ago I met with an embedded firmware guru over coffee and we discussed various topics about registers and register management tooling.  We discussed registers in the context of multi-processor system on chips (MPSoCs) with a lot of different interconnect channels or bridges and buses. In such a system, where there is concurrent software that may access the same registers, we discussed the pains of read-modify-write and how to reduce the need for such operations.  Some of our conclusions on this are discussed in this posting, which was spurred by one Gary Strigham’s recent Embedded Bridge issues.  Gary has hinted that his upcoming issue will discuss “an atomic register design that provides robust support for concurrent driver access to common registers” and I’m curious to see how his techniques compare to the ones discussed herein.

What is  a register read-modify-write operation?

Firmware often needs to modify only one single bit or bit-field of an addressable register without modifying other bits in the register.  This requires the firmware to read the register, change the desired bit(s), then write the register back.

Problem 1: Atomicity for register read-modify-write operation

In a system that has concurrent software accessing the registers, read-modify-writes are a real concern.  Without proper inter-process synchronization (using mutexes or some other form of guaranteed atomicity) there is a danger of race conditions.  These dangers are well described in Issue #37 of Gary Stringham’s Embedded Bridge.

Problem 2: Latency of read-modify-write operations

In a complex MPSoC, with a complex interconnect fabric, register read operations can be painfully slow when compared to pure register write operations.  System performance can be greatly improved by reducing the number of read operations required.

How to trade register read-modify-write transactions with a single register write

The trick to replacing the need for read-modify-write of a register with a register write operation is to create additional CLEAR and SET write-only registers.

Consider the following FLAGS register as an example which uses 8 bit registers for simplicity sake.

Without any supporting CLEAR/SET registers, to modify flag_f would require a read-modify-write operation. However, when we add the supporting CLEAR and SET write-only registers and related RTL logic then each bit can be set or cleared independently.  The flag_f bit can be set by writing 0×04 to FLAGS_SET and cleared by writing ox04 to the FLAG_CLEAR register.  The following table shows how the three related registers would look.

Here the complexities of read-modify-write in a concurrent software environment are traded for additional complexity within the Verilog or VHDL RTL code, and the related verification code. A register management tool like SpectaReg can be setup to allow easy specification of such register patterns in a graphical environment and auto-generation of the related RTL, verification code, and the firmware abstraction of the bits. With such a register management tool, the related work is greatly simplified when compared to the tedious and error-prone process of doing it manually.  An additional advantage relates to architectural exploration - with an automated path between the specification and generation it’s much easier to switch between the two techniques: i) a single read/write register requiring read-modify-write, and ii) a read only register with supporting SET and CLEAR registers.

In addition to register read-modify-writes discussed at the coffee talk with the firmware guru, we also chatted about how specialized hardware registers offer valuable diagnostics, performance profiling, optimization and debugging of MPSoC systems - perhaps a good topic for a future posting so stay tuned.

Lastly, if you have any thoughts to contribute, be sure to leave a comment.

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.

While on an ocean side walk, I daydreamed of being struck by a great IP/subsystem idea with potential for royalty licensing.  I imagined organizing a team and jumping into action, developing the RTL logic, and processor integration.  Should I choose Virtual and/or FPGA prototyping?

ocean side walk

Virtual Platform

It’s all about getting the software working as soon as possible.  The Google Android Emulator is an excellent example of how Google was able to get the software working without requiring developers to possess the device hardware.  The Android Emulator is described as a “mobile device emulator — a virtual mobile device that runs on your computer.”  Android abstracts the hardware, ARM processor, and Linux kernel with an Eclipse based Java framework, targeting Android’s Dalvik Virtual Machine, a register-based architecture that’s more memory efficient than the Java VM.

Virtual Prototyping

Clearly the virtual Android emulator/platform makes software development easier. Similarly, a virtual prototype makes abstract product validation easier. With a virtual prototype, the developers can explore different algorithms and architectures across the hardware and software abstractions.  Things like instruction set, on-chip interconnect, acceleration, memory, interrupt, and caching architecture can be explored by digital designers and firmware ahead of the VHDL and Verilog solidification.  Still, despite any effort spent on virtual prototyping, physical validation is essential before offering an IP for license.  FPGA prototyping is a good choice for all but the most complex and highest performance IP.

FPGA Prototyping

Those who know firmware and RTL coding, should have no problem getting basic examples running on an FPGA dev kit in the first day or two.  Those with experience validating a chip in the lab understand that so much really comes down to using embedded software to drive the tests.  Today’s Embedded System FPGA kits provide on-chip processors and the whole development environment.  Some available embedded FPGA processor options are listed in the following table:

Short of having deep pockets for an ASIC flow, or a platform provider lined up to license the IP and spin prototype silicon, FPGA prototyping makes good sense.  Virtual platforms make sense for reaching software developers, so they can interface with the IP as soon as possible.  One problem with providing models for developing software before the hardware is complete is that it’s difficult to keep the different perspectives aligned as the design evolves.  Tools like SpectaReg that model hardware/software interfacing and auto-generate dependent code keep the different stakeholders aligned, resulting in quicker time to revenue for the IP.

So back to my oceanside daydream… how would I get the IP to market and start making money?  It depends on the target market.  If the end user targets embedded system FPGAs then it’s a no brainer - go straight to FPGA prototyping and don’t worry about virtual platform.  If the target market is mobile silicon platforms, then virtual prototyping/platforming makes sense.  Having validated silicon in hand is ideal but impractical in many circumstances. FPGA prototyping is pretty darn compelling when you consider the speedy turnaround times, and the low startup costs.

A SpectaReg.com 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.

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 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, 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.