Which came first … the model or the tool?
One of ESL’s great chicken or egg questions is: do ESL modelling tools encourage the development of models to fit, or does model availability encourage the development of and use of ESL modelling tools?
Viktor Hartmann, Sketch of costumes for Ballet ‘Trilby’ (an inspiration for part of Mussorgsky’s “Pictures at an Exhibition”: Ballet of the unhatched chicks)
I was reminded of this conundrum while reading a press release from Synopsys (one of the pre-DAC runup in EDA-related press releases from many corners), on “Synopsys Adds 30 New Titles to DesignWare System-Level Library“, dated May 15, 2008. In this release, Synopsys discusses the addition of a number of transaction-level models to their SystemC libraries, including models of DesignWare IP blocks such as PCI Express 2.0 interconnect components, and processors such as PowerPC and MIPS.
The usage of system level models and virtual prototype or virtual platform models, in a number of tools including POSC (Plain Old SystemC), has long been felt to be gated by model availability. With this in mind, the availability of new models for components, especially interoperable SystemC models, but also including models with proprietary interfaces, is a good thing. The more models, the more likely it is that users of any of the tools out there will find models of existing IP available when they want to build system models of their complex designs.
All such developments will encourage more people to look into building system models, and the growth of use of system modelling (and the derivation of benefits thereby) will feed into a virtuous circle, where ESL modelling usage increases, encouraging demand for more models of components and IP, encouraging the growth in model availability, thus encouraging an increase in ESL modelling. Let’s hope that eventually the issue of model availability will become a secondary or tertiary issue in the growth of ESL modelling and usage.
4 Comments »
RSS feed for comments on this post. TrackBack URI
Leave a comment
Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
May 23rd, 2008 @ 1:15 am
I would suggest that models drive the adoption of ESL for software development and architecture analysis. It is very difficult to take advantage of ESL techniques if you’re missing one or more important component models. Tools, on the other hand, usually don’t have all the features required or desired so users improvise. An example of this would be “POSC” (the OSCI kernel) is spartan but popular. It is unconstrained and relatively easy to augment.
Do tools make it easier to write and use models? I would suggest that tools can add to the cost of developing models because many of the value add features require the model developer learn and use proprietary APIs. This is a significant burden when the model is to be reused in several different tools. In ESL, interoperability extends far beyond the transaction interfaces. We still must take huge strides in interoperability for model configuration, instrumentation and debug.
May 30th, 2008 @ 12:30 am
Model availability always gates the use of any sort of modeling tool. I’ve found it more pressing in the system architecture space than say for software development, simply because system architecture is the bit you come to first, when you start thinking about building a platform/chip/ HW/SW widget.
Marketing comes up with a grand idea. Then if you are into the whole ESL thing, you almost immediately want to start slinging prototypes around, exploring the performance, maybe running snippets of algorithms, exploring the bandwidth issues and other performance corners that are the focus of much of the back and forth of the initial system and architectural design.
Peripherals on the boundaries of the chip functionality can be happily abstracted away to a large degree, but models of those core bits that really influence the performance are key. Worse still when you are considering evaluating different options from external IP vendors.
The models are never ready when you want them, usually because the companies are still designing the IP and either do their design first and create a model last, or wrote the model in some other language than the one you want to use, for a customer that uses a different interface or hooks up to a different sort of modeling tool.
All of these are very solvable problems and can easily be worked around with a 6 month lead time and some money and engineers thrown at the problem.
But for system design, you need those models now and you’d better be finished in 6 months time or maybe turning it into a nearly final virtual prototype to be starting your software development.
The killer for ESL IP availability, if you want to be using anywhere near current IP or the latest and greatest processors is the complete lack of lead time on the need for models. Excel almost always wins that race.
May 30th, 2008 @ 11:01 am
Gordon, that is a great comment. With tongue well pressed into my cheek, I would say that the best IP vendors (such as the one I work for) have a strategy whereby models are generated as part of the IP generation process - this is an absolute pre-requisite if you are developing configurable, extensible processor IP, because potential users/customers absolutely need a model base and an ability for automated model re-generation as they iterate over their configurations and extensions. In many ways the model issue for IP would be resolvablle if all IP vendors took the same tack - that models are an indispensable part of the deliverable, and if they develop their IP and models in parallel with a configurable idea in mind, the users/architects would be much better off.
June 8th, 2008 @ 10:38 am
On the other hand, quite often the value of a virtual platform is such that models are developed from the requirement to support software development. So what comes first is the clear need to do software without hardware, and then the models that are needed to fix that get developed.
Models from the IP vendor are the ideal in many cases, not just for the configurable IP business. But sometimes the IP vendors do not feel like releasing models, or the chips in question are old hat. For example, someone using an oldish Intel chipset along with some standard x86 processor and then a pile of custom ASICs, FPGAs, and standard network controllers to build a board… there is no real “IP” being bought here, really just standard chips.
What is the model here that makes sense? Right now, it seems to be tool vendors or consultants building these models from the manuals and providing them to the needy software developers. This tends to get resolved simply because the value of doing software development on a model is so great that procuring the models is less of a problem. Just pay someone to do it. And twist some arms to get hte documentation needed.