Published on January 22nd, 2006

The EDA Ecosystem and Free or Open Source Software

This paper addresses the issues of evolving a Free or Open Source Software (F/OSS) initiative within the EDA and silicon industries.

The term Free or Open Source Software (F/OSS) scares people in the silicon industry. The term itself is confusing. There are perhaps two potentially positive aspects of F/OSS: first its "openness" can promote and support collaboration; second, its "freedom" can encourage inclusion of otherwise (economically) excluded participants.

In fact, there are two similar organizations that promote F/OSS. The Free Software Foundation ( promotes the notion of free software as a "right" of the developer that promotes cooperation. They argue that all software should be modifiable by others and carry those rights.

Similarly, but coming from a slightly different standpoint, the Open Source Initiative ( focuses on the economic benefit of open source.

"When programmers on the Internet can read, redistribute, and modify the source for a piece of software, it evolves. People improve it, people adapt it, people fix bugs. And this can happen at a speed that, if one is used to the slow pace of conventional software development, seems astonishing." (From the web site)

Both organizations promote licensing schemes that can be used to protect the rights of both the developer and the user. It is perhaps the details of these licensing schemes that causes most angst.

For the silicon industry, there is a tension here, because this industry deals with extremely high value Intellectual Property (IP). The silicon design itself represents the "crown jewels" for a silicon company. These designs are traded between companies for large sums, under relatively complex licensing terms. Thus, for this industry, the concept of "Free" or "Open" IP is not easy to mix with their own high value IP.

There are two main obstacles to "free" software from the silicon design industry's point of view, Not only does the design itself need to be licensed in such a way as to enable "free" access, but the means by which the design is "accessed" must also be "free". In other words, for meaningful F/OSS development, both the IP and the tools must be free. Although this has long been the case in the software domain with tools such as the GNU 'C' compiler, thus far this has not been the case in the silicon industry. With the advent of SystemC, however, the first industrial strength F/OSS "EDA" tool is now available freely.

Distinctions between tools and silicon IP, middle-ware and operating systems

Before examining the benefits of F/OSS within the silicon and EDA industry, it is worth examining the distinction between the various "parts" of the ecosystem. There are distinctions drawn between tool companies, systems companies, silicon manufacturers and software companies.

Often, one large company may contain divisions that address all of these segments, although (typically) the tools industry is separate. In the past, this separation has made some sense. The silicon industry has used common and standard tools in order to create their designs. Today, however, designs - both silicon and software - are becoming increasingly "configurable," and it is becoming less and less clear where the boundary between the tool and the design lays.

For example, it used to be the case that a CPU manufacturer would have a (small) range of available CPUs. Now there are companies that offer a configurable CPU. Their product is both a specific tool (with which to select the configuration) and the design itself. It becomes irrelevant to the customer of such a product the degree to which this is a tool or a design. This trend can also be seen with memory controller vendors.

This effect is not limited to CPU's and memory controllers. The SPIRIT Consortium aims to allow the integration of all pieces of IP into a tool flow. From a user's perspective, within such an environment, it does not matter if the IP is fixed or generated using a "tool." The boundaries between tool and design become merged and any distinctions become increasingly unhelpful.

In short, both EDa companies and silicon companies are engaged in exactly the same endeavor.

It is increasingly apparent that many companies that have traditionally been perceived as "tools" organizations now consider themselves to be IP providers; at the same time, traditional IP companies are increasingly viewing themselves as "tools" vendors. One has only to walk the aisles of the major conferences (DATE in Europe or DAC in the US) to see ARM and Cadence (for instance) sharing floor space.

As much as the EDA and the IP companies should now be considered as one industry, this industry must include software; in turn, this software must include operating systems, user interfaces, middle-ware, etc. For the purposes of discussion - and purely to provide a point of reference - let's represent the silicon design ecosystem as illustrated in Figure 1.

Figure 1
Figure 1: The silicon design ecosystem

SystemC is a tool which is aimed at exactly the centre of the space; it provides a means by which both hardware and software designs can be realized. In this case, the "tool" is really a language, which can be used as a modeling tool. Equally, designs constructed using the tool can form part of the end product (as software components). Hence systemC is both "tool" and "IP", and can be used for both hardware design and software design. Furthermore - and crucially - it is the first tool to emerge in the F/OSS domain.

Benefits of F/OSS for the silicon industry

The silicon industry's primary driver is to -- in the vernacular -- "Fill the fabs!" From their point of view, the value of arriving at market on time with innovative and high value products is the percentage that they receive for the silicon product. It is becoming increasingly the case that innovative products consist not only of the silicon, but also of substantial amounts of software. Increasingly they are adopting F/OSS solutions that reduce their cost of production, enable them to get to market quicker, and are often more stable than proprietary solutions.

This has been the case for embedded products requiring an operating system, for example, where Linux has been extremely successfully deployed. Increasingly, this is also the case for other "middleware" components (i.e. ObjectWeb see [2])

These examples occupy the lower-right quadrant on the graph shown in Figure 1. The question posed here is: "What are the barriers for its adoption elsewhere in this space?" There is a tension here based on the fact that the silicon industry deals with extremely high value IP. Also, there remains a "mental" gap between hardware IP and software IP. Hardware IP is at the

heart of the silicon industry's perceived value chain, so encroaching upon it and claiming it as commodity seems an extremely risky strategy from their point of view.

This is equally the case for the industries that support the silicon and systems industries; both those that supply tools and those that supply component IP. Perhaps this obsession with the value of IP is the primary reason why the silicon industry has been slow to adopt the principles of "free software." For them to do so, however, would seem to have some obvious and direc benefits as follows: 

  • There is now silicon design IP that is nothing more than commodity. It is better served by an F/OSS services based model. (See "Rimer's Rules for Open Source" [3]. Danny Rime is a successful Venture capitalist specializing in F/OSS. He suggests that the F/OSS source model is especially suited to servicing "commodity" IP. 
  • Having a wealth of silicon design available as F/OSS will permit silicon companies to more easily "fill the fabs." 
  • The net result of the F/OSS model is the quality and robustness of the results. This has already provided considerable benefits to those adopting F/OSS for middleware and operating systems.
  • As security considerations become increasingly important, it is also worth noting that the F/OSS model can provide a more secure system (Two effects can be seen: first, more "eyes" to find potential vulnerabilities; second, an awareness that it can not simply be the "hidden" nature of a piece of code that will protect a system).
  • The F/OSS world has already constructed license mechanisms and infrastructure to foster collaborative activity. Silicon companies are now becoming increasingly interested in sharing design blocks in order to "fill the fab," and they can greatly benefit from an existing infrastructure. There are now tripartite agreements between many competing companies to share IP. The companies involved, having decided to share IP with their biggest rivals have nothing to loose and everything to gain in sharing that IP with a wider community. They have already identified this IP as non-differentiating commodity. If others are prepared to maintain (and indeed develop) it, costs can be reduced, and quality increased.

Benefits to the wider community

Just as important, if not more so, than the direct benefits to the silicon industry are the benefits that the economy in general receives from an increased F/OSS ecosystem. In this case, a F/OSS ecosystem can:

  • Create new business opportunities, such as the emerging "ESL" market.
  • Enable research activity, especially in the academic sector.
  • Enable small and medium sized enterprises, including those in less advantaged economic zones.

Creating new markets: An effect of making software open is that it is often used in different, or more extensive, ways than had originally been envisaged. One example of this is the use of SystemC as an electronic system level design tool. As the silicon industry strives for evermore sophisticated systems, the complexity of the design task has exploded. At much the same time, SystemC - an open source hardware/software development language - has become available. This language has been picked up by the silicon companies to assist with the "electronic system level" design of their products.

SystemC was conceived as a means of conglomerating a number of C-based hardware description languages into one common language. The perceived benefit was that having one common language would enable EDA companies to support it and silicon companies to adopt it (without being tied to a specific vendor). In this, SystemC has been very successful. In addition, a number of small and medium sized companies have developed solutions in what is essentially a brand new environment.

These companies owe much of their existence to the open source nature of SystemC. This has been a "side effect" of the collaborative F/OSS environment. It's a new industry, feeding a level of design activity that was hither-too unobtainable.

Enabling (academic) research: One common (miss?) conception is that research and development is not feasible within an F/OSS setting. Bill Gates has been quoted as saying: "I don't think that someone who completely gives up license fees is ever going to have a substantial R&D budget and do the hard things, the things too hard to do in a university environment."

It is interesting that Mr. Gates' conclusion specifically assumes that there are things that are too hard to be done within a university. The natural solution to his concern, surely, would be to enable our university sectors to be able to better address research and development.

The fundamental interest in funding Free or Open Source Software initiatives in the EDA and silicon industry space is to directly build an EDA "ecosystem" - an environment in which both hardware and tools companies in the silicon industry can flourish outside of the current "big three" US-based EDA tools companies.

Our "ecosystem" must emerge from small and medium sized enterprises (SME's) offering the large (EU based) silicon industry users compelling products. Those SME's in turn are most likely to emerge from academic institutions (spin-outs). Therefore one of the critical actions that funding bodies can take is to insure that academic research is relevant to the silicon industry.

Currently academia is caught in a vicious cycle. They do not have access the relevant tools (and resources) in order to build relevant and large designs. They do not have large and relevant designs in order to guide their research into - and construction of - relevant tools. Within the context of the silicon design industry, the problems of scale are becoming crucial. Certainly, universities would like to help, and there are many good ideas coming from the university sector, but they are hampered in their efforts, not because it is "hard" but because first, they do not have "large systems" to experiment with; and, second, they often do not have access to the tools.

Large designs/systems are (still) considered valuable IP, and are therefore not released to the academic sector. Initiatives such as ARTIST2 (see [4]) have the aim of developing the research community; however, they are still powerless to capture realistic designs, without which their research will always lag behind the state of the art within the private sector. And without the tools to manipulate that IP, they are powerless to contribute meaningfully to either the tools or the IP.

A classic example of this is the work in the field of using ULM (the Universal Modeling Language), which has successfully been deployed within the software sector to handle large scale designs. Naturally, it would seem to be appropriate to reuse the methodology for the design of large scale hardware designs (which are nothing more than software descriptions in hardware).

Both the university sector and the private sector have been developing methodologies around UML for use in the silicon industry. However, much of the universities' work (whether it is valuable or not) can be dismissed on the basis that the so-called "large scale designs" they are using to test out their work are often trivial in comparison to the systems that the industry needs to work with.

Providing F/OSS designs into this environment will directly help those universities research and develop these methodologies (in an independent way). The results will be beneficial to all those within the industry now faced with increasingly unmanageable designs. Of course, co-ordination of this F/OSS activity will help enormously, as it will encourage critical masses of researches focused in the same area, producing de-facto standards that can then be adopted and supported more widely.

Enabling SMEs: These advantages spread wider that just the university and research sectors. The availability of "standard" tools and IP will also enable small and medium sized businesses to create the innovative (and sometimes disruptive) products for which the SME sector is renowned. Finally, of course, the same applies to economic areas that have hitherto been excluded from developing innovative embedded systems products.

While this may not be appealing to multi-nationals, it should certainly attract public funding bodies. The bigger question is not whether there is a benefit in F/OSS, more it is a question of exactly what should be shared, and where the real value rests. The assertion in this paper is that the value is in the silicon; following from this, any other part of the system - or the tools used to build the system - can be, from the point of view of the silicon industry, better developed within a F/OSS model will.

To say the least, this worries those who are not silicon manufacturers, but it shouldn't. There is a perfectly viable business model for this industry, which is likely to have a very similar margin portfolio to the EDA industry's current model (Table 1).

Figure 1
Table 1. Comparison between the top three EDA companies and RedHat.

Economics of F/OSS Business Models

Weaning companies off the drug of license fees will not be easy; neither will convincing companies and organizations to part with money up-front for software development - especially in an industry that has thrived through license fees.

There have been many attempts to successfully make money from F/OSS, with varied degrees of success. Companies such as RedHat are successfully using a support and maintenance model. Others, such as CodeSourcery, adopt a services approach, offering to develop specific F/OSS items for an upfront fee. (Actually, it is irrelevant whether this payment is made before, during, or after the development; the distinction being made here is between a business model based on ongoing licensing and a business model based on a payment that relates to the cost of development)

Of course, software is "special" in that once produced, there is no cost in reproduction. As the Debian organization puts it when answering why F/OSS can be free:

"A better question is how do software companies get away with charging so much? Software is not like making a car. Once you've made one copy of your software, the production costs to make a million more are tiny (there's a good reason Microsoft has so many billions in the bank)."

On this basis, paying "up-front" for the development seems more natural. On the other hand, the costs of "good" software development can be high. Thus, some may consider it to be a lower-risk option to buy a piece of software that somebody else has developed, as opposed to paying for the development of a new piece of software (even in the new software better matches the user's needs).

The answer to this is clearly to disperse the cost of development between those that require the feature. This is becoming more and more possible as the technology used to develop software increasingly focuses on breaking the software down into evermore specialized parts, each of which can be reused in other environments.

In this scenario, rather than the software being a single monolithic entity, it is more likely that it will be constructed of many parts. Thus, it is the development of these (small) parts that requires funding, and not the development of single large-scale software systems. This is comparable to the case within the silicon design industry, whereby large designs are constructed from small blocks that can be re-used. This re-use is critical to achieve time-to-market goats and to meet the industry's return on design investment.

The need for public funding

In general, F/OSS funding is not about what gets done, it is more about the speed at which it gets done. From a public funding body's perspective, the advantages that F/OSS can bring can be summarize as follows:

  • Growth of new economic activity.
  • Direct benefit to SME's and less advantaged economic zones.
  • Support for academic sectors.
  • High "Value for money."

Without public support, however, the speed at which the F/OSS community grows may be depressingly slow. There is also the question of "critical mass" for any project; a project will make little or no progress unless some basic amount of resource is dedicated to it.

Options for funding

Within the context of the silicon industry, there are two aspects of funding that can be usefully separated: first, funding of projects in the silicon industry in general; and second, funding of "traditional" F/OSS activities.

For the silicon industry, the assertion made here is that all IP can be open source, that there are viable business models for its development and exploitation, and that the real "value" is only in the tangible silicon product. The implication is that ALL silicon industry funding that is not directly contributing to tangible silicon products should have, at the very least, a substantial open source result. Public funding would then have a publicly available benefit.

For public funding bodies, this means adopting criteria that will (over time) result in an increasing

shift towards open source dissemination. The time scales for such a shift are not necessarily long. The "mental" shift is already happening within the industry. As one example, in the keynote address given by Andrea Cuomo, Executive Vice President, Chief Strategic Officer of STMicroelectronics, to the November 2003 Fifth Real-Time Linux Workshop, he emphasized the existing use of F/OSS already within STMicroelectronics products, and its business requirement for F/OSS). Furthermore, in his keynote address to the CODES+ISS conference in Stockholm 2004, Mr. Cuomo indicated that he was looking towards the open source community to provide tools.

This addresses the majority of funding within the silicon industry, but it does NOT address the wider scope of F/OSS activity that could (and should) be enabled. With the construction of a F/OSS silicon design ecosystem, it is only natural that there should be a F/OSS community supporting it. Indeed this is vital for the success of F/OSS projects in general.

Large companies may be involved in the conception and design of new material, but it will be the

F/OSS community itself that maintains and develops those objects. The question for funding bodies is how best to nurture that community.

What is also clear, after some research (e.g. [1]), is that funding needs to go directly to the F/OSS operatives. This is primarily because - in all other cases - the funding effect is diminished by including other parties in the funding instrument. The maximum "speed" increase and the high rates of return that are made possible by F/OSS can only be achieved by direct funding.

From a public funding perspective, this is a difficult situation, as typically public funding bodies are more used to dealing with one or more large institutions. Funding individuals or small bodies of "open source activists" is dangerous in terms of both the security of the investment and its trace-ability.

Contra-wise, F/OSS activists may not be used to dealing with the tight constraints of a public funding body. From the F/OSS activists point of view, there are also difficulties in spending time attempting to convince public funding bodies to support their work, as their livelihood depends upon them producing results in shot time frames. They have little or no spare time to be engaging in the funding process.

The best solution to this would be specific funding instruments that are tailored to resolving both issues. There are some alternatives:

  • A separate "body" can be created who's remit is to channel funding into F/OSS projects. This protects the public funding body itself from the problematic interface with the operatives themselves, and it also provides a simple route to funding for those operatives. The disadvantage here is that the funding is still not direct.
  • Specific instruments can be created that fund F/OSS operatives directly. The "call" for such funding instruments must be frequent and "streamlined" enough to allow operatives to take part within their time scales. It is also likely that such funding would need to include some allowance to specifically address the issues of trace-ability (which might be provided by a third party specialist).

Assessment criteria and value for money

F/OSS operatives typically work in small dynamic organizations with low overheads. Their rates of progress are often phenomenally high, and the individuals are highly motivated. Clearly, this represents an opportunity in terms of a high potential value-for-money investment; but one issue the funding bodies need to address is how to assess results.

In this case, there are some additional challenges, as simply using common metrics like patents created will not work. Of course there are other metrics that can be used. The aim of publicly funding F/OSS activity is to enable an ecosystem, with potentially the side effect of enabling new activities (such as the Electronic System Level (ESL) design tools). In order for this to occur, there must be significant uptake of F/OSS within the industry.

Within the silicon industry, the use of tools and IP is regularly gauged by companies such as Gartner/Data Quest, and this provides a tangible measure that can be used. F/OSS projects need to set a target in terms of the percentage of developers engaged in their specific design activity who make use of the F/OSS objects. Clearly, each project will be different, and will therefore require different measures. Care must be taken to measure the desired effect of the F/OSS, and to not rely on metrics that would be better deployed elsewhere.

Coordination of funded efforts

There are needs for some amount of "infrastructure" in order to enable F/OSS. These needs may be summarized as follows:

  • "Repositories" to hold the software (in public) are perhaps the most visible.
  • "Bug trackers", "Feature/Requirements capture tools", etc.
  • Collaborative Web sites, which must help "grow" the community.
  • Suitable licenses and legal agreements that companies can use to fund the effort.

In addition, there are "working practices" that need to be adopted in order to guarantee the quality and worth of the result (this was touched on in the "Options for Funding" discussions above). Successful software projects have "processes" such as peer review mechanisms (see or In order to achieve successful F/OSS projects, these mechanisms are usually "run" by individuals, or small organizations, who take an overview of what is happening within the project - they are "gate keepers" for the project.

In order to address the problems of scale and complexity that are "relevant" in the silicon industry, it is to be expected that in general it will be small specialized organizations that should provide these "gate keeping" services. All of these mechanisms can (and possibly should) be common, best practices promoted such that the funded projects achieve quality results. "Guardians" need to be appointed (or recognized) for "project areas", and they need to be "empowered" with the tools they need (like the repositories, bug trackers, collaborative web sites, and licensing agreements).

Funding bodies have a key "co-ordination" role to play, both in terms of providing the resources, and in terms of guaranteeing that best practices are adopted in diverse project areas.


The fundamental interest in funding F/OSS initiatives in the EDA and silicon industry spaces is to directly build an EDA ecosystem - an environment in which both hardware and tools companies in the silicon industry can flourish. This document addresses the questions:

  • Why support F/OSS?
  • Why is EDA different and why hasn't F/OSS taken off in EDA?
  • Why do we need something special?

The important message are:

  • Treat tools, IP, software, and hardware in the same way.
  • Consider the "value" to be in the silicon; everything else is a candidate to being placed in the open as commodity items.
  • F/OSS commodity objects enable new businesses.
  • It iscost effective to fund research and development directly in the F/OSS community.

For a full and detailed exploration of Free or Open Source Software in general, and the implications for public funding within Europe, see [1]






Mark Burton is the founder of the open source SystemC community and initiative called GreenSoCs ( GreenSocs' mission is to encourage SystemC to be used by designers by engineering a SystemC infrastructure to complement the capabilities developed by OSCI and commercial EDA providers, and also to promote and utilize academic research. Furthermore, GreenSoCs will co-ordinate and make available collaboratively developed models, methods, and utilities, prioritized by designers needs. You can contact Mark at

Tech Videos

©2018 Extension Media. All Rights Reserved. PRIVACY POLICY | TERMS AND CONDITIONS

Extension Media websites place cookies on your device to give you the best user experience. By using our websites, you agree to placement of these cookies and to our Privacy Policy. Please click here to accept.