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:
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?
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 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?
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.
|reg name||bit 7||bit 6||bit 5||bit 4||bit 3||bit 2||bit 1||bit 0|
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.
|reg name||bit 7||bit 6||bit 5||bit 4||bit 3||bit 2||bit 1||bit 0|
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.
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.
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:
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:
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!
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:
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.
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.
Harry the ASIC guy recently did a posting on survey results from past DVCon conferences. Harry listed percentages for languages used for design, verification, and property specification. Having attended DAC 45 in Anaheim, I couldn’t help but notice all the buzz about the newly open-sourced VMM and OVM SystemVerilog verification methodologies (both of which we now support). I commented that it would be interesting to know the popularity of OVM vs. VMM. Harry picked up on this and has since created a poll at Doodle that poses the following question:
The poll has the following choices: VMM, OVM, AVM, RVM, eRM, Teal/Truss, Home Grown, Native SystemVerilog, Native Vera, Native e, Native VHDL, Native Verilog, and Other.
Click on the above-hyperlinked question to view the results and participate in the poll. As it stands now, there have been more than 100 participants and OVM is winning. There could be some possibility for vendor manipulation, given the way Doodle works… hopefully people play fair.
Props to Harry for creating this poll!