<em>Can't find PageSubscribe to include!</em></em>

This page contains ideas and discussions about SystemC Kits and extentions that people would find useful

See also the GreenSocs Roadmap

This will also form the GreenSocs "Roadmap". It is open for all to contribute to, please make your views known! Feel free to leave comments or make changes. This is a scratchpad for ideas...

Stable Open Source implementation

SystemC has experienced growth into design environments that are not always expected, principally because there is an open source implementation that permits people to experiment. That needs to continue. It is vital that the open source implementation tracks the LRM.

(MarkBurton) I believe that OSCI will provide this.

SystemC "Compliance" suit

A suit of (independent) tests to verify if a SystemC implementation does, or does not comply to the LRM.

MultiVote(SystemC/SystemCNeeds, SystemC Compliance suit would be useful for your work, yes, no)

Basic Building Blocks

(see Basic SystemC Building Blocks)

Things like UARTS, Timers, Interrupt controllers, even routers and arbiters are fairly "common" and dont represent "differentiating" IP. It would be helpful if they were simply available to download and use.

Defining registers, map them to an address space and providing a debug interface to those registers (for breakpoints) would be valuable

However, on top of this an XML SPIRIT compatible description of the registers and their map should be used to either generate, or configure the model. - This is analogous to the same as the GreenBus SPIRIT configuration.

In addition, many IP blocks could be constructed from register files, simple state machines, and fifos. Again, it would be helpful if these "parts" could simply be downloaded and used. MultiVote(SystemC/SystemCNeeds, Basic Building Blocks would be useful for your work, yes, no)

Debug interfaces

The interfaces required by a debugger break down as follows:

1. IP block Interface
2. : This interface needs to include the abilities to
3. Collect Data information (information about the state of data items in the IP block)
4. Collect Analysis information (processed information about the state, and potentially history of an IP block)
5. Perform Data Control (Setting the state of data items in an IP block, resetting the IP block etc)
6. Perform Meta Control (Setting the modelling behaviour of a block - for instance increasing, or decreasing timing or analysis information)
7. Simulation Kernel Interface (see Standard SystemC Simulation Control Library)
8. : This interface needs to include the abilities to
9. Start or stop the simulation kernel
10. Be informed of other requests to start and stop the kernel.

MultiVote(SystemC/SystemCNeeds, Debug interfaces would be useful for your work, yes, no)

Debug Environment and "debugging"

(See SystemC Eclipse Environment)

SystemC needs a simple Eclipse plug in to improve user productiveness. Combined with this, it requires something like GDB that is "SystemC Aware". Especially of SystemC threading. Some useful features may be to easily see the scheduling queues, breakpoints on events etc.

Finally, there could be some tidying up of the SystemC library to make sure that both compile time and run time errors are better handled, and described to the (novice?) user.

MultiVote(SystemC/SystemCNeeds, Debug Environment would be useful for your work, yes, no)

Profiling of simulation

To debug SystemC models some extra tools are needed that would fit within a "debug environment". To enable "profiling" of the SystemC kernel (and the models running on it), there are some kernel annotations needed, which can then be combined with Valgrind, gprof, etc.

All of this needs to be run-able from within the debug environment

MultiVote(SystemC/SystemCNeeds, Profiling tools would be useful for your work, yes, no)

Analysis Tools

In combination with a debug environment, and a stable bus fabric (GreenBus) there are some obvious "visualisation" tools that would be useful, e.g. bus utilisation etc.

MultiVote(SystemC/SystemCNeeds, Analysis Tools would be useful for your work, yes, no)

Verification tools

The basic requirements for verification are:

1. Stimulus.
2. Checkers.
3. Predictors.
4. Assertions.

Some of these are present, to a greater or lesser degree in the SCV library. However, there is another layer on top required to make use of this (just as with the TLM library and a bus fabric on top). So, some of the things that might need to be done are:

1. Formally defined interfaces in order to guarantee inter-working and compliance.
2. Constraint solvers to assist with stimulus generation.
3. Scoreboards to allow different abstraction models to communicate with each other to assist both checkers and predictors.
4. Assertions that can not only be simulated but can also work with formal tools.
5. Basic verification building blocks from which verification libraries can be build

MultiVote(SystemC/SystemCNeeds, Verification Tools would be useful for your work, yes, no)

SystemC Micro Kernel

A micro-kernel, is an operating system kernel which provides only essential services such as tasks, threads, inter-process communication (IPC), and memory management primitives. All servers including device drivers - run in user mode and are treated by the u-kernel just like any other application. Since each server runs in its own address space, all these objects are protected from each other.

Integrating a u-kernal into SystemC would provide a very quick simulation environment for many common operating systems, and platforms, while allowing them to be easily extended with "star" IP.

MultiVote(SystemC/SystemCNeeds, Micro Kernel would be useful for your work, yes, no)

GreenBus Configuration

GreenBus will be customizable to provide heterogeneous user APIs and bus protocol implementations. These customized GreenBus implementations will be automatically generated from XML descriptions (figure 1).

Figure 1 Green Bus Architecture

All green shaded components are planned to be generated automatically from an XML (SPIRIT Schema) description. There the user specifies necessary quarks and the structure of his atoms. Thus the user and the bus specific data types will be generated also automatically. This is a static configuration. Configurable properties can be also declared dynamic. For instance time delays of the bus protocol are possible to set at the elaboration time. Supported formats include XML and Java-style properties files. Dynamic properties can be modified at runtime using a front-end connected to the GreenBus configuration manager. Each property is described as a pair of strings, indicating the propertys identifier and value. The identifier splits up into a hierarchical path to the module the property belongs to and the propertys name itself.

MultiVote(SystemC/SystemCNeeds, GreenBus Configuration would be useful for your work, yes, no)

Tcl API

The SystemC kernel needs a Tcl API. This would be base for development of any kind of tools:

1. Simulator environments.
2. Analysis tools.
3. Debugging tools.
4. Custom visualization tools.

The Tcl API should allow to:

1. Control the simulation.
2. Examine and force SystemC signals/variables.
3. Hook signals/variables to user scripts.

Why Tcl? It's already the defacto standard to control EDA tools and it gives you an easy possibility to build OS independent GUI's (with Tk).

MultiVote(SystemC/SystemCNeeds, Tcl API would be usefull, yes, no)

Traffic Generator/Analyzer

A generic traffic generation/monitor module which has the same capabilities like Adtech traffic generator/analyzer tool in the lab (spirent/smartbits/ixia) that can be customised to send protocol specific packets to the systemc Model.

A traffic generator/monitor can send TRAFFIC of particular type on its PORTS. We should be able to specify FLOWS inside the Traffic and Provide the parameters that control the generation of PACKETS- Throughput, Band width allocation, inter packet gap. packet distribution etc.Also ability to specify the SEQUENCE of PACKETS that form the FLOW. Each PACKET its internal Fields , Header and Payload fields can be associated with MODIFIER to specify the range, increment, random etc.Also ability to INJECT ERRORS.

The MONITOR has a PORT. A FILTER can be specified to filter out a specific FLOW and the can be VERIFIED for the expected state. Ability to log the PACKETS in the FLOW.

A GUI interface to contol and manage this.

The Implementation shall be using object oriented techniques, so that the PROTOCOL and PACKET specifics can be customised. But the concepts involved in specifying and generating the traffic is GENERIC.

MultiVote(SystemC/SystemCNeeds, Traffic Generator/Analyzer would be usefull, yes, no)

SystemC Simulation Cockpit

Simulations are currently accomplished by providing input test files and the simulations result in trace files and output files. Engineers would have better and easier control of the simulation is they had a visual an interactive framework for controlling the simulation in real time.

See Simulation Control and Visualisation

MultiVote(SystemC/SystemCNeeds, Simulation Visualisation Cockpit would be usefull, yes, no)

---

NewPage(PublicTemplate,New Page Here,SystemC/SystemCNeeds)