SoC Design Management Software: Proprietary Vs. Open Source

These days, there’s a tendency to read the word “proprietary” and think “bad,” as if whatever is proprietary is inflexible and limited capability. It’s a legacy from the emergence of open-source software, when “open” became associated with progress and “proprietary” became bad.

But in many industries, proprietary solutions to this day have enormous value, deliver trust, security, reliability and scalability. SoC design management (DM) is one of those areas. In this area, proprietary carries an even greater value because of the enormous stakes (and cost) that come with each design project.

Nonetheless, the open-versus-proprietary argument still lingers in our sector, especially when it comes to DM technology.

Optimizing for an industry
Design management software has been used for a longer time by the software industry as opposed to the hardware design teams. As hardware and software teams grow closer together, there can be a temptation to embrace solutions from the software industry that aren’t necessarily (or easily) optimized for SoC design. Ultimately the decision to adopt a solution can come down either to cost or efficiency.

Case in point: Some of the commercial DM solutions in the semiconductor space are actually layers of glue logic added to solutions designed for the software industry. This has value for some teams such as the software and some front-end engineering teams. But what works for the software industry (and software engineers in your company) does not always work for the different types of designs in the semiconductor industry.

Why? Software consists primarily of small text files often edited by users concurrently with frequent merges of changes. SoC design flows, on the other hand, comprise a combination of text based RTL files and large binary files in addition to the large text files generated by the tools. The need for concurrent changes and merges by multiple users assumes less relevance. The emphasis is more on ensuring performance while managing large data sets across multiple sites, data security, optimizing disk usage and EDA tool integrations, to name a few. Data management systems built as a layer glued on top of a software configuration management (SCM) system often have to work around the SCM system to cater to the needs of hardware designers, such as fast workspace creation or optimizing disk space.

Let’s take, for example, network disk space usage & optimization. When a workarea is created with a SCM solution, a copy of the data is retrieved from the design repository and copied into the user’s workarea as physical files. A user typically will modify only a handful of the design files in his workarea while utilizing the rest of the design data files simply as read only objects often required to run simulation and/or verification jobs. In a project with multiple users, you can see how redundant read only data is duplicated across workareas! This is a bigger problem in SoC design flows as compared to software design flows because of the size of the design files.

DM solutions using an underlying SCM resort to using Linux kernel-level changes by developing proprietary file system or custom hardware to optimize the disk space. These techniques compromise the stability and integrity of the IT infrastructure by introducing non-standard parts and can be a major headache for the IT staff. As a result, most companies using SCMs for hardware designs avoid using this feature altogether.

We take a different view at ClioSoft, one focused on the unique needs of semiconductor design teams. In the above example, ClioSoft’s solution optimizes network disk space and speeds workspace creation by creating native Linux symbolic links in a common cache for files that are not being modified instead of copying them into each user’s workspace.

Let’s look at another example—tool integration—and another common misperception about so-called proprietary solutions—that integration is hard. Far from it. Tools-integration activity sometimes requires integrators to work with legacy software that has unique requirements. When a DM vendor owns the entire solution software, it can accommodate the needs of the EDA tool even if it may seem quirky and no SCM system would support it.

Let us look at yet another example – something which can impact the performance of the DM system. The performance of a DM system depends on the manner in which the data is managed. Each file used in a typical software design flow is managed individually and over the course of the development cycle has several versions. SCM systems are designed to handle such scenarios and manage files. However, the nature of data is different in case of hardware design. Most EDA tools use an open access database. An open access layout view is composed of 2-4 files sometimes called a co-managed set. A change to any one of the files in the co-managed set implies a change has been done to the entire layout. Depending on the operation the editor does you may have one or more files changing. Tracking individual revisions of the files is therefore meaningless. A DM solution based on SCM would need to store extra glue logic to decode “layout” versions and map it to the version of individual files, which can considerably impact the SCM performance!

A simple solution to this would be to treat the co-managed set of files as a package and then manage revisions of the package rather than individual files. This is both logically correct and efficient in terms of tool performance. Implementing this is difficult if not impossible with an SCM. A proprietary solution like ClioSoft SOS can easily implement such a problem of co-managed data sets. SoC design flows of today have several such examples where managing packages instead of a large number and size of individual files is immensely beneficial – place & route databases, verification IPs and even custom outputs from simulations and verification runs.

The nature of choice
There also can be a lot of hype around “choice” when it comes to DM solutions. Presumably, the more choice the better.

Self-styled “open” solutions, however, can run into challenges in scaling and support. Any issues in the solution which require some fixes within the software based DM solutions could potentially result in a long wait. And in a globally competitive playing field, any delays to the schedule can prove to be catastrophic to the product success.

Enhancement requests? It’s difficult to see a frictionless path with open solutions. But proprietary DM solutions designed for the semiconductor industry have the resources and support to service those needs quickly.

The “open” proponents also will argue that your design data is held hostage in a proprietary solution. But let’s be honest: In today’s world, it is next to impossible to hold anybody’s data hostage. And with ClioSoft SOS, customers can easily export the data from ClioSoft in the same way consumers can move data from iOS to Android and vice versa.

There is no one-size-fits-all when it comes to DM solutions, but “proprietary” is not a bad word either. In fact, given the immense risk and cost associated with design projects, we can warm to the word.

And at the end of the day, consider that Apple has a proprietary ecosystem. It’s worked pretty well for them and millions of their customers for a long time.