标签: modelling

Part 6 of this experts' roundtable covered IP integration issues. We now conclude this series by looking at the issue of system-level modelling. Taking part in today's discussion are: Mike Gianfagna, vice president of corporate marketing at Atrenta; Warren Savage, CEO of IPextreme; John Koeter, vice president of marketing for the solutions group at Synopsys; and Chris Rowen, Cadence Fellow and CTO at Tensilica. Brian Bailey : Are we at the point where enough high-level models exist for people to do system modelling? Chris Rowen : I think a lot of pieces are coming together, but it's not a no-brainer yet. Warren Savage : John and I recently had a question: "Where are my SystemC models?" I asked, "Are you willing to pay extra for those models?" The customer's response was "No, that should be part of the price." I think we're still in the space where the value proposition for people to be willing to pay extra money to feed the development side of things is not yet there. I think it's coming, but it's a slow slog. John Koeter : It's definitely coming, though. Savage : I think it will probably happen for the things where there's a lot of volume, but then we're going to have the fringes, the verticals, that are not economical unless there's a compelling reason. Koeter : You also have to ask, "What is the system-level model." Is it a loosely timed model? Is it cycle accurate? Is it cycle approximate? These terms get thrown around with not the best definitions. Mike Gianfagna : That's a tremendous problem. You trade accuracy for speed. You cannot run software with a cycle accurate model. Bailey : Isn't there enough demand to clarify what is necessary? Koeter : For us, it is very clear. Our models, generally speaking, are loosely timed, and with partners, we have access to their fast models. We create models for our own IP. We also have another tool which is more for platform architecture. For that, you need at least timing approximate, if not cycle accurate, so it's different needs. Are you looking at your architecture, or are you looking at creating a virtualized model of your SoC for software development? Those are two totally different scenarios—closely related, but different. Rowen : The ideal is get to a system in which there is one big knob—the big knob that says the level of accuracy for each block. Given that it's usually performance versus level of detail, people can systematically work from the software scenarios down through these cycle-by-cycle scenarios without switching tools or methodologies. I think that this is a useful by-product of some of the consolidation which has taken place. It is likely to be a barrier for some of the small shops if they have to have this range of models. But this seamless model that scales from being fast enough so somebody can boot an operating system to accurate enough so that they can figure out the picosecond-by-picosecond power is ideally what you want. The fact that somebody needs something which is new and differentiated and important is the first step towards getting a real industry shift towards making this kind of support for modelling at every level, whether it's completely in simulation or it's emulated or it's in FPGAs—just so long as it's seamless is really what's critical. *** And with that, we conclude our discussion on IP. Do you use system-level modelling, or do you think it has enough value that you would be willing to pay for the creation of models? What do you use it for, and what level of models would be the most valuable to you? Brian Bailey EE Times  

In the previous instalment of this experts' roundtable, we discussed IP integration issues. We now conclude this series by looking at the issue of system-level modelling. Taking part in today's discussion are: Mike Gianfagna, vice president of corporate marketing at Atrenta; Warren Savage, CEO of IPextreme; John Koeter, vice president of marketing for the solutions group at Synopsys; and Chris Rowen, Cadence Fellow and CTO at Tensilica. Brian Bailey : Are we at the point where enough high-level models exist for people to do system modelling? Chris Rowen : I think a lot of pieces are coming together, but it's not a no-brainer yet. Warren Savage : John and I recently had a question: "Where are my SystemC models?" I asked, "Are you willing to pay extra for those models?" The customer's response was "No, that should be part of the price." I think we're still in the space where the value proposition for people to be willing to pay extra money to feed the development side of things is not yet there. I think it's coming, but it's a slow slog. John Koeter : It's definitely coming, though. Savage : I think it will probably happen for the things where there's a lot of volume, but then we're going to have the fringes, the verticals, that are not economical unless there's a compelling reason. Koeter : You also have to ask, "What is the system-level model." Is it a loosely timed model? Is it cycle accurate? Is it cycle approximate? These terms get thrown around with not the best definitions. Mike Gianfagna : That's a tremendous problem. You trade accuracy for speed. You cannot run software with a cycle accurate model. Bailey : Isn't there enough demand to clarify what is necessary? Koeter : For us, it is very clear. Our models, generally speaking, are loosely timed, and with partners, we have access to their fast models. We create models for our own IP. We also have another tool which is more for platform architecture. For that, you need at least timing approximate, if not cycle accurate, so it's different needs. Are you looking at your architecture, or are you looking at creating a virtualized model of your SoC for software development? Those are two totally different scenarios—closely related, but different. Rowen : The ideal is get to a system in which there is one big knob—the big knob that says the level of accuracy for each block. Given that it's usually performance versus level of detail, people can systematically work from the software scenarios down through these cycle-by-cycle scenarios without switching tools or methodologies. I think that this is a useful by-product of some of the consolidation which has taken place. It is likely to be a barrier for some of the small shops if they have to have this range of models. But this seamless model that scales from being fast enough so somebody can boot an operating system to accurate enough so that they can figure out the picosecond-by-picosecond power is ideally what you want. The fact that somebody needs something which is new and differentiated and important is the first step towards getting a real industry shift towards making this kind of support for modelling at every level, whether it's completely in simulation or it's emulated or it's in FPGAs—just so long as it's seamless is really what's critical. *** And with that, we conclude our discussion on IP. Do you use system-level modelling, or do you think it has enough value that you would be willing to pay for the creation of models? What do you use it for, and what level of models would be the most valuable to you? Brian Bailey EE Times  

Electronic and Embedded design is increasingly becoming complex. A model driven approach to design is one way to deal with this complexity by lifting the level of abstraction at which designers work. In fact modelling is an important aspect of ESL Design (Electronic or Embedded System Level). A model is a specification of a device, processor or system that is being developed which has the look and feel of the final system (Example: prototype). It may also be a replica of an existing system used to analyse certain properties of the system. Several kinds of modelling languages, frameworks and tools have been developed over the years by design automation researchers. These allow embedded designers to to work with higher level abstractions (models) using model driven tools to automate one or more development activities Understandably, It is not easy to create modelling frameworks for embedded system design. Embedded systems combine different types of components for realising system behaviour#8212;RF, Sequential, Combinatorial, Programmable Logic and Processors to name a few into a single system. A modelling language that works well for one component type may not work really well for the other. This did not stop the ambitious from trying to create a single language that attempts to work for many of these (like SystemC). Such attempts have traditionally yielded mixed results. If one looks at the modelling technologies in the general IT space, one sees a plethora of standards. Just one organisation, The OMG has come out with different specifications like UML (Unified Modelling Language), SysML (System Modelling Language), BPMN (Business Process Modelling Notation) and so on. Modelling it appears can replace one kind of complexity with another. Clearly design teams need a good strategy in place if they intend to take advantage of model driven development. There is no doubt that the right model driven development strategy can give an organisation a significant competitive advantage in the market place. I intend to share my thoughts and experience on how to take advantage of modelling in the development of complex electronic embedded designs through this blog. Stay tuned.