BlogTransformation of a hardware electronic design automation (EDA) solution to a SaaS

In the hardware and semiconductor industries, engineers routinely use electronic design automation (EDA) software tools to accelerate the large amount of work required to release highly-integrated hardware products that will both meet the needs of their customers, and can be successfully productized in volume. Many traditional EDA solutions are deployed as computer- or server-installed software, used via the command line and/or GUI. By contrast, many of today’s modern software applications are released as software-as-a-service (SaaS) solution offerings in the cloud, accessed by a light-weight web application or browser. As with any important decision, there are pros and cons, but indeed some EDA solutions may benefit from a migration to this model.

We have been working with the OpenROAD project out of the UCSD VLSI CAD Laboratory to transform their installed software into a cloud SaaS solution. We thought it would be worth taking a step back to talk about considerations when planning out such an endeavor.

What is unique about EDA software?

Let’s first discuss what sets EDA tooling apart from most other installed software applications used by businesses:

1. They are normally computationally intensive thanks to the under-the-hood algorithms that provide a great deal of value to the engineers using them.
2. There are no monolithic EDA applications; instead, they exist as separate installed tools, each supporting a specific set of engineering activities in the flow of designing hardware.
3. Commercial EDA tools are traditionally sold and managed via licenses which govern overall feature availability, and all the users normally have the same access to this capability.
4. They are used on large screen devices, such as laptops, desktops, and workstations. Engineers use them via a GUI or command-line, and not normally via tablets and phones.

We considered all of these unique characteristics when planning ahead for the OpenROAD SaaS transformation. At the same time, we also realize that some items are up for rethinking, and therefore this is not a hard list of requirements that must carry over to the SaaS. From here forward, we will elaborate our thoughts about migrating this installed product for the cloud.

Big architectural decisions affect everything

When transforming any installed application to a SaaS, it is not a matter of rewriting some code; the changes are foundational at the architectural level. The previous software implementation will be effectively split apart into services accessed via APIs to separate the duties within the SaaS. The solution’s infrastructure will transition from customer-hosted to vendor-managed on slices of rented hardware. Even the expertise of development and devops teams must transform to work within this new model.

While not a comprehensive list of all considerations for any such project, here are a few areas evaluated for this particular migration:

Security tolerance and tenancy: Hardware companies treat their designs, including the output of EDA tools in the design flow as highly-guarded intellectual property (IP). We readily anticipate businesses will have significant anxiety for any SaaS architecture that doesn’t guarantee that one customer’s IP is kept physically separate from all others. One key SaaS decision point is how data and resources are separated via a selection of single-tenanted or multi-tenanted architecture. While at first blush, it may seem the single-tenancy model is most appropriate, there are variations in the multi-tenanted model that can still silo key customer data while retaining the efficiencies and cost benefits of this shared architecture.

Cloud support: Depending upon the customer’s existing business relationships, providing flexibility to choose commercial cloud providers (e.g. AWS, Google Cloud, etc.) can be a deciding factor. In addition, certain customers may have contractual restrictions that prohibit use of public clouds, and thus the only options are a private cloud or complete hosting within a specific data center. These latter options can present additional complexity for deployment, even requiring a significant setup cost for these types of clients.

Scaling and leveraging containers: One primary advantage of the cloud is the ability to scale compute, data, and other types of storage resources on demand. In practice, scaling requires separation of duties for the solution. For OpenROAD SaaS, we consider the application itself segmented into various pieces, each which can scale on their own via deployed containers. For instance, a management interface is where the user logs in and manages their hardware designs, and a separate job controller application is responsible for executing design compilation jobs in the cloud. By segmenting the responsibilities over multiple service applications that can run and scale independently, we enable an efficient use of resources. For example, the jobs – the computationally-heavy processes – live in their own containers on separate hardware, and prevent any bogging down the management interface used by the engineers for other tasks.

Licensing, Features, and Roles

Company-wide, site-wide or individual user licensing schemes are often employed by traditional EDA software, and must be rethought with a SaaS migration. Because the SaaS infrastructure is managed by the vendor through their cloud provider(s), variable costs are incurred which are normally passed along via a recurring subscription. This model also simplifies the customer management process, since license keys are replaced by tenant administration interfaces centrally managed by the vendor. Collections of features can be packaged together in bundles and sold in tiered levels or as other add-ons, enabled immediately upon payment. This certainly simplifies feature management over installed software, and provides a great deal of pricing model flexibility for the vendor.

Additionally, as opposed to most installed software applications where there is one type of user, most SaaS solutions will support different types of users, distinguished by their roles. For instance, in OpenROAD SaaS, we envision not only engineer users, but also different levels of customer administrators who are responsible for self-management of the company’s user base, for accounting review and payment, monitoring tenant statistics, security alerts, and more. By restricting users to certain roles, the SaaS vendor enables flexibility in their arrangement with customers (e.g. subscription pricing for certain user roles), and more importantly, roles keeps users within the bounds of their responsibilities in the system.

Rethinking target devices

As we noted earlier, traditional EDA software is used via a laptops, desktops, or workstations. However, in the “new world” we can certainly envision use cases where engineers can make use of a tablet or mobile. For instance, when multiple, lengthy design jobs are run by the engineer, and he/she goes out to lunch, it’s conceivable that an occasional check-in on the job status, or even rerunning a job that failed is desirable via a mobile interface. For OpenROAD SaaS, we designed exactly this capability into a mobile version.

In many enterprise SaaS solutions, all the features presented one device are not necessarily available for another device. For instance, the smaller screen size on mobile phones is obviously prohibitive for some types of operations that require a larger viewable area. However, by focusing on the jobs-to-be-done by users of each role, we design features that support those specific needs, while not overcomplicating the interface with features that clearly cannot be used effectively.

Wrap-up

Our work with OpenROAD on the transformation of an installed EDA application to a SaaS solution highlights the complexity that must be managed under the hood while presenting a usable, simplified customer experience. It’s important to realize that decisions about SaaS architecture, user roles, and target devices indeed are foundational and necessary to consider during any installed software to SaaS transformation process. Both user experience and customer experience are inextricably linked to these key decisions since they equally contribute to how customers will use the SaaS, and how the vendor will manage it. Whether building a new SaaS or migrating an existing product like an EDA solution to the cloud, going into this process with a partner who has done this before will set you up for success while avoiding costly mistakes.