D. Thomas, J. Adams, and H. Schmit, "A Model and Methodology for Hardware /Software Codesign," in IEEE Design & Test of Computers, pp. 6--15, 1993.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....of a hardware software partitioning system. The partitioning algorithm is a crucial part of the formal approach because it is the algorithm that actually minimizes the expensive hardware. However, current research into algorithms for hardware software partitioning is at an early stage. In [1], the essential criteria to consider during partitioning are described, but no particular algorithm is given. 2 Model Estimators User interface Algorithms Partitioned description Functional description function Cost Partitioning Figure 1: Basics parts of a hw sw partitioning system In ....

....Experimental results We briefly describe the environment in which we compared the various algorithms. It is important to note that most environment issues are orthogonal to the issue of algorithm design. Our algorithms should perform well in any of the environments discussed in other work such as [1, 2, 3, 4]. It should also be noted that any partitioning algorithm can be used within the BCS algorithm, not just simulated annealing. We take a VHDL behavioral description as input. The description is decomposed to the granularity of tasks, i.e. processes, procedures, and optionally to statement blocks ....

D. Thomas, J. Adams, and H. Schmit, "A Model and Methodology for Hardware /Software Codesign," in IEEE Design & Test of Computers, pp. 6--15, 1993.

....(For more information on how to se (a) Bus A C SYSTEM B CTRL B NEW PROC ASIC (b) SYSTEM A C B x MEM (x) Figure 1: An example of model refinement: a) an input specification, b) the refined specification. lect a good allocation and partition please refer to related work in [1, 2, 3]) After partitioning, the model refinement task is required to transform the original specification into a refined specification to reflect the allocation and partitioning decisions. For example, the refined specification (Figure 1(b) shows that one processor and one ASIC are used for the ....

....verification, behavioral synthesis or software compilation tasks that may follow hardware software codesign. ED TC 96 0 89791 821 96 5.00 1996 IEEE Previous work in hardware software codesign has addressed many issues. Functional partitioning among system components has been discussed in [1,2,3]. Simulation environments have been developed to encourage early functional verification [4, 5] and various techniques [6, 7] have been proposed to interface hardware and software components. Our work is closely related to hardware software interfacing. However, instead of focusing on the ....

D. Thomas, J. Adams, and H. Schmit, "A model and methodology for hardware/software codesign," in IEEE Design & Test of Computers, pp. 6--15, 1993.

....application system. Keywords Hardware software codesign, Communication synthesis, Protocol selection allocation, Interface generation I. INTRODUCTION Recently the synthesis community has moved toward the highest level of abstraction commonly known as the system level [4] 9] 15] 16] 20] [32]. This move vas motivated by the increasing complexity of systems and by the need for a unified approach to allow the development of systems containing both hardware and software. As the level of abstraction rise some problems heretofore non existing appear [12] 38] At the system level, some of ....

D.E. Thomas, J.K. Adams, and H. schmit, A Model and Methodology for Hardware/Software Codesign, IEEE Design & Test of Computers, Vol. 10 No. 4, pp. 6-15, December 1993.

....layout) using the Estelle to VHDL translator e2v described in [24] Related Work. Several projects currently in progress are trying to integrate both hardware and software into the same design process: COSMOS from TIMA INPG [8] SpecSyn from Irvine [6] CODES from Siemens [1] Thomas from CMU [21], Gupta and DeMicheli from Stanford [7] and Ptolemy from Berkeley [3] COSMOS is a hardware software co design environment based on the SOLAR intermediate format for system level modeling and synthesis. SOLAR supports the system and behavioral levels of specification. COSMOS includes system level ....

D. E. Thomas, J. K. Adams, and H. Schmitt. A Model and Methodology for Hardware /Software Codesign. IEEE Design and Test of Computers, pages 6--15, Sept. 1993.

....A new generation of methods and tools for system design is emerging; they are able to handle the design of mixed hardware software systems starting from system level specification. These are called co design or embedded system design tools; they provide a drastic increase in the productivity [2, 5, 7, 8, 9, 12, 17, 19, 21, 22]. This gain in productivity may be used to explore several architectural solutions to improve the quality and to reduce the cost of the final design. This paper discusses the co design of an ATM network interface card (NIC) using a co design tool called Cosmos. This experiment allowed design ....

D.E. Thomas, et al., A Model and Methodology for Hardware/Software Codesign, IEEE Design & Test of Computers, Vol. 10 No. 4, pp. 6-15, December 1993.

....parameters needed by a hardware size estimator. As we shall see, we were able to do this by assuming that the granularity at which we partition the specification is at the procedural level (sometimes called the process or task level) as is the case in many new functional partitioning techniques [7, 8, 10, 11, 12, 13, 14, 15]. Our contribution is the development of this incremental hardware size estimation method, consisting of a new data structure and algorithm, that achieves the advantages of both classes of previous approaches, namely accuracy and speed. This paper is organized as follows. In Section 2, we describe ....

D. Thomas, J. Adams, and H. Schmit, "A model and methodology for hardware /software codesign," in IEEE Design & Test of Computers, pp. 6--15, 1993.

....grained than an arithmetic operation. Instead, it corresponds to a block of statements in the specification such as a loop body, procedure, or process. The abstraction level of a behavior is sometimes called the algorithmic level in other work. A behavior is similar to a task described in [1]. Variables Behaviors Channels Allocation Partitioning Refinement System design tasks Memories Buses Variables to memories Channels to buses Address assignment Arbitration protocols Interfacing Processors Behaviors to processors. Functional objects Figure 1: System design tasks For each of these ....

....to implement a set of performance constrained processes, and to partition the processes among those processors. Some other related works include that in [23] which provides techniques for rapid size and time estimation for a partition of arithmetic operations among ASICs. Research pre23 sented in [1] and [24] overviews the hardware software partitioning problem, including discussions on granularity, estimation, and simulation of interacting hardware and software components. A survey of a variety of research efforts in the field of hardware software codesign appears in [25] The most important ....

D. Thomas, J. Adams, and H. Schmit, "A model and methodology for hardware/software codesign," in IEEE Design & Test of Computers, pp. 6--15, 1993.

....which in turn are those buses that implement at least one channel crossing the boundary. 4 Related work Many projects focus on partitioning functionality among hardware or hardware software components. The need for coarse grained procedural level partitioning was stressed in [2] as well as in [3, 4]. Approaches in [5, 6, 7] partition at the finer grained statement level (or statement sequence) Other approaches, such as those in [8, 9, 10, 11, 12, 13] partition at the fine grained arithmetic operation level. Additional research has focused on functional transformation, at a procedural ....

D. Thomas, J. Adams, and H. Schmit, "A model and methodology for hardware/software codesign," in IEEE Design & Test, pp. 6--15, 1993.

....functions for implementation among some set of components. The first problem has received much recent research attention, with the focus being on functionally partitioning a specification among software processors and custom hardware processors to achieve good cost and performance tradeoffs [1, 2, 3, 4, 5, 6, 7]. The functional partitioning solutions to the latter two problems have received less attention, but as we shall demonstrate, are very important in synthesis environments. The problem of satisfying hardware part size and I O (input output) constraints, including ApplicationSpecific Integrated ....

....We first decomposed the specification into a set of functional objects to be assigned to system components. The objects granularity was that of procedures and variables. Arguments for this granularity, as opposed to finer granularities like statements or arithmetic operations, can be found in [2, 5, 41, 42]. Techniques in [42] can be used to group a procedure s statements into sub procedures when a procedure is too large. We then partitioned the functional objects among two groups, using both automated and manual techniques. We applied the prototype automated partitioner in SpecSyn [34] SpecSyn ....

D. Thomas, J. Adams, and H. Schmit, "A model and methodology for hardware/software codesign," in IEEE Design & Test of Computers, pp. 6--15, 1993.

....synthesis, but may be too fine grained for the system level. Decomposing to the statement level or basic block level, as done in [2, 3, 4] may yield thousands of functional objects for a VHDL specification possessing several thousand lines. Decomposing to the process procedure level, as done in [5, 6, 7, 8, 9] yields tens or a few hundred functional objects, which is approximately the level at which designers can interact, and at which inter object communication times don t dominate over object computation times. However, we have found that designers often write processes or procedures with a large ....

D. Thomas, J. Adams, and H. Schmit, "A model and methodology for hardware/software codesign," in IEEE Design & Test of Computers, pp. 6--15, 1993.

....a behavior or variable of component p with another behavior, variable or port not in component p. 4 Related work There are several research efforts that focus on performing system design tasks. Several efforts have focused on partitioning functionality among a hardware software architecture [3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13] for partitioning functionality among hardware modules [14, 15, 16, 17, 18, 19, 20, 21, 22, 23] for partitioning functionality among multiple processors [24] and for transformation during system design [25, 26] Many of these efforts use an intermediate format intended to expose control and data ....

D. Thomas, J. Adams, and H. Schmit, "A model and methodology for hardware/software codesign," in IEEE Design & Test of Computers, pp. 6--15, 1993.

....risks. A new generation of methods and tools for system design is emerging; they are able to handle the design of mixed hardware software systems starting from systemlevel specification. These are called co design or embedded system design tools; they provide a drastic increase in the productivity [Fel97, Mic95, Gaj95, Wol94, Tho93, Hen94, Wil94, Chi96, Rom96, Gup94]. This gain in productivity may be used to explore several architectural solutions to improve the quality and to reduce the cost of the final design. This paper discusses the co design of an ATM network interface card (NIC) using a co design tool called Cosmos. This experiment allowed design ....

D.E. Thomas, J.K. Adams, H. schmit, A Model and Methodology for Hardware/Software Codesign, IEEE Design & Test of Computers, Vol. 10 No. 4, pp. 6-15, December 1993.

....A new generation of methods and tools for system design is emerging; they are able to handle the design of mixed hardware software systems starting from system level specification. These are called co design or embedded system design tools; they provide a drastic increase in the productivity [2, 5, 7, 8, 9, 12, 17, 19, 21, 22]. This gain in productivity may be used to explore several architectural solutions to improve the quality and to reduce the cost of the final design. This paper discusses the co design of an ATM network interface card (NIC) using a co design tool called Cosmos. This experiment allowed design ....

D.E. Thomas, et al., A Model and Methodology for Hardware/Software Codesign, IEEE Design & Test of Computers, Vol. 10 No. 4, pp. 6-15, December 1993.

....in [2] and statements in [3] To our knowledge, our metrics are the first to address objects at the procedural level. Such coarse granularity supports manageable complexity and designer interaction. The case for procedural level granularity during system partitioning has been presented in [4, 5, 6, 7], although those efforts did not address the issue of closeness metrics. Other functional partitioning efforts include operation level approaches in [8, 9, 10, 11] statement sequence level approaches in [12, 13] and state level approaches in [14, 15] Our closeness metrics can be used in ....

D. Thomas, J. Adams, and H. Schmit, "A model and methodology for hardware/software codesign," in IEEE Design & Test of Computers, pp. 6--15, 1993.

....such as microprocessors, microcontrollers, and custom ASIC FPGA processors. Ideally, application developers would be able to develop software and hardware code using abstract send receive primitives for communication, based on a communicating sequential processes (CSP [1] paradigm as proposed in [2], for example. A primitive s underlying implementations, such as the choice of a particular bus type and protocols, the assignment of communications to ports, and the setting and reading of interface registers and port signals, would be hidden or created later. However, there is presently a gap ....

....read and write the device s ports. Symphony [6] defines a standard communication protocol for all processor components, using send and receive operations with a synchronous wait protocol, where the sender asserts a ready signal and then waits for the receiver to assert its own ready signal. In [2], a codesign methodology is discussed using process communication primitives that allow three types of process interaction: synchronized data transfer, unsynchronized data transfer and synchronization without data transfer. In [7] a system design methodology is discussed using abstract ....

D. Thomas, J. Adams, and H. Schmit, "A model and methodology for hardware/software codesign," in IEEE Design & Test of Computers, pp. 6--15, 1993.

....read and write the device s ports. Symphony [2] defines a standard communication protocol for all processor components, using send and receive operations with a synchronous wait protocol, where the sender asserts a ready signal and then waits for the receiver to assert its own ready signal. In [3], a codesign methodology is discussed using process communication primitives that allow three types of process interaction: synchronized data transfer, unsynchronized data transfer and synchronization without data transfer. In [4] a system design methodology is discussed using abstract ....

D. Thomas, J. Adams, and H. Schmit, "A model and methodology for hardware/software codesign," in IEEE Design & Test of Computers, pp. 6--15, 1993.

....(b) System parts Functional objects Fig. 1: Procedure exlining during system partitioning: a) Initial specification, b) after exlining procedures, c) after decomposition based on procedures, d) after functional partitioning. computation, thus defining the granularity of functional partitioning [1, 2, 3, 4, 5]. Second, a procedure can be converted to a process to represent a separate controller, in order to simpify the synthesized control logic [6, 7] or to achieve more concurrent execution [8] Third, procedures can be input separately to synthesis tools, in order to reduce the memory and runtime ....

D. Thomas, J. Adams, and H. Schmit, "A model and methodology for hardware/software codesign," in IEEE Design & Test of Computers, pp. 6--15, 1993.

....Mb, 10 Mb, and 20 Mb. The field of codesign itself is not really recent, but joint specification, design and synthesis of mixed hardware software systems is a recent issue. Several projects currently are underway (SpecSyn at Irvine[6] CODES at Siemens[3] SDW at Italtel[1] Thomas approach at CMU[18], Gupta and De Micheli approach at Standford[8] Ptolemy at Berkeley[13] RASSP[16] etc. are trying to integrate both hardware and software in the same process. The proposed methodologies differ mainly on three key points : the input specification style, the target architecture model, and the ....

D.E.Thomas, J.K.Adams, H.Shmitt, "A Model and Methodology for Hardware/Software Codesign", IEEE Design and Test of Computers, pp.6-15, September 1993. 17

....exploring hardware software tradeoffs, satisfying hardware packaging constraints, and reducing synthesis runtimes. Recent research has focused on the first problem of exploring tradeoffs of cost and performance through functional partitioning among software and customhardware processor components [1, 2, 3, 4, 5, 6, 7]. The latter problems are also important, but their functional partitioning solutions have received far less attention. The problem of satisfying hardware packaging constraints, such as size and I O (input output pin) constraints on ASIC or Field Programmable Gate Array chips (FPGA s) has ....

....lines. 2.2 Functional partitioning We first decomposed the specification into a set of functional objects to be assigned to system components. The object granularity was procedures and variables. Arguments for this granularity, as opposed to finer granularities like statements, can be found in [2, 5, 18, 19]. Techniques in [19] can be used to group a procedure s statements into sub procedures when the user written procedures would be too coarse grained. We then partitioned the functional objects among two groups, using both automated and manual techniques. We applied the prototype automated ....

D. Thomas, J. Adams, and H. Schmit, "A model and methodology for hardware/software codesign," in IEEE Design & Test of Computers, pp. 6--15, 1993.

....which in turn require new closeness metrics. Such granularity enables shorter runtimes and designer comprehension, and ensures that inter part communication times don t dominate over computation times. The case for procedural level granularity during system partitioning has been presented in [15, 16, 17, 18]. We should point out that the procedures being partitioned need not be the same procedures from the original specification; some can be eliminated through inlining, and others can be introduced through exlining [19] The paper is organized as follows. In Section 2, we briefly describe the ....

D. Thomas, J. Adams, and H. Schmit, "A model and methodology for hardware/software codesign," in IEEE Design & Test of Computers, pp. 6--15, 1993.

....[1, 4, 5, 6, 7, 8] as well as hardware hardware partitioning [9, 10, 11, 12] The former techniques focus on maximizing performance while minimizing hardware size, and the latter on satisfying packaging constraints while minimizing communication time. Other techniques assume a manual partitioning [13, 14, 15, 16, 17], but could certainly be extended to use heuristics. The work presented here is intended to greatly improve the ability to make fair comparisons of various heuristics. In particular, we need a well defined model on which to apply partitioning heuristics. A model represents the specification ....

D. Thomas, J. Adams, and H. Schmit, "A model and methodology for hardware/software codesign," in IEEE Design & Test of Computers, pp. 6--15, 1993.

....feedback of performance, size and cost metrics for a given distribution of functions on any allocation of processors, ASICs, memories and buses. Tools described in [26, 27] assist in mapping a specification onto a fixed allocation of one processor, one ASIC, one memory and one bus, while tools in [28, 29] assist in mapping onto a single processor with multiple ASICs. 3.2 Partitioning Given a functional specification and an allocation of system components, we need to partition the specification and assign each part to one of the allocated components. In fact, we can distinguish three types of ....

....processes and subroutines are partitioned among ASICs using clustering and iterative improvement algorithms. Hardware software partitioning techniques form the second functional partitioning category. These techniques focus on partitioning functionality among a hardware software architecture. In [29] and [42] overviews of the hardware software partitioning problem are provided, including discussion on the issues of granularity and estimation. The technique in [43] partitions at the statement level of granularity using clustering algorithms, while the approaches in [26] 27] and [34] ....

[Article contains additional citation context not shown here]

D. Thomas, J. Adams, and H. Schmit, "A model and methodology for hardware /software codesign," in IEEE Design & Test of Computers, pp. 6--15, 1993.

....semantic models and be described using different languages. The purpose of co simulation may be to flesh out the functionality of hardware and software early in the design process or to integrate the two late in the design process. It may be aimed at verifying the functionality of the system [2] [3] or at evaluating the performance [4] 5] Hardware software co simulation requires a simulation environment that can understand the semantics of both the software and the hardware components and how actions in one domain affect the state of the other. The interaction of the hardware and ....

....approach is most accurate for evaluating performance, but is computationally expensive. If the hardware and software elements of the system communicate asynchronously, the interaction could be modeled at a high level by the process or device communication mechanism provided by an operating system [2] [3] This approach is much very efficient computationally, but may not be useful for evaluating performance. 3.2 Hardware software co synthesis Co design may also include integrated synthesis of hardware and software components, which we refer to as hardware software cosynthesis [6] 7] 8] ....

D. E. Thomas, J. K. Adams, and H. Schmit, "A Model and Methodology for Hardware/Software Codesign," IEEE Design & Test of Computers, vol. 10, no. 3, pp. 6--15, 1993.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC