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.
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.
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.
Harry 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 SpectaReg.com register-map tool does. Poster children for SaaS include:
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 blog. Many thanks to Harry for or organizing this exciting event!
If you’re wondering how this relates at all to design verification, well SpectaReg.com does auto-generate SystemVerilog Register Abstraction OVM and VMM RAL SystemVerilog from the common register Specification.
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!