Automatic communication refinement for system level design

Abdi, S.; Shin, D.; Gajski, D.

doi:10.1109/dac.2003.1219013

Cited by 10 publications

(5 citation statements)

References 6 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Because of the formalized modeling style of SpecC, general hardware modules can be synthesized automatically. The SpecC synthesis flow consists of two sequential steps: Architecture Exploration including automatic model refinement [68], followed by communication synthesis [69]. For processor modules, system level RTOS 4 modeling and automatic task refinement are possible [70].…”

Section: Speccmentioning

confidence: 99%

Retargetable Processor System Integration into Multi-Processor System-on-Chip Platforms

Wieferink¹,

Meyr²,

Leupers³

2008

View full text Add to dashboard Cite

Section: Speccmentioning

confidence: 99%

Retargetable Processor System Integration into Multi-Processor System-on-Chip Platforms

Wieferink¹,

Meyr²,

Leupers³

2008

View full text Add to dashboard Cite

“…Large interest has been attracted by transaction level modeling with system level design languages such as SpecC [4] and SystemC [6]. Based on the orthogonalization of system functionality and system communication, these languages support virtual prototyping and mixed-mode simulation [1,5,9] as well as communication analysis [11,16,17] using several TLM abstraction levels. Faced with the task of generating a synthesizable MPSoC implementation, however, the crucial issue is communication refinement.…”

Section: Figure 1 Complex Multiprocessor Socmentioning

confidence: 99%

“…In [1] and [17], the authors tackle automatic communication refinement, and Kogel et al [11] address virtual architecture mapping using a generic bus model. Fummi et al [3] and Ramaswamy et al [14] show application-specific techniques for HW-assisted verification with SystemC.…”

Section: Figure 1 Complex Multiprocessor Socmentioning

confidence: 99%

TRAIN: A Virtual Transaction Layer Architecture for TLM-based HW/SW Codesign of Synthesizable MPSoC

Klingauf

Gädke

Giinzel

2006

Proceedings of the Design Automation &Amp; Test in Europe Conference

View full text Add to dashboard Cite

Our concept of a virtual transaction layer (VTL) architecture allows to directly map transaction-level communication channels onto a synthesizable multiprocessor SoC implementation. The VTL is above the physical MPSoC communication architecture, acting as a hardware abstraction layer for both HW and SW components. TLM channels are represented by virtual channels which efficiently route transactions between SW and HW entities through the on-chip communication network with respect to quality-of-service and realtime requirements. The goal is to methodically simplify MPSoC design by systematic HW/SW interface abstraction, thus enabling early SW verification, rapid prototyping and fast exploration of critical design issues. With TRAIN, we present our implementation of such a VTL architecture for Virtex-II Pro and PowerPC and illustrate its efficiency by experimentation. end, a flexible and scalable HW/SW communication architecture is required which from the programmer's point of view fully retains all TLM channels as virtual channels in the final system implementation. The key features that such an architecture should provide are:Flexibility: The hardware part of the architecture should be highly flexible and scalable, enabling each processor core to be connected to an arbitrary number of on-chip communication networks. Performance:The HW/SW interface should deliver highest possible data transfer rates according to the underlying communication subsystems. Adaptability:The VTL should be highly retargetable, rendering any re-engineering of MPSoC components unnecessary. For software components, TLM channel interface method calls such as put and get should be transparently mapped to the HW/SW interface. Hardware components should be accessible independently from their communication protocol.Configurability: Each TLM channel of the high-level system model should be represented by a virtual communication channel in the implementation model. Virtual

show abstract

“…Different models are used for generating each type of interface. Abdi et al [13] propose a way for integrating heterogeneous subsystems by using an abstract interface. In these approaches, the coarse granularity of the library elements may provide unnecessary functionalities, which impact system efficiency.…”

Section: Related Workmentioning

confidence: 99%

Service dependency graph

Jerraya

Rousseau

Bouchhima

et al. 2005

Proceedings of the 3rd IEEE/ACM/IFIP International Conference on Hardware/Software Codesign and System Synthesis

View full text Add to dashboard Cite

Complex systems-on-chip are designed by interconnecting predesigned hardware (HW) and software (SW) components. During the design cycle, a global model of the SoC may be composed of HW and SW models at different abstraction levels. Designing HW/SW interfaces to interconnect SoC components is a source of design bottlenecks. This paper describes a service-based model enabling systematic design and co-simulation of HW/SW interfaces for SoC design. This model, called Service dependency graph (SDG) allows modeling of complex and applicationspecific interfaces. We present also a model generator that can automatically build HW/SW interfaces based on service and resource requirements described by the SDG. This approach has been applied successfully on the design of an MPEG-4 encoder. Additionally the SDG seems to be an excellent intermediate representation for the design automation of HW/SW interfaces.

show abstract

Automatic communication refinement for system level design

Abstract: Abstract

Cited by 10 publications

References 6 publications

Retargetable Processor System Integration into Multi-Processor System-on-Chip Platforms

Retargetable Processor System Integration into Multi-Processor System-on-Chip Platforms

TRAIN: A Virtual Transaction Layer Architecture for TLM-based HW/SW Codesign of Synthesizable MPSoC

Service dependency graph

Contact Info

Product

Resources

About