Agile Standards

Semiconductor Engineering sat down with Lu Dai, chairman for Accellera and senior director of engineering at Qualcomm, to discuss what’s changing in standards development. What follows are excerpts of that conversation.

SE: Accellera has had a great first half of the year.

Dai: Yes, we are only half way through the year and yet we got Portable Stimulus Standard (PSS) out, the SystemC CCI and we still found time to do the UVM reference implementation. In addition, we are starting to talk about IP security assurance (IP SA). This is a proposed working group and they are still working on defining the scope, but in just two months a lot of companies showing interest.

SE: How did this get started?

Dai: There is a lot more user input today, both during the development stage as well as in the initial proposal stage. The IP SA proposal came out of a published Intel and Qualcomm paper. Users are looking at their day-to-day life and looking at where they see the most pain. They come up with some ideas and those are then shared amongst the users. Then they start to get the vendors to develop tools to help. I want the tools to be in a standard so that I can pick and choose the vendors based on the capability instead of being stuck with certain vendors. So, it is as if the user already has an end solution in mind and they are looking for a standard as a way to insure compatibility amongst the vendors. Verilog and VHDL came from a vendor source and then users learned how to use it – now it is the user who says this is the way I want to write things. Can you help me to make sure that what I am proposing is a clean solution, that is a compatible solution? This makes the adoption of the standard faster because you don’t have as much of a ramp time for the user to learn things. They already have the need, or similar deployment, so they just convert from an in-house custom solution to an industry standard solution through a commercial vendor.

SE: In the past, there was a lot of innovation going on within EDA companies. The users basically picked and chose which ones worked for them and which ones didn’t. Today, there are far fewer EDA startups and far fewer new solution offerings. The large EDA companies do not invest in new areas until there is user demand, which means that we are unlikely to see defacto standards being created again. That means we are likely to see more design by committee.

Dai: In some sense it is true. PSS involves many companies and a lot of them are fairly senior in their companies and with standards development. Everyone has their own opinions about how things should work. If I design a chip within a company and my chip team has 50 people where each of them reports to a different branch of the company, it does create some challenge because they all have their own ideas. Who has the final say about how it gets implemented? There are a lot of competing ideas – so how do you consolidate that. The PSS working group did a good job getting everyone focused on the end solution, getting to the end goals, and not getting carried away with the tiny details. The fact that they could get PSS released in three years is pretty impressive. I joked that some company’s chip design process takes more than three years and we have a brand-new industry standard coming out within that time period. Yes, there is more to come, but the 1.0 is a fairly usable solution.

SE: PSS is very different from a DDR standard. When a DDR standard is created, it is created as a stretch goal that it is expected it will take several years before it can be fully realized. With PSS, it is more of a minimum of what can be implemented now. Should we be making standards that stretch the EDA companies?

Dai: I can look at PSS, as a language standard, and compare that the SystemVerilog. PSS is a syntax, a language that can be used for doing verification and from that perspective it is similar to SystemVerilog. When SystemVerilog first came out, and even up to now, the vendor tool implementations still take a subset of the constructs. Of the LRM, there is legal syntax in SystemVerilog that the vendor may not have implemented or they have a subset of that construct. That is what we see from SystemVerilog or UPF type of standard. For PSS, what is likely to happen is that some vendors may actually implement a superset – their solution will have all of PSS 1.0, plus they have something that will come in 1.1, but because it is not there yet, they will provide some customizations that provide additional features.

That is a special case and may not happen in future standards, but in this case you have a couple of vendors that were more ready and have mature tools in the marketplace already. They donated some of their knowledge to the standards group and the committee was able to agree upon a subset of that but not everything. From a user perspective, I do have a concern that if I use the additional features from one vendor, I may have lost a purpose of the standard. We do see one vendor offer a mix and match solution where basically you can write your code in PSS and you can write some code in their custom solution and they will work together. I can stay with that vendor even though I am not 100% PSS compliant, but they give me an option that I can migrate to a full PSS for some advanced features that are still being discussed for 1.1. So, I am not as worried. This is better than the SystemVerilog scenario where I still have headaches with my in-house usage because I have written code based on the LRM and a lot of the engineers got trained at school and may be following the LRM to the teeth and then they have their implementation taken by one vendors tool and it does not work, or sometimes even on the same vendor when I move from a front-end tool to an implementation/back-end tool.

SE: Is that the responsibility of the standards organization to close the gaps, or is it just for the vendors to fight out?

Dai: A small subset of the issues belongs to the standards group. Certain syntax may not be clearly defined. But the majority of them are vendor company issues. They have limited resources and they look at the users and the syntax that the language supports. They will implement the things that the users are asking for, but others will wait until there is a need or they run out of things to do – but they never run out of things to do. So if the user company does not push them for that particular thing, or they are only seeing one user pushing it, and if they are not a high-paying customer, then they will say – I understand that it is legal, but I don’t have the support for it today.

Coming back to PSS, one advantage, when you do a subset, is that users are asking for that strongly. So, the vendors all hear loud and clear and if you don’t have that support, then I will not buy your tool. While on SV, we have a nice syntax, but fewer users ask for it and vendors choose not to do it.

While each company may have their own compatibility check, they do not have cross vendor checks. This is their crown jewels and they don’t want other people to know what subset of the syntax they don’t implement. I was hoping that someone would push out a compatibility test for PSS, but so far nothing has happened. We have some in-house solutions about how to deal with that, but I should not have to do that at the user level.

SE: The rate of uptake for consumer devices is accelerating. Are we seeing the same with standards? It took 10 years for SV to see broad adoption. Will it take 10 years for PSS?

Dai: I don’t think so. You have to look at who the standards are trying to target. For PSS, it is a standard that primarily targets the SoC and systems guy and potentially for post-silicon and software folks. Another user group is the IP verification folks. PSS is not designed for them, so adoption for IP verification is probably going to take a lot longer. However, for the SoC side, I expect adoption will be fairly fast. If I compare that to SV, SV took a long time and targeted everyone from system design and verification to SoC.

For PSS, I think there will be two different slopes – SoC vs IP. Overall, I think adoption of standards is getting faster. UVM adoption was faster, UPF was also pretty fast compared to SV. It matters that the standard has a target audience in mind and also additional audiences that may adopt at a slower rate.

SE: How does Accellera work out when is the right time to transfer a standard to the IEEE?

Dai: I don’t know if we have a preset schedule for the transfer. Typically, we see it when a standard developed by Accellera has sufficient user adoption. If we have a standard that we think is good but there is only a small subset of the users using it, then IEEE would probably not be interested in continuing that effort. Some standards also need wider adoption within the user community outside of the typical Accellera reach. Accellera is still primarily North America, but with IEEE you can reach a lot more users internationally. If we see the standard is ready for that type of growth, then we start to talk about transfer to the IEEE. Accellera is also broadening its reach with DVCon India, China and in Europe.