Review criteria

This page lists evaluation criteria for reviewing concepts and contributions to the GreenBus project.

Developers View

• method calls
• port2port binding
• channels (primitive or hierarchical)

Location of the bus behaviour implementation

• communication channel
• data object
• bus functional model

Interfaces

• available interfaces (bus access, configuration, "decoupling of concerns"?)
• type of interface? (virtual functions, sc_interface, standard base such as OSCI-TLM)
• usability (self-explaining function names, complexity)
• representation of different abstraction layers (function overloading, seperate functions, interface hierarchy/seperate interfaces)

Abstraction layers

• well defined and separated?
• untimed (PV), timed (PVT), BA (CCATB) and/or CC
• wrappers available? if yes, implementation?

Modularity, hierarchy

• monolithic, manageable, too ramified
• decoupling of functionality and communication (ideological, pragmatic)

Simulation performance

• dependency on abstraction layer
• emphasis placed on performance or model flexibility/beauty?

Implementation details

• data flow (end-to-end communication, fragmentation/defragmentation, number of "hops")
• control flow (mutual exclusion, one/multiple threads, event-driven, callback functions, ...)
• utilisation of SystemC constructs (ports,sc_interface,sc_event,sc_thread/sc_method); where?, for what purpose?
• highlights

Extendability and adaptability

• necessary effort to develop new bus or extend existing bus's funcionality
• how to add further abstraction layers
• how to support multiple abstraction layers at once

Source code documentation

• level of detail
• doxygen-compatible

Users view

Skill requirements

• support of different user skill levels (beginner, advanced, professional)
• API structure (simple <-> complex, intervowen <-> layered, high/mid/low level functions)

Usability

• factory for typical tasks
• meaningful warnings and error messages

Controllability

• configurable parameters, level of detail
• static (compile time) / dynamic (elaboration phase, during simulation)

Extendability

• separation of framework and user extensions (e.g. user data renders user services)

Adaptability/flexibility

• compatible to OSCI-TLM or other standards?
• wrappers available?

Error handling

• detection of misuse
• assertions

Trace / debug support

• standard (scv)?
• transaction recording
• configurable trace-levels, recorded signals, ...
• direct access of internal functions
• introspection/reflection

API documentation

• quality of documentation (examples given, tutorials, ...)

Overal usability

• communication refinement
• necessary effort to proceed to next abstraction layer
• automation possible?
• limitation of systemc command set, or -- even worse -- framework-specific commands required?
• design reuse, IP integration
• analysis tools available (visualization, ...)?
• gcc compatible (which version?), systemc-2.1 compatible