Are Models Holding Back New Methodologies?

Semiconductor Engineering sat down to discuss the state of the industry for modeling at abstractions above RTL, a factor which has delayed adoption of and the proliferation of system-level design and hardware/software codesign. Taking part in the discussion were Frank Schirrmeister, group director, product marketing for System Development Suite at Cadence; , CTO for Carbon Design Systems; Nick Gatherer, engineering manager for models within the processor division of ARM; Victoria Mitchell, director for SoC software within Altera; Marleen Boonen, CEO and founder of Methods2Business; and Tom De Schutter, product marketing for Virtualizer at Synopsys. In part one, each of the participants provided an outline of the current state of modeling and virtual prototypes, from their perspective. Part two contained a lively discussion about the state of approximately timed (AT) models. What follows are excerpts of that conversation.

SE: What is so different about and virtual Prototyping that they cannot use the same models?

Boonen: My team has three months to develop the MAC layer for WiFi. We use high-level synthesis (HLS) and virtual system prototypes (VSP) from day one. Both of them are necessary to build the quickly because without the VSP there is no single means to build an IP which contains both complex hardware and software and it is these two together that are a MAC. If there is no way to bring the software alive then it is difficult to understand the MAC layer and the kernel. My synthesizable model is the model in my platform. It runs very fast because it is event driven.

Schirrmeister: I appreciate the need to have both the system view and the implementation view and that you want them interacting. You have managed to build one model and in that model you have the ability to switch on and off certain things. When we describe it we have to be precise because someone could have done it using two different models, but you chose to put it into one model with a switch. For fast execution I switch off some of the clocking aspects which are required for HLS, but keep it all consistent in a single model. This also enables the system software to be combined in the building of the IP to optimize the IP.

Boonen: This is a requirement because I don’t want to have two models and it has a much higher value now because all of the verification is done on one model including the software being validated on the model which is my design.

Mitchell: It is a slightly different interpretation of the term “golden model” but I see why you use it and that is an application of golden model that I hadn’t thought of before.

De Schutter: This is not yet a common methodology, but it is very nice in the way it has been done. In general, the HLS model is a very accurate model…

Boonen: No – my model is the entry for HLS and is an untimed SystemC model.

Schirrmeister: When I think about a universal golden model, it is a model in an arbitrary language, such that using tools and automation I can get a model suitable for both virtual prototyping or implementation without having to know the specific needs of either environment. This is a dream.

Mitchell: Yes, this is similar to what I see for a golden model.

Boonen: OK, now I challenge you to provide the automation for that.

Schirrmeister: This enables you to have a single model, so everything stays synchronized, that acts as the knowledge base for the person who knows how to make it fast and another that knows the requirements for HLS.

Gatherer: It depends on the IP as well. I would have done it the same way, but if we look at a CPU, you would not even start that discussion. To make a model that can run at a few hundred Mips, but also an optimized piece of silicon with low power and all of the demands, there is no technology that can bridge that divide. The golden model concept is interesting. I never declare any model as golden, although we are often asked how we know the models are correct. The answer I give, which is somewhat facetious, is that they are correct because we deem them to be correct. We do a lot of validation on them, but there is also an element of the same interpretation of a specification being reused like an executable spec. When we build a complex model of a processor, we use that to auto-validate the specification of the device we are making, that model is the same model that will be provided to operate in a virtual platform. The same model is used everywhere and every design is signed off against this for compliance. This is also how we protect the ecosystem. I still do not call it golden, but there is a continuity in interpreting it.

Boonen: I can call it golden because my model is used to create my RTL. I can actually customize it for my customers.

Schirrmeister: I get excited about models because they find things that you don’t find by other means. I have seen a customer running a software workload on a model and they were running it on and FPGAs. It ran on emulation, but it did not run on FPGA and it did not run in the model. They were finger pointing at the modeling guy. It turns out that the model had correctly implemented the specification, and the difference was the way in which memory was initialized. This enabled us to find the bugs. When you rely on automation, if there is a bug in the model, then it will also be in the RTL. The beauty about a parallel approach, even though I hate it, is that you find bugs that otherwise may not have been found.

Boonen: I do verification on the SystemC model, and it is repeated on the RTL and I also use , unfortunately only on the RTL code – this is a challenge for SystemC models…

Neifert: There are a lot of companies using HLS and there are a lot using virtual prototypes, but why aren’t there more people using them together? Even if a company is using both of them, it tends to be different groups and they never come together. I would love to see them come together. Better people than me have tried to make this happen.

Boonen: When you are a small company, you don’t have these walls. Big companies have groups which a specific focus.

Mitchell: We tear down those walls as well. People raise their eyebrows when they see what we are doing, but we do have people crossing the lines. There are a limited number of people who can think across the lines and we may have to go back to the Universities and revise their view of an engineering methodology so that people can start to think like this and not say I am a hardware guy, or a software guy, or verification…

Boonen: This is part of our methodology. We use the best tools and methods, and the next generation of engineers. They need to understand hardware and software.

Mitchell: I think we, as tool vendors, have the responsibility to go back to the Universities and tell them we want to change the way of thinking. It is no longer good enough to do things the way they were in the 80s.

Boonen: I had to change my software team last year because they were not using the VSP. They could not understand that their software had to run there.

De Schutter: We also have to remember that HLS does not lend itself to all kinds of IP. For some pieces you are stuck with having to create models and building RTL and there is no tool that can do it for you.

SE: What is missing that would enable us to get to a golden model above RTL?

Mitchell: Standardization. We need a standard interface so that we have the flexibility to switch approach, between HLS and SystemC and between cycle accuracy and approximately timed models. Standardization would allow us to mix and match depending upon the type of IP. Until we agree on the right abstraction layers I don’t think we will be able to have all of the pieces come together.

Gatherer: The word of caution is that in the early days, when we talked about virtual prototypes, we had a lot of grand ideas about what we might be able to do and achieve with automation. The things we have really achieved have come from bringing some pragmatism into the discussion. Our models get put into a very diverse range of products and you have to be pragmatic about the questions people are trying to answer and not be drawn into to trying to solve all problems with one solution. We have been successful with fast models because they are solving one particular part of the jigsaw puzzle. The hybrid solutions are also very exciting because they allow some of the best in class solutions to be brought together to build powerful validation scenarios.

De Schutter: More than having a golden model from which pieces are derived, models are standing on their own for the specific use cases they solve. We are seeing the need for a model for software development, for verification, and for early architecture and power exploration – and they stand on their own merits next to an RTL model. This is making people realize that there is a benefit to having modeling teams and more companies are beginning to do this. There are also benefits from doing things in two different ways and using it as a way to check the RTL. I am not a believer in having one model from which everything is derived.

Neifert: We have seen much of this already. There is not a single approach that is going to work in all cases. We serve both approaches, the high-level models and the accurate model and have a dynamic switch. You start and run until you get to a point that matters and then switch over. The hybrid solutions are trying to solve some of that problem using a different approach. The ability to combine high-level and accurate models will release an additional set of values.

Boonen: I am really happy that high-level synthesis has become a reality. I have been using SystemC since 2000 and now it is coming together and when it is time to go to RTL, I like a hybrid approach so that I can keep the virtual platform alive and see my software running along with rapid prototyping where I have my RTL – all in a single environment. I am quite happy and I also see more opportunities for formal and SystemC which is the next challenge.