The GreenSocs mission is to support the ESL community.

Methodology

GreenSocs provides the corner pillar of the Methodology triangle. The infrastructure which must be in place in order to be effective with ESL.

The infrastructure is not core business to either EDA nor ESL user companies. Indeed, it is only of value when it is shared.

GreenSocs enables this to be achieved by sharing the cost of development and by disseminating the results publicly.

Licensing

The results of contracts with GreenSocs are made available to subscriber under the terms of a standard Software License Agreement (GreenSocs Subscribers License). For simplicity this is simply a "BSD" style license which permits subscribers to do virtually anything with the code they receive. Other terms and conditions normally associated with SLAs are negotiated on a per customer basis.

Those who do not subscribe to GreenSocs should be aware that the code is free for them to use, and is licensed to them using an "open source" license called the GPL. This has implications if they need to distribute their products outside of their companies.

Dividing up the work

Typically, larger projects are divided into smaller sections, and individual companies will contract GreenSocs to complete those sections. Contracts may overlap, and hence the price will be significantly reduced. Finally, the customer will receive the sum of all the parts, having only payed for a small proportion of the effort.

Significant Infrastructure : Interfaces

One of the most significant parts of the infrastructure is the definition, and availability of interfaces. The next section details how GreenSocs processes the de-facto standardization of interfaces.

GreenSocs Operation Overview

1/ GreenSocs will focus on API's that enable ESL models, tools and companies to communicate. We will also make available infrastructure that can be used to quickly connect to these APIs.

We divide an API into two parts

1. the transportation mechanism
2. the data packets that are passed across that transportation mechanism

The distinction is important, transportation mechanisms may be common to many APIs (and this should be encouraged) while data packets are specific to individual APIs.

The transportation mechanism are:

1. Between Models of hardware and Models of hardware
2. Between Models of hardware and Models of software
3. Between Models and Services
4. Between External applications and Services
5. Between External applications and Models
6. Between Businesses (Documentation, and machine readable meta descriptions)
7. Between Businesses (Binary or other encrypted, but executable data)

Many of these are already available as standards, and GreenSocs will make use of those. Where they do not exist, GreenSocs will assist other organizations where appropriate to standardize these transport mechanisms. We will provide requirements, sample implementations, and review the output of standards organizations who are addressing the transportation mechanisms.

On top of these transport mechanisms, GreenSocs will provide a procedure for standardizing and publishing the data packets that are passed across the transportation mechanisms. This will be documented below. The list of these "API's" will change and grow over time. Initially examples using each of the transportation mechanism will be chosen.

The infrastructure that GreenSocs provides(may be independent of a specific API, or associated with an API. The infrastructure that GreenSocs provides is aimed at the principle GreenSocs mission, to support the ESL community. GreenSocs is not intending to provide competitive IP or EDA tools. It is aiming to provide

1. basic infrastructure that can be used by tool and IP vendors to quickly make use of the common API's.
2. infrastructure that is common to IP or EDA vendors that does not provide them with value and is simply a cost on their business.
3. infrastructure that is needed to provide links between IP and or EDA vendors.

2/ GreenSocs interfaces will be funded by subscribers

1. Full subscription membership fee of 50k euro / year.
2. This is intentionally set to ensure commitment.
3. Full Subscribers will dictate the API's that are addressed, and how the engineering effort available is used. The will set the roadmap for GreenSocs.
4. Participant membership fee of 5k euro / year per API standardization effort (max 20k euro /year for full participation)
5. Participants will work within a standardization effort group, and direct the engineering resource within that group.
6. Technology access Membership fee of 5k euro / year
7. Technology access subscribers will have full (and favorably licensed) access to all GreenSocs technology.
8. The subscribers will fund :
9. The "community" activities of GreenSocs (public meetings, wiki site, etc)
10. some centrally funded engineering. - The engineering will be provided to :
    1. take proposed packages and build them into a "GreenSocs package"
    2. provide some support for standardisation efforts when requested - see process below
    3. document requirements
    4. document existing (contributed) approaches
    5. run experiments
    6. document proposed solutions
    7. implement solutions.
    8. develop APIs, data packets and infrastructure (the latter to support ESL in general) - where it is missing.
    9. Provide support for Members.
    10. The engineering effort will be controlled by the subscribers.
    11. It will be determined on a per project basis.
    12. Some projects will be "engineered" by universities.

3/ GreenSocs subscribers are expected to donate significant (existing) code (API's and infrastructure).

4/ GreenSocs subscribers are expected to make 1 person available - at least 50% of their time,

1. to complete the GreenSocs roadmap that has been collaboratively agreed
2. to provide sufficient feedback and supervision of the work carried out within GreenSocs

  '' Of course, subscribers might contract GreenSocs to provide extra central resource, but this would fall outside of the normal subscription.''

5/ Where API's or infrastructure becomes externally standardised, GreenSocs will maintain an up to date copy such that GreenSocs can be reliably used as a resource for all API's and infrastructure.

GreenSocs Process:

	Bi-annually, GreenSocs subscribers will provide a list of API's and Infrastructure that they would like to see made available. This list will be fully annotated with requirements as far as is practically possible - this activity will be relatively formal, supported by GreenSocs engineering. Hence, the requirements capture and "Ideas pool" is managed by GreenSocs Road-map restricted to items achievable with the combined resources of GreenSocs and Subscribers
	GreenSocs provides documentation - in line with requirements capture
	Implementation achieved using GreenSocs and/or Subscribers staff

Subscribers and others are expected to donate API's, and infrastructure to GreenSocs. In the general case, this will be documented and amalgamated into the GreenSocs environment such that the adoption of those API's can be made as easy as possible. Any API may be donated by anybody - so long as it carries an open source license. Only API's that fulfil items on the GreenSocs roadmap will be worked on by GreenSocs.

Where no donations are received, subscribers will be obliged to expend engineering effort to construct a suitable API or infrastructure.

Where more than one donation is received, subscribers will be asked whether to

1. start a working group within GreenSocs, supported by GreenSocs engineers, in order to build an agreed solution
2. move the effort to an external standards body (if the expectation is that the result would be donated to such a body anyway)

GreenSocs subscribers must support this process. This last step is important. IF it is decided to run the initial "standards agreement" process within GreenSocs, then the subscribers must ensure that the standards body is informed of progress, and visa versa. It will be the subscribers, and not GreenSocs that must ensure the inter-working between GreenSocs and a standards body in this case.