Explore chapters and articles related to this topic
System-Level Design
Published in Wai-Kai Chen, Computer Aided Design and Design Automation, 2018
Alice C. Parker, Yosef Tirat-Gefen, Suhrid A. Wadekar
There are no widely adopted formal languages for system-level hardware design although System-Level Design Language (SLDL) was developed by an industry group. Hardware descriptive languages such as VHSIC Verilog Hardware Descriptive Language (VHDL) [1] and Verilog [2] are used to describe the functionality of modules in an application-specific system. High-level synthesis tools can then synthesize such descriptions to produce register-transfer designs. Extensions of VHDL and Verilog have been proposed to encompass more system-level design properties. Apart from system constraints, VHDL specifications can form complete system descriptions. However, the level of detail required in VHDL and to some extent in Verilog requires the designer to make some implementation decisions. In addition, some information that is explicit in more abstract specifications such as the flow of control between tasks is implicit in HDLs.
Parallelizing High-Level Synthesis: A Code Transformational Approach to High-Level Synthesis
Published in Louis Scheffer, Luciano Lavagno, Grant Martin, EDA for IC System Design, Verification, and Testing, 2018
Gaurav Singh, Sumit Gupta, Sandeep Shukla, Rajesh Gupta
All these factors continue to limit the acceptance of HLS tools among designers. As mentioned earlier, manual implementations are often superior to HLS solutions because of the range of design optimizations that a system designer has at his/her disposal. While HLS tools have been catching up, just as they have already done so at lower levels of abstraction, a significant gap remains. Parallelizing high-level synthesis has been shown to address these factors and has demonstrated through experimental results that it can produce designs that are competitive with manual designs. This can make HLS part of the microelectronic design flow, thus, bringing about the much needed productivity gain required to design increasingly complex circuits.
NoC and System-Level Design
Published in Hoi-Jun Yoo, Kangmin Lee, Jun Kyoung Kim, Low-Power NoC for High-Performance SoC Design, 2018
Hoi-Jun Yoo, Kangmin Lee, Jun Kyoung Kim
After the functional specification of a system is determined, the architecture exploration stage follows. It searches for the most appropriate way to specify the number and types of components as well as the connections between them. An example is shown in Figure 1.7 where the behavior of a setup box system is mapped to a shared bus-type hardware architecture. In the functional specification, there is no clear separation yet between software and hardware, just mapping or partitioning the functional blocks of the function model onto the architecture model by assigning every function to a specific hardware or software resource. The assigned hardware may be a dedicated hardware block or one mode of a dedicated hardware block, and the assigned software, a task running on a general or specialized processor. In addition, depending on the availability of IPs, some of the hardware parts will be newly designed and some will just use the existing IPs. Based on the performance analysis of the assembled system, it can be decided which part of the target system will be implemented by hardware and which part by software. For the software part, the compiler techniques will be used according to requirements. On the contrary, for the hardware part, because only the functional behavior has been determined, its architectures should be derived from the functions. The function set to describe the behaviors is analyzed and its common parts are selected to describe in the transaction level. That is, the hardware is divided into multiple modules of appropriate size for processing, whereas the behaviors of the individual modules are described by a high-level modeling language. Then, the resulting behavior of the target system is applied to the collective operation and communication among multiple modules. The detailed communication mechanism among multiple modules should be modeled and analyzed independently as if they were separate hardware modules. This will be explained further in Subsection 1.3.2. The hardware modules are converted into register transfer level (RTL) description by high-level synthesis tools. Although the appropriate architecture model can be found by trial-and-error-based mapping in many practical cases, there have been many studies on how to get the optimal mapping automatically under the given system, hardware, and software constraints. Most of the architectures are made of the integration platform composed of communication networks, RISC, DSP, and parallel processors such as VLIW, SIMD, and MIMD.
A hardware intelligent processing accelerator for domestic service robots
Published in Advanced Robotics, 2020
Yutaro Ishida, Takashi Morie, Hakaru Tamukoh
As depicted in Figure 3, we propose a COMTA [30,31], which is a hardware-accelerated intelligent processing system for domestic service robots. We now organize the problems to be solved in the proposed system. Using hardware description language (HDL) or high-level synthesis, circuit engineers design intelligent processing circuits inside FPGAs (Figure 3(1)). As shown in the right side of Figure 3 regarding the case of a hw/sw complex system, the engineers have to implement an interface that connects the circuit and an FPGA controller on an embedded CPU (Figure 3(2)). In this case, the system provides the interface to reduce the man-hour. In the same way, circuits engineers have to implement interfaces which connect the FPGA controller and ROS space/other processes (Figure 3(3)). The system should provide the interfaces which are familiar to the circuit engineers in this case. Furthermore, when robotic engineers utilize the hw/sw complex system, it is desirable that the system should be easy to maintain as a ROS package.