Warning: Undefined array key "upload_with_nude_flag" in /www/www_com/htdocs/get_weekly_feature_ad.inc.php on line 69
Introduction
In my interviews with EDA executives I find many commenting on the considerable value of standards as enablers for their technology. They can develop products that leverage the interfaces defined by these standards with confidence in minimum risk. End users benefit from the flexibility that have in choice of tools.
I had an opportunity to interview the heads of two organizations, namely Ralph von Vignau, Chairman of Spirit, and Kathy Werner, president of Virtual Socket Interface Alliance (VSIA)
SPIRIT stands for “Structure for Packaging, Integrating and Re-using IP within Tool flows”. The goal of The SPIRIT Consortium is to develop specifications for describing IP and IP packaging, as well as plug-in tool IP interfacing and packaging, in order to enable more efficient and cost-effective integration of IP from multiple sources. Specifications for IP meta-data description and IP tool API's will be addressed.
On June 12, 2006 the SPIRIT Consortium announced it would contribute the current version of its system-onchip meta-data specification, v1.2, to the IEEE for consideration as an industry standard. This technical specification, to be known as the IP-XACT design-exchange format, comprehensively addresses support for the integrated multi-vendor RTL design and verification flow. This schema provides a standard method to describe IP to make it compatible with automated integration techniques. Tools that implement this standard will be able to automatically interpret, configure, integrate, and manipulate IP blocks delivered with meta-data that conforms to the proposed IP meta-data description, and the IP-XACT APIs will provide a standard method for linking multiple tools together through a single exchange meta-data format.
Ralph von Vignau is the Chairman of Spirit. Ralph is also the Director of Infrastructure & Standards at Philips and the CTO of LIPP (Library and IP Partners), cooperation within the Crolles Alliance between STMicroelectronics, Freescale and Philips. He has held a number of management positions in integrated circuit, software and systems design throughout his 36-year tenure at Philips.
How long have you been involved with the Spirit Consortium?
Right from the beginning! I was one of the people basically forming it. Starting around April 2003 we had our first official setup meeting. At DAC we announced the formation of Spirit.
Were you the Chairman from the start?
Yes. I have been the chairman since the beginning.
How would you define the role of chairman?
On the record, I have had, an easy job is not the right word. It has been amazing actually how well the companies who have such differentiated markets, approaches, values and so forth have cooperated. They are not exactly working together in the market. In Spirit it has been tremendous how they have all pulled together. I must say we put some fairly hard rules in place at the beginning. There has to be executive signing during the commitment. I have had cases where if there were problems, it didn't take me more than one day to get s7 or 8 executives on the line in a conference call. That to me is not something I achieve in normal business.
According to your resume you are involved with several standard organizations.
I am also on the board of OSCI. I am responsible internally in Philips for the standards used internally which can be industry standards we take over as well as internal standards. We even produce some that we then bring into the industry. PC1500 which is now IEEE 1500 is an example. It is such that a lot of my work revolves around getting standards utilized by Philips and trying to drive industry standards. Philips recognizes that there is a value in these standards. I used to be on the VSIA board. We decided to drop out of that at a certain time.
What's involved in getting people at a company like Philips to adopt, use or leverage standards? What's the challenge?
There are two challenges. One is getting management to recognize the value of deploying standards rather than to do it their own way. The other, having gotten over the first hurdle, is getting design groups to actually deploy them because I would say that pain of change has to be less than the pain of not changing. It is not always that obvious why they should change their way of working. Very often standards are not directly of advantage to a point design. It is more on a total company value that being able to use these things, to use common tools or to use things done in one division in another division are not recognized at the low level of a design team but they are at a higher level as having considerbale value. I think it is the explaining and getting the recognition of the value of a standard in a particular design environment. That is the biggest challenge.
Philips clearly understands the value of standards at a high level.
Absolutely! I think we are in an awful lot of standard groups, sometimes we wonder why in so many. We also contribute a lot into these standards groups. Obviously, there are different types of standards. There are basically two types. One is a standard where you want to improve your environment, your way of working, interoperability between companies or between whatever which do not have a value in themselves as a license or something like that has but rather a value that they are there so that you can interoperate with people. Spirit is a typical example of that type of standard. The other standards are like the DVD, CD or cassette standards where you make a profit on them, where you have an idea in the market you believe will be picked up by the public, by end users. You can get license fees for allowing people to use these standards. So two different types of standards. Philips is actively involved with both of these. Also these days more and more creative in understanding that through standards we can lower the overall cost by getting not point solutions for tooling and so forth but getting the industry to provide tooling on a more even basis.
What was the motivation or vision that prompted you and others to launch Spirit?
Frustration! Enormous frustration! I think several things came together. We deal quite a lot with ARM. We use their processors and their IP. With Philips at that time I was trying to drive a new step of reuse. We have always been trying to evolve reuse. We said we needed a high level of automation. With the tools we currently have and the ways of working, there was too much manual fiddling around. I said we have to go into automation. We have to have a standard in place which will allow people to deliver IP in a way such that we can use it in our design environment independent of where it came from. We didn't want that if it was developed in a Cadence or Synopsys environment that you could only continue to use it in that environment or that when you received that IP you have to do a lot of work to fit it into your own environment. That was the frustration from my side: how so I do this when talking to ARM who had to deliver it in 8 different flavors for 8 different standard flows out in the market. That meant all the testing and validation for those 8 flows. Spirit enables them to deliver one thing and it can be used in any flow. It enables us to integrate their IP without doing a lot of work on it. That was the original idea behind Spirit. We need something in place. It needs to be an open standard. It is really an enabler for an economic system where automated tooling can come into play. Up until then it wasn't really possible or only possible on a limited scale.
What was the specification you set out to develop?
It was the interoperability of IP. But really you express IP or you provide something that expresses the requirements of IP on its environment or what it has in itself so what type of busses it has, what type of signals it has, what it requires to be connected to, the polarity of these signals … things like that which are normally done manually to express them in a format where a tool can pick it up and automatically generate an interconnect, automatically verify they have been properly interconnected, automatically verify the registers have been placed in the right order and that they are in the right memory mapping. All the sorts of things you do when you build a SoC. That's now through the Spirit way of expressing data or meta-data. Tools can take it and use it to make the intelligent interconnections rather than having to be hand-drawn or connected by name and all of those types of things. The system will now recognize that this is an AHB bus. I connected it to the central core bus or whatever has been allocated to it and did it the right way. It says I have an interrupt signal, it produced with a negative flank and the other has a positive flank. I need to invert it. These are the types of things that can then be done.
As a matter of history when did Spirit first publish a specification?
The first published specification was V1.0. I think that was at DAC 2004, one year after we started. We then published V1.1 a half year later which added some of the features that were missing in 1.0 but that people required to do some of the things which could be added fairly easily. In March of this year we have released V1.2 which basically completes the RTL. We believe that every form of IP can now be described. We also believe that in large part the verification if IP which you need can also be described in this common format.
On June 12th Spirit announced it would send IP-XACT to the IEEE organization for consideration as an industry standard.
We started up an IEEE working group, P1685. V1.2 is being prepared to drop into that. It hasn't actually been done at this moment. It is being correctly formatted and going through formal check. It has been out there. It has been reviewed. It has a couple of comments that have been corrected so that when it goes to IEEE, it will have fairly high maturity and have been tested fairly well in various environments.
What is the IEEE process on a go forward basis?
We don't just send it to IEEE as sort of mail. What happened is that all our members have become IEEE corporate members. We are part of IEEE-SA (Standards Association). The corporate members have to put together and form a working group under the IEEE which has its own standards and ways of doing things. Spirit has now formed this working group and has allocated resources and got others to join. There is now a team of engineers that have started to meet. You bring in or donate to this working group the specifications that then come out after the working group has gone through the formal IEEE way of making it public, of getting feedback, of getting more industry involvement. Eventually it goes through the voting procedure and comes out as an IEEE standard.
How long do you expect that process to take in this case?
Expect? What? Believe? We would like to have it done in roughly 9 months. This appears to be the average that most standardization groups are achieving. There are signs that you can do it in 6 months but we are not going to push it because in bringing out the standard we will be dropping in a few other things which we may develop during the coming months to complete certain aspects or where the industry has said would you add this. I think 9 months is a fairly good time frame. It might take a year but we certainly do not want an 18 month or 2 year process. We would prefer to limit the content to ensure we bring it out in time.
Do you envision Spirit continuing to extend the specification or moving on to other issues?
We have quite a lot of input on certain things that the industry thinks has to be added to the spec. I can give you an idea that verification was done but it did not include all of the features that a verification suite would like. There are things to add to what has been done in verification. We expect that OSCI will proceed with TLM. There is a requirement for TLM interoperability which we would also like to add. We have been working with OSCI and the ESL part is being brought in. Also we keep up with what they are bringing out in addition to that. Interoperability is important. When they bring TLM interoperability out, we will obviously add that to the scope of the standard. The scope of the first IEEE standard will be clear in the next month. If we take this seriously and try to bring it out in 9 months, somewhere in the 2007 timeframe, we don't want a never-ending process. “Oh there is something else, let's add this and add that.” So we have stopped. We bring it out now. We go through the process of making this an IEEE standard. Probably one year or one and a half years down the road we will have a whole bunch of new things. We see this as an ongoing process but not that we don't bring out IEEE standards along the way. There may be IEEE 1585 then you get a version 1, version 2, version 3 and so forth. It may be that the new information is so different that it doesn't go into IP-XACT but is something else. That may be a new IEEE standard. The intention is that Spirit itself will approve and make public its standards in the beginning. The whole idea is that we will call them specifications. They will actually go through the IEEE process to make them standards.
Would you describe the different categories of Spirit membership?
At the moment we have roughly 58 members. The members are split up into what we call reviewing members which is a membership that any company can enter into. There are no fees associated. Rather, we hope and expect that people who become reviewing members will in fact review the documents. They have access to alpha and beta versions and provide valuable feedback. We get an automatic buy-in from the people providing the feedback. We ensure the industry feels that what is being defined is something they can use. So the idea behind reviewing members is that we get industry feedback at an early stage. We then have contributing members, reviewing members who have said that they have an knowledge and are extremely interested in this and need to be able to influence it because it its one of their key knowledge or requirements. They can bring in engineering resources. Again, Spirit is not so much driven by paying members. Even contributing members don't actually pay a fee. We are more interested in them committing to provide engineering resources into the working groups. That's what really makes it work. When you look at the total cost, putting an engineer into a working group is much more expensive than a fee of $10K or $20K. That commitment is where the firm says “I have the interest. I want this to be done. I give my engineers into this.” You see that the results are driven because in the end the whole idea is to bring out something of value for the companies. This has been one of the values of Spirit that it has the drive to bring these standards out.
The third class (class is probably the wrong word), the third type of company is what we used to call Steering Committee members, members who have a vote in the final approval. The working group member can vote on ongoing work and proposals of his group. The final vote is taken by the Steering Committee members who are expected to put engineers into two working groups. Normally one of these would be in the major group, the schema working group what brings it all together into the standard. So the expectation is that they have a high commitment of resources and thus earn the right to be on the Steering Committee. They also pay fees which allow the organization to keep running. We try to keep it a very slim organization so the expenditures are not really that high. Of course, as you get bigger, it does increase in terms of administration. With 56 members I can no longer run this organization with my secretary. We actually need to have someone administrating and dealing with all the things, making sure the mail is answered. We have people like Jayne Scheckla (PR Person who arranged this interview) contributing heavily into marketing and making sure we have the exposure we require and set up interview like this properly. We are sort of partially driven by the Steering Committee providing facilities, time and effort. This allows us to have an office, a website and an administrative staff. There is also one other class which is new. That's a so-called associate member which cooperates with other groups. This is a very new idea. Towards DAC we will have this idea sorted out and will be announcing something.
Are the engineers in the various working groups participating full time or are they still working for their employers?
We really want them to continue to work for their firms because they should be bringing in the requirements from their companies. They should be collaborating with more people in their firms bringing back what is being done because we would like this to be verified and tried out. To give you an example at Philips, we have someone working on the schema group. Behind that person are probably 10 people working at the firm utilizing what we are generating. There is sort of feedback and rapport between users within the company doing company specific things with it and providing feedback. “You defined this but this is not working or whatever. We are having problems with it. We need to add something.” The representative is someone that is working 30% to 50% of his time in a working group and the rest of the time in their company. This goes for every company. The lowest acceptable rate is around 15%. The working group meets once a week on a conference call, which usually last an hour to an hour and an half. It is expected that people pick up work, do it and present it and bring it back the next time. Every 8 to 9 weeks there are face to face meetings. Again a high commitment. US firms are a majority but we have members in Europe and we are picking up members from China and Japan. If they are contributing members, they have to send engineers for these face to face meetings. These meetings usually last for three days. That works very well. The commitment is very high with engineers. The average is 30% to 50%. Of course it goes up and down depending on what is happening. Behind that you always have people working within the companies.
What are the working groups within Spirit?
We have three of which I would say one is in maintenance mode but not shut down yet because they have delivered their parts. We have a scheme working group which is working on the basic things that need to go into the standard and ensuring that it is all working together so that when new things are brought in they are not breaking something else. They are doing the integration and testing of the whole lot, ensuring it is a stable, mature and robust system. One group we have is a working group called the ESL Working Group which works on bringing in the system level description.
We see new things coming from OSCI, new ideas connecting SystemVerilog, SystemC and UML together. Making sure all these fit and can interoperate. The Verification Working Group is the other one. They have deliver into 1.2 what they were required to deliver. At the moment they are helping with the maintenance and with ESL because with ESL you start getting TLM which also gets into verification space as well. We see a large crossover there. They are ensuring the verification aspects of what is being done in ESL. So you will always have a working group working on its own on a particular scheme and starting to get to solutions which need to be integrated together with the rest of them and then they start interworking and having common meetings.
You mentioned OSCI several times. Do you currently have relationships with any other groups?
No. But we are considering this. Spirit does not want to generate standards that are already out there. The whole idea is to try and utilize what's out there. We are also looking very closely at being able to work together with those who are generating certain things and to describe them in the Spirit way. We will generate an environment that allows tools to package the systems in a standard way and to utilize this metadata as provided.
You mentioned you were previously involved with VSIA at one point.
I was actually on the board there. We will probably be discussing with them on the same level what they are doing and what we are doing because we don't want to work on something that someone else is working on to achieve alignments. With VSIA after their reforming of the way they are operating. We need to understand what they are going to work on and in what way this could be of interest to Spirit or what could they do that we would say is complementary to what we do and can we support them in getting it done. But that is still to be done.
Is there anything that you wish to add?
From the point of view of where we are going, the separation between the Spirit Consortium and IP-XACT is something we have done because we feel there's going to be a lot of work and a lot of standards coming along. Some of them will be pertaining to what we are doing and some may have to be described in another way. That's sort of branding the organization as the Spirit Consortium. The products or the standards can be IP-XACT A, B or C. But that's slowly getting understood by everyone
By the way there is an open meeting of the Spirit Consortium at DAC on Monday, July 24, 6-8 pm at the San Francisco Marriott Hotel.
VSI Alliance or the Virtual Socket Interface Alliance
VSIA's mission is to dramatically enhance the productivity of the SoC design community by providing leading edge commercial and technical solutions and insight into the development, integration and reuse of IP. The VSIA board of directors unanimously elected Kathy Werner of Freescale Semiconductor as president in April 2006.
Would you give me a brief bio?
I have been in design and reuse for more years than I care to number. I have done a lot of designs. I started out in the fem, went to computers and then went to processor design. From that point I moved to consulting. I started working with reuse programs with global companies all around the world in many different areas. My design background is pretty broad. I have been in the reuse space for probably 9 years now. It's amazing the more companies I talk to, the more the problems are very similar. People are struggling with this internally. I think that where VSIA can really help. Because of the broad range of member companies we have and the different experiences that everybody brings to the table.
How long have you been involved in VSIA?
It's funny! I got involved with VSIA probably 5 or 6 years ago when we first kicked off the quality study group. So I have been involved with what has turned into the QIP Metric pretty much since its inception. We started off with the donation of OpenMORE IP assessment program from Synopsys and Mentor. Then Agere Systems and Cadence donated ChartReuse IP which was extended from that. We released the Soft IP metric in January. Since then we've had over 1,000 downloads. We are working closely with FSA (Fabless Semiconductor Association) to extend the metric for hard IP. We expect that to go into beta soon. There will be an announcement on that soon.
Were you the head of that group?
Yes! It has gone through a progression. I was a participant at the beginning. Then I co-chaired with Intel and then with Agere. Then I chaired on my own after some personal changes. I feel a pretty strong sense of ownership for the group.
Did you have any prior involvement with any other standard organization?
VSIA was the first one in this space. I have worked with other standard organizations, for example on bus standards. But VSIA is the first one I have been involved with where I am looking more at the business aspects of it.
What do you see the role of the VSIA president to be?
(Laugh) Chief cook and bottle washer. Actually, I see the role of president as touting and sharing the vision of VSIA in the space we are working in, trying to drive the organization as a whole to come up with solutions that are needed in the marketplace. There are common issues that companies are seeing. Where I see a real role for VSIA is coming together for some of these non-differentiated solutions, pooling resources and coming up with a standard that everybody can adhere to and follow. It makes so much sense. A lot of people have internal reuse standards. That's fine and there are definite good business reasons to have very specific things for internal methodologies and procedures. But there is definitely a base line that could be and should be common across the industry. It makes it much easier for vendors to support their customers and for customers to understand what they are getting.
In addition to being president of VSIA you are a full time employee of Freescale.
Yes. I am manger of IP Business and Strategies. It's an umbrella organization within Freescale. We work with all of the business groups for IP roadmaps, IP make-buy decisions, IP procurement and internal standards. It's closely related to what I do at VSIA.
Is your involvement with VSIA personal or actively support by Freescale?
It's both really. Even before I joined them Freescale had been very active in VSIA. Freescale has its own internal semiconductor reuse standard. They donated portions of that several years ago. Not only myself but several other people in Freescale are very active. This is not public knowledge but there is going to be another donation from Freescale to VSIA which will be available to the industry.
Are the people in the various working groups actively supported by their employers? Is this a requirement for VSIA membership?
For the participation to really work, it has to be something that the people are really interested in. You can't force somebody to come up with something for the good of the industry because they are being told to. It is something they have got to believe in. With the way companies are utilizing resources nowadays, everybody is overworked at this point. You definitely need company support behind you to allow you to take the time to do it. It's a little bit of personal interest and company support.
Some organizations have different types of membership in terms of fees and resource commitments. Is this true of VSIA?
Not really. We have different tiers of memberships. They have different financial obligations. We do not require minimum participation in the working groups, although it works out that way. People who are really involved and interested make it a point of trying to contribute. We do not try to put restrictions on members that other organizations do, is the main point. We definitely have committed people in VSIA and then there are some who for whatever reason can't commit the time to it. They communicate via email and attend meetings whenever they can.
Would you describe VSIA as a national or international organization?
It's definitely international. There is a lot of interest from Asia; Hong Kong, China and Japan. We have a lot of participants from Europe. It makes it real interesting sometimes when you get on conference calls.
A couple of years ago there was a restructuring of VSIA. Any comments?
That was under the previous president.
Hillary: Basically VSIA had 12 or 13 working groups. The previous president decided to reorganize and focus on 3 or 4 topics of interest to the members and dedicate the resources accordingly. We were spread too thin and wanted to make sure that we gave value back to members on what they though was valuable by focusing on IP protection, quality and transfer.
How would you describe VSIA?
VSIA is kind of an umbrella organization established in 1996. It crosses the IP ecosystem. We are looking from IP development, how it is handed off and evaluated through the integration process. We are really trying to enable the efficiency of the IP ecosystem.
The big thing is to contribute to areas that cause pain to everyone in the industry and try to drive the industry to a common solution. It is really sharing the cost of coming up with that solution that our members are finding a lot of value in.
VSIA is not as nichey as other organizations. That is a perfectly valid business model and definitely needed. But what we are trying to do is take a high level view of how the IP works throughout the entire space and to interact and closely collaborate with these other organizations. Make sure we are not duplicating effort and resources.
The board right now has 8 sitting members (ARM, Cadence, Freescale, HP, IBM, LSI Logic, Mentor Graphics, and TSMC). We are getting ready for an election in July. The membership mix may change just a little bit. I expect to grow by at least 1 or 2 members.
There are around 75 members including the big three EDA firms, leading semiconductor firms and companies like IBM and HP.
We have generated a number of formal VSIA documents - specifications, standards, and other technical documents. Some are available publicly while some are only available for members. A lot of these have been used as baselines for internal development and used as a jumping off points for internal company action. The QIP Metric is one of the things that we are saying that derivative works are not allowed because if you start deviating on the standard measurement for quality, it defeats the whole purpose of having the standard. It is meant to facilitate the exchange of IP between vendors and users.
We are working collaboratively with other organizations. We are working with FSA on extending the QIP to hard IP. We are in discussions with Si2 about tagging and protecting IP and how it fits into the OpenAcess model. Right now the spec from VSIA is strictly for GDSII. That's one area where we really want to explore. We are also talking to Spirit about packaging and transfer because there are some XML aspects to some of our work that we want to make sure fir in and tie in to what Spirit is trying to do.
QIP has generated a lot of interest since it has come out in January. There have been 1,000 individual downloads of it. It is really being used as a kind of springboard to a whole lot of other work that is going on. It definitely has ties to the other working groups. For example this deliverable checklist BOM work ties in with the QIP Metric. QIP provides an overview of the quality of an IP as a whole deliverable checklist. We actually delve down into the details of specific deliverables that are being handed off. We are trying to facilitate productivity and the exchange of IP.
Would you describe QIP Metric?
QIP Metric stands for Quality IP Metric. Right now it is implemented in an Excel spreadsheet. It may not be the best mechanism but it is functional now. We are looking at what might be a better mechanism. What it does is try to quantify the quality and usability of an IP as a whole. There are three main focus areas that look at the vendor: what their methodologies and procedures are, what kind of support they have. It tries to quantify the stability of the company. Is it two guys in a garage or a really world wide organization? Then it looks at two aspects of the IP quality. It looks at things that integrators are going to need to know when they put it into their system, so the things that immediately affect them. It's the documentation, the interfaces, the build environment, the verification environment. The third area is the development of the IP. There's a lot of things that go into it that impact the quality and usability of it that the end user may not have immediate visibility into. It lets you know that care was taken in developing it and that it will definitely affect the ability to turnaround bug fixes enhancement or derivatives.
QIP came out last year. It was a very flat spreadsheet. We got some feedback that it was intimidating and hard to use. We went through a lot of effort to convey the information to the person that needs it and to make it much easier for the provider so that it wasn't an onerous process to go through. Once you fill out the vendor qualification portion, that's it. It is done unless something major happens to your company. The developer portion is what is done on a standard basis. So this would be filled out once per design group. The only questions that a vendor needs to complete on an IP by IP basis are the integrator questions. It makes it much easier for integrators to evaluate IP. They can start at a high level. If they decide that they don't want to do business with a particular vendor, they don't have to spend a lot of time looking at the IP specific information. The more interested they get, the deeper they can look into the details.
One of the big points I want to make about QIP is that although it gives you a score, the absolute number doesn't have as much meaning as the information that is conveyed in QIP. It is meant to be a communication mechanism to highlight where the stumbling blocks may be using the IP so that you can develop a migration plan upfront and really be able to scope the work as opposed to running along normally and hitting a bring wall and having to wait for the vendor to get back to you. It's really intended to ease the process from the beginning.
QIP is a self-scoring evaluation.
The IP provider fills it out. The questions are weighted so that there are imperatives. These are things that the group felt if they were not meant, the IP would be virtually unusable or very difficult to reuse. Any imperative that is not meant is highlighted and is going to be immediately obvious to the integrator. We have gotten a lot of good feedback on it. Before we released it, it went through a substantial beta program where we partnered providers and integrators together to use QIP on a piece of IP and give us feedback on whether it really did relate and convey the integration experience and on how useful it was.
End user comments, evaluations and feedback are not part of the QIP. It's vendor input only.
Right! We don't have an Amazon feedback form. Everything in the QIP should be quantifiable. There was a big effort to ensure the questions were not subject to interpretation. There could be proof behind them. You need a lot of trials or documentation. It really doesn't make sense for vendors to stretch the truth because it is going to come back and bite them. It is available on the VSIA website if you want to check it out.
Editor:
The VSI Alliance calls its working groups pillars. Currently there are four pillars: IP Quality, IP Protection, IP Transfer and Research & Development. Creation of a Pillar requires committed interest from at least four large industry companies. Each Pillar addresses both technical and commercial solutions to IP integration and reuse.
|
The IP Quality Pillar defines the essential Quality Attributes of any IP core required to make it properly functional and efficiently reusable in SoCs; creates a VSIA Quality Metric to motivate the use and measure the presence of these Quality Attributes
The IP Protection Pillar defines, documents, and demonstrates open, interoperable, standards-based solutions and promotes awareness of IP protection schemes and practices that balance the necessary level of security with customer usability of IP to foster the proliferation of design reuse. The IP Transfer Pillar provides standards facilitating the exchange of IP between consumers and providers. Key goals of the Pillar include IP design flow automation, incremental IP delivery and IP directory structure remapping. The R&D Pillar is committed to studying and determining the future direction (three to five years out) of challenges facing the industry, such as IP valuation, ultra-large block reuse, design for manufacture, signal integrity, verification of implementation, analog firm, hardware-dependent software, platform-based design, and other key long-term issues as they are identified |
Yes! There are two specifications for tagging already released from VSIA. There is one for soft tagging (Virtual Component Identification Soft IP Tagging Standard) and another for hard tagging (Virtual Component Identification Physical Tagging Standard). There is a new version of hard tagging that should be released soon. A tool to support this will also be released. There are a lot of uses for tags. They have been adopted by several of the foundries. I can't speak for all of them but I know several of them are using them. There are a couple of really good reasons to use them. The assurance that you are using the correct version and the correct configuration management that all the files you are using are the actual files that you are supposed to be using. The there is also providence in being able to track the history of the IP for bug tracking, for yield or for whatever other application you may come up with. Probably the most important to some people is the identification of ownership. This can be used for revenue. At Freescale we use the tags heavily for identifying the source, i.e. which of IP partners, where it actually came from when it goes through the fab.
You really can't protect IP, if you are giving it away. Once it leaves your hands, it is difficult to perfectly protect it. But we are trying to come with ways to detect and prevent either inadvertent or malicious changes. Tagging at this point is really a trust issue. Watermarking and fingerprinting are areas where we are actively pursuing. This is something where we have been in discussion with academia to see if there is any research we can leverage. There is a lot of work going on.
Future plans for VSIA?
The template for a standard is a four to six months beta program following a six to eight month development effort. Our tentative schedule subject to board approval has
| QIP - Soft IP & Vendor Evaluation released QIP - Hard IP approaching beta. This is a collaborative effort with FSA QIP - Verification just started BoM - Soft IP & Verification Package beginning now BoM - Hard IP beginning in October |
Does VSIA have any relationship with IEEE?
At this point I am not sure that we have anything that makes sense to submit to IEEE. QIP is not a static document. It is not only being extended for different types of IP but its methodologies and technologies change. It is going to need maintenance and updates. I don't see it as something that can have as long a lifecycle as some of the specs coming out of IEEE. Truthfully, it is not something that has made sense for us up to now. I am not saying we will never do it. But at this point we don't have the right content.
The top articles over the last two weeks as determined by the number of readers were:
Cadence Delivers New Space-Based, Full-Chip Router for Advanced Mixed-Signal and Custom Digital Designs Cadence introduced Precision Router, a space-based, full-chip and block routing solution for advanced mixed-signal, analog and custom digital designs. The product speeds design and manufacturing convergence by allowing designers to model manufacturing effects during the design process for design performance closure and faster time-to-volume manufacturing ramp-up. Cadence Precision Router operates seamlessly with the Virtuoso custom design platform and provides a hierarchical and constraint-driven design closure environment with highly incremental interactive and automatic routing. Cadence Precision Router, along with Cadence Chip Optimizer, is built on innovative technology developed in Cadence's Project Catena technology incubator.
Mentor Graphics Announces New Bit-Accurate C++ Datatypes that Accelerate Algorithm Validation by 10x Mentor announced the availability of Algorithmic C(TM) datatypes, new high-speed datatypes based on ANSI C++. These arbitrary-bit-width datatypes enable algorithm, system and hardware designers to precisely model bit-true behavior in C++ specifications while accelerating simulation speeds by 10-200x. Mentor Graphicsis making the new C++ datatypes immediately available to the electronics designers and (EDA tool vendors free of charge on its website.
Pyxis Technology Raises $9.2M in New Funding Pyxis Technology announced that it has raised $9.2 million in Series B funding. Formative Ventures of Menlo Park, California led the round with participation from Series A investors: Austin Ventures and CMEA Ventures. Funds will be used for continuing R&D and to begin developing sales and marketing infrastructure to support customers. The company is focused on DFM routing technology based on a new software architecture optimized for design for manufacturability, which reduces design closure cycle time while improving overall design yield.
ADVISORY/ Five Reasons to Stay at DAC 2006 until the End of Thursday, July 27th At 4:30pm on Thursday there will be a panel “DFM: Where's the Proof of Value?". Panelists from Aprio Technologies, Blaze DFM, Clear Shape Technologies, Mentor Graphics, Pyxis Technologies and Synopsys will present information on how their DFM tools fit into a fixed design methodology, budget and timeline, and give real-world examples of expected ROI.
Micronas Tapes out HDTV Chip With Synopsys' IC Compiler This new chip is a key part of Micronas' drive to improve picture and sound quality for flat-panel TV and to provide benefits to manufacturers in the total cost structure from R&D to production, based on very high integration. Using the Galaxy design platform with new IC Compiler optimization technology, Micronas was able to tape out this design at the required performance while achieving a remarkably high utilization in excess of 90 percent.
Sequence Powers Up For DAC -- Booth 1614; New PowerTheater 65 Highlights Low-Power Leader's Strategy For 65nm Design Sequence Design will unveil a host of new technologies for low-power design at this year's DAC, headed by its new Silicon Aware PowerTheater 65, an RTL power analysis and management solution targeted to address the challenge of designing at 65nm and below.
Synopsys Continues IC Compiler Momentum With 2006.06 Release The 2006.06 release of IC Compiler, Synopsys' next-generation place-and-route system, delivers advances in the areas of integrated design planning, enhanced physical test, advanced low-power design, true concurrent multi-corner/multi-mode optimization, and design-for-yield techniques. The 2006.06 release allows flat floorplan creation and refinement in the same environment as physical implementation -- placement, clock tree, and routing. These capabilities utilize proven technologies from the JupiterXT tool for floorplanning, automatic high-quality macro placement, and automatic power-network synthesis and analysis. The integration brings about commonality in graphical user-interface, timing analysis, placement, and global routing technologies, to drive higher-quality floorplanning and faster time to results.
Other EDA News
VaST Systems Technology Names Colin Lythall as Director of Engineering
Cadence Test and Formal Verification Technology Speed Time to Market for Matrox
VeriSilicon Announces Acquisition of ZSP Digital Signal Processor Unit from LSI
Azuro Enables PowerCentric for 65nm
GiDEL's PROCWizard™ enables full hardware and software integration.
43rd Design Automation Conference to Feature 44 New Exhibitors
Ross Video Selects Synopsys' VCS SystemVerilog Native Testbench to Increase Verification Productivity and Predictability
Altera Adds New Member to Cyclone II FPGA Family
Accent Emphasizes Greater Design Chain Productivity with Semiconductor Data Management Solution from ENOVIA MatrixOne
Optimal Corporation, Rio Design Automation Partner to Solve Chip-Package Co-Design Challenge
Nanno SOLUTIONS Launches Company
DAFCA Announces Availability of ClearBlue(TM) Debug Infrastructure IP and Software Product Family
Real Intent Introduces Conquest(TM) and Ascent(TM), Leading the New EnVision(TM) High-Performance Formal Verification Family
Other IP & SoC News
Rambus and Matsushita Sign Patent License Agreement
STMicroelectronics' New Voltage Regulator Shrinks Portable and Battery-Powered Devices
ISSI Acquires Alliance Semi Synchronous SRAM Product Line
SigmaTel Announces Second Quarter 2006 Earnings Conference Call and Webcast
MagnaChip Introduces CMOS Sensor CSP Solutions
UMC Collaborates with NTU to Deliver RF Chip for WiMax
Abilis Systems Announces Manufacturing Agreement With IBM Microelectronics
You can find the full EDACafe.com event calendar here.
To read more news, click here.
-- Jack Horgan, EDACafe.com Contributing Editor.