Register Bits

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?

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:

• SaleForce.com
• 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

Presenters:

• Harry Gries (Design Methodology Consultant @ the ASIC guy)
• James Colgan (CEO @ Xuropa)
• Susan Peterson (Verification IP Marketing Manager @ Cadence)
• Jeremy Ralph (CEO @ PDTi, yours truely)
• Bill Alexander (VP Marketing @ Blue Pearl Software)

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.

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.

My typical day starts with a cup of coffee while I check email and browse the EETimes homepage.  Recently, I read an article entitled Rhines challenges pessimistic prognosis for EDA, which describes a DesignCon keynote by Walden Rhines, Mentor’s CEO/Chair.  The following segment from the article stuck with me:

Rhines pointed to a bright future for EDA, despite the doom-and-gloom that surrounds the industry. The number of chip designers in the world is growing he said.  While he [Rhines] joked that not all of the designers are acquiring EDA software legally at the moment, he said their companies would likely “clean that stuff up” as they matured in places like China, India and Eastern Europe.

For the most part, SaaS solves this issue — piracy of EDA software becomes a non-issue when tools are offered as a SaaS since the vendor has complete control.  The  software binaries don’t get transfered, so they cannot be pirated.  Also, as the number of chip designers in the world grow, SaaS is well positioned to achieve the required economies of scale and reduced cost structure to serve emerging markets.

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:

Which functional verification methodologies are you (or your group or your company) planning to use on future projects?

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!

We’ve decided to start a corporate blog at PDTi.  This inaugural posting is about something that’s near and dear to our hearts – using Software as a Service (SaaS) web applications for solving chip-development register automation needs. The most compelling benefits in using a SaaS business model for EDA include:

• Simplified use, support and maintenance
• Lower cost structure
• Expanded collaboration

By register automation, I’m referring to a class of tools that takes in addressable register specifications for defining the hardware interface.  This is the hardware interface that gets read and written by software.  This type of register interface goes by many different names.

Simplified use, support, and maintenance benefits come from the fact that the SaaS user can run the tool using a web-browser.  Users simply point their trusty browser to a URL, and login.  The tool vendor has complete control of the server hardware and software.  The vendor can add enhancements and fixes seamlessly, saving the end user a lot of work.

One obvious constraint with the SaaS model is data transfer requirements.  For the front-end of chip design, file sizes are not such a big issue since plain text VHDL, Verilog, SystemVerilog, and C/C++ files are relatively small.  For transferring larger files, like back-end physical design databases, the average HTTPS client/server connection may not be ideal.

Another factor that always comes up with SaaS is security.  One benefit with web-applications is that a lot of big enterprises have put a lot of money and time into how to secure web servers, and there is a lot of common knowledge in this area.  An enormous number of transactions per day occur securely over HTTPS around the world.

Intense vendor specialization and economies of scale provide the benefit of a lower cost structure.  Vendors know how to best develop, run, and maintain the tools they build.  With the vendor actively maintaining the tool, the cost structure can be lower for all parties.  Sharing the server-side compute resources among many users maximizes utility, reducing the compute nodes per user/project/company.  This also reduces the environmental costs of having un-utilized servers running.

The need for better collaboration in the chip-dev supply-chain is growing and SaaS helps to expand collaboration.   More companies are buying IP, selling IP, outsourcing work, using open-source projects, and in general collaborating with customers, partners, and suppliers.  The client/server architecture of web applications makes it possible to formalize this collaboration and make it consistently repeatable.

We have no doubts that register design automation is well suited for a SaaS business model.  In future postings we’ll examine what other types of existing and future EDA tools align with the SaaS model. If you have any thoughts on this leave a comment and let us know what you think.