This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process document) and is written to declare its intent and scope. This proposal is written to solicit additional participation and input from the Eclipse community. You are invited to comment on and/or join the project. Please send all feedback to the http://www.eclipse.org/newsportal/thread.php?group=eclipse.dsdp.vpp newsgroup.
Functional accuracy can range markedly, from very little (pure traffic generators), through partially accurate models (which may not model some specific features of a hardware implementation, which may or may not be visible to a programmer), to models that are totally functionally accurate. Further more, models may be specifically designed to "stress" software components, often for the purpose of assisting in debug, and ensuring software correctness. This level of activity is often referred to as the "Electronic System Level" or ESL. ESL Design activity often occurs prior to or at the point of making a split between hardware and software, which is often recognized as a highly influential point in the design process. The wide range of uses that ESL models are put to means that there are many "views" of them that are appropriate.
These models may be of components destined to for implementation in hardware or in software. The models constructed (and debugged) in this way then provide a starting point for the development of hardware dependent software and the hardware itself. While the processor-centric view of a system is addressed by other projects within Eclipse, and other projects focus on connections with hardware, this project focuses on how to construct, connect, debug, analyze, visualize and use models (of virtual prototype components destined for implementation in hardware, or software) to Eclipse. The language used for the ESL Design activity is predominantly (though not exclusively) SystemC. SystemC is a language implemented as a C++ library, so it shares many of the debug requirements of C++ itself. However, there are additional views of a SystemC model that are useful to the designer (for instance, SystemC keyword highlighting, model connectivity diagrams etc). It is expected that the VPP will cover other languages over time that are relevant to ESL (e.g. System Verilog). Once SystemC models are debugged, and executable, they can be run either using a freely available SystemC library implementation (provided by the Open SystemC Initiative), or one of the many proprietary simulators. In either case, a model may wish to interact with the user, for a number of reasons:
In each case, mechanisms will be required in Eclipse to support this user interaction.
Overall, a typical use case would be for an Electronic System Engineer to initially import a number of pre-existing models into their environment. They may use some VPP topology visualization plugins to help understand the connectivity of the model they are trying to build. They may then go on to build a few "component models" themselves, using many already existing Eclipse plugins, and some VPP additions. Having debugged the model, again with a combination of plugins, they would then go on to execute the model, controlling its execution through other VPP plugins. Finally, they will need to extract data from the model (the reason for constructing the model in the first place!). This data will be provided to the user through VPP plugins.
Leverage Eclipse Ecosystem - A major goal of this project is to apply the application development strengths of Eclipse to the System Level Design Domain (especially as, in the end, a System Level model is nothing more than a relatively constrained, but none the less complex, application). The project will work closely with other Eclipse project areas whenever possible to leverage the capabilities being developed in those areas.
Vendor Neutral - We aim to encourage Eclipse participation and drive Eclipse market acceptance by providing vendor-neutral capabilities and to encourage participation for complementary capabilities through additional projects.
Open, Standards-based Development - Where market adopted standards exist that meet the design goals, our aim is to leverage and adhere to them. Where market adopted standards do not exist, we will develop and publish any new capabilities in the Eclipse open forum.
Incremental Delivery - In order to meet the pent-up demand for a standardized framework for device software development tools, we aim to deliver functionality to the market as rapidly as possible via an incremental delivery model.
System Level Design includes all of these, but with respect to models. In addition, the Bring-up phase will apply to models of functional components that may be destined for implementation in a combination of hardware and software and there is one more phase: Hardware/Software partitioning, or model abstraction level decisions In this phase, designers decide at what level they need to (or can) model items in their system. At high levels of abstraction it may not be clear if this item will be implemented in hardware or in software. At lower levels details about the implementation become important. The VPP will use or adapt other projects within DSDP to address the other three design phases as they relate to system level design and will add specific exemplary tools aimed at assisting in the hardware/software partitioning task.
Having designed a model, and chosen a level of abstraction suitable for the use cases to which the model is to be applied, the wider range of Eclipse tools and plug-ins will be required including:
For each of these, work in disparate organizations is already taking place, GreenSocs (see below) aims to pull this work together in one central place and to feed that into VPP.
Back to the top