SpecSyn: an environment supporting the specify-explore-refine paradigm for hardware/software system design

Abstract

Abstract-System-level design issues are gaining increasing attention, as behavioral synthesis tools and methodologies mature. We present the SpecSyn system-level design environment, which supports the new specify-explore-refine (SER) design paradigm. This three-step approach to design includes precise specification of system functionality, rapid exploration of numerous systemlevel design options, and refinement of the specification into one reflecting the chosen option. A system-level design option consists of an allocation of system components, such as standard and custom processors, memories, and buses, and a partitioning of functionality among those components. After refinement, the functionality assigned to each component can then be synthesized to hardware or compiled to software. We describe the issues and approaches for each part of the SpecSyn environment. The new paradigm and environment are expected to lead to a more than ten times reduction in design time, and our experiments support this expectation.

Generating FPGA-Accelerated DFT Libraries

“…The rewriting system contains three rule sets: 1) breakdown rules (1) and (4), 2) partitioning rules (8)- (12), and 3) the cleanup rule (6).…”

“…In these works, the most difficult challenge is in choosing the appropriate granularity of representation in the computation graph; for example, a node can represent an instruction, a loop, a function call, or a module. This issue is addressed by system level design languages such as SpecSyn [5,6]. The development frameworks for these languages deploy search techniques and implementation strategies based on the ability to represent and manipulate specific solution features at various levels of abstraction and where the user is always welcome to interact during the design process.…”

Design flow for optimizing performance in processor systems with on-chip coarse-grain reconfigurable logic

“…The speedup of each application will come from accelerating few kernels. The small number of the detected kernels in each application means that the usage of exploration algorithms, which typically examine thousands of possible partitions and utilize complex algorithms [9], [10] is not necessary in the case of partitioning the considered applications on the processor-CGRA systems. The results from mapping the critical loops of the applications on the 4x4 CGRA are given in Table 2.…”

“…Such a design choice stems from the observation that most embedded DSP and multimedia applications spend the majority of their execution time in few small code segments (typically loops), the kernels. This means that an extensive solution space search, as in past hardware/software partitioning works [9], [10] is not a requisite.…”

Automated Software Generation and Hardware Coprocessor Synthesis for Data-Adaptable Reconfigurable Systems

“…A profile either defines specific settings for various configurable parameters within the standard or defines a subset of allowed options, thereby reducing the level of complexity needed to implement a specific profile. As such, hardware accelerated solutions-often achieved through hardware/software codesign [1][4] [9][13]-can potentially provide the required performance for these applications but are severely limited in the application space that can be supported. Traditional hardware accelerated solutions supporting all profiles even within a single domain is often infeasible, as hardware coprocessors must be generated for all profiles utilized within that domain.…”