Codesign For System Acceleration A Quantitative Approach 1st Edition Nadia Nedjah

Codesign For System Acceleration A Quantitative
Approach 1st Edition Nadia Nedjah download
https://ebookbell.com/product/codesign-for-system-acceleration-a-
quantitative-approach-1st-edition-nadia-nedjah-1713618
Explore and download more ebooks at ebookbell.com

Here are some recommended products that we believe you will be
interested in. You can click the link to download.
Codesign Approaches For Dependable Networked Control Systems Daniel
Simon
https://ebookbell.com/product/codesign-approaches-for-dependable-
networked-control-systems-daniel-simon-4301742
Collaborative Design For Embedded Systems Comodelling And Cosimulation
1st Edition John Fitzgerald
https://ebookbell.com/product/collaborative-design-for-embedded-
systems-comodelling-and-cosimulation-1st-edition-john-
fitzgerald-4697568
Packetbased Control For Networked Control Systems A Codesign Approach
Kang
https://ebookbell.com/product/packetbased-control-for-networked-
control-systems-a-codesign-approach-kang-6754536
Codesign Volume Iii Practical Ideas For Developing Across Complex
Systems Stefan Cantore Author
https://ebookbell.com/product/codesign-volume-iii-practical-ideas-for-
developing-across-complex-systems-stefan-cantore-author-33356680

Codesign Volume Ii Practical Ideas For Designing Across Complex
Systems Mark Gatenby Author
https://ebookbell.com/product/codesign-volume-ii-practical-ideas-for-
designing-across-complex-systems-mark-gatenby-author-33356684
Codesign Volume I Practical Ideas For Learning Across Complex Systems
Mark Gatenby Author Stefan Cantore Author
https://ebookbell.com/product/codesign-volume-i-practical-ideas-for-
learning-across-complex-systems-mark-gatenby-author-stefan-cantore-
author-33356686
Designing For Digital Transformation Cocreating Services With Citizens
And Industry 15th International Conference On Design Science Research
In Information Systems And Technology Desrist 2020 Kristiansand Norway
December 24 2020 Proceedings 1st Ed Sara Hofmann
https://ebookbell.com/product/designing-for-digital-transformation-
cocreating-services-with-citizens-and-industry-15th-international-
conference-on-design-science-research-in-information-systems-and-
technology-desrist-2020-kristiansand-norway-
december-24-2020-proceedings-1st-ed-sara-hofmann-22498040
Investigation On Robust Codesign Methods For Networked Control Systems
1st Edition Sanad Alareqi
https://ebookbell.com/product/investigation-on-robust-codesign-
methods-for-networked-control-systems-1st-edition-sanad-
alareqi-51627238
Codesign For A New East Asia After The Crisis 1st Edition Hitoshi
Hirakawa Auth
https://ebookbell.com/product/codesign-for-a-new-east-asia-after-the-
crisis-1st-edition-hitoshi-hirakawa-auth-4475450

Co-design for System Acceleration
A Quantitative Approach

CO-DESIGN FOR SYSTEM
ACCELERATION
A Quantitative Approach
NADIA NEDJAH
Department of Electronics Engineering and Telecommunications,
State University of Rio de Janeiro, Brazil
LUIZA DE MACEDO MOURELLE
Department of Systems Engineering and Computation,
State University of Rio de Janeiro, Brazil

A C.I.P. Catalogue record for this book is available from the Library of Congress.
ISBN-13 978-1-4020-5545-4 (HB)
ISBN-13 978-1-4020-5546-1 (e-book)
Published by Springer,
P.O. Box 17, 3300 AA Dordrecht, The Netherlands.
www.springer.com
Printed on acid-free paper
All Rights Reserved
c
2007 Springer
No part of this work may be reproduced, stored in a retrieval system, or transmitted in any form or by
any means, electronic, mechanical, photocopying, microfilming, recording or otherwise, without written
permission from the Publisher, with the exception of any material supplied specifically for the purpose of
being entered and executed on a computer system, for exclusive use by the purchaser of the work.

To my mother and sisters,
Nadia
To my father (in memory)
and mother, Luiza

Contents
Dedication v
List of Figures xi
List of Tables xv
Preface xvii
Acknowledgments xix
1. INTRODUCTION 1
1.1 Synthesis 2
1.2 Design Approaches 3
1.3 Co-Design 4
1.3.1 Methodology 5
1.3.2 Simulation 6
1.3.3 Architecture 6
1.3.4 Communication 6
1.4 Structure and Objective 7
2. THE CO-DESIGN METHODOLOGY 9
2.1 The Co-Design Approach 10
2.2 System Specification 11
2.3 Hardware/Software Partitioning 12
2.4 Hardware Synthesis 15
2.4.1 High-Level Synthesis 16
2.4.2 Implementation Technologies 17
2.4.3 Synthesis Systems 20
2.5 Software Compilation 21
2.6 Interface Synthesis 22
vii

viii Contents
2.7 System Integration 23
2.8 Summary 27
3. THE CO-DESIGN SYSTEM 29
3.1 Development Route 30
3.1.1 Hardware/Software Profiling 31
3.1.2 Hardware/Software Partitioning 33
3.1.3 Hardware Synthesis 33
3.1.4 Software Compilation 36
3.1.5 Run-Time System 36
3.2 Target Architecture 37
3.2.1 Microcontroller 38
3.2.2 Global Memory 40
3.2.3 Controllers 41
3.2.4 Bus Interface 42
3.2.5 The Coprocessor 45
3.2.6 The Timer 45
3.3 Performance Results 45
3.3.1 First Benchmark: PLUM Program 46
3.3.2 Second Benchmark: EGCHECK Program 47
3.3.3 Results Analysis 48
3.4 Summary 50
4. VHDL MODEL OF THE CO-DESIGN SYSTEM 53
4.1 Modelling with VHDL 54
4.1.1 Design Units and Libraries 55
4.1.2 Entities and Architectures 55
4.1.3 Hierarchy 57
4.2 The Main System 58
4.3 The Microcontroller 60
4.3.1 Clock and Reset Generator 61
4.3.2 Sequencer 61
4.3.3 Bus Arbiter 65
4.3.4 Memory Read and Write 68
4.4 The Dynamic Memory: DRAM 72
4.5 The Coprocessor 74
4.5.1 Clock Generator 75
4.5.2 Coprocessor Data Buffers 76
4.6 Summary 77

Contents ix
5. SHARED MEMORY CONFIGURATION 81
5.1 Case Study 82
5.2 Timing Characteristics 85
5.2.1 Parameter Passing 87
5.2.2 Bus Arbitration 87
5.2.3 Busy-Wait Mechanism 88
5.2.4 Interrupt Mechanism 90
5.3 Relating Memory Accesses and Interface Mechanisms 92
5.3.1 Varying Internal Operations and
Memory Accesses 94
5.3.2 Varying the Coprocessor Memory Access Rate 96
5.3.3 Varying the Number of Coprocessor
Memory Accesses 98
5.4 Summary 105
6. DUAL-PORT MEMORY CONFIGURATION 107
6.1 General Description 108
6.1.1 Contention Arbitration 108
6.1.2 Read/Write Operations 110
6.2 The System Architecture 111
6.2.1 Dual-Port Memory Model 111
6.2.3 Bus Interface Controller 113
6.2.4 Coprocessor Memory Controller 114
6.2.5 The Main Controller 117
6.3.1 Interface Mechanisms 120
6.4.1 Varying Internal Operations and
Memory Accesses 121
6.4.2 Varying the Memory Access Rate 126
6.4.3 Varying the Number of Memory Accesses 127
6.4.4 Speedup Achieved 129
6.5 Summary 130
7. CACHE MEMORY CONFIGURATION 133
7.1 Memory Hierarchy Design 134
7.1.1 General Principles 134
7.1.2 Cache Memory 135

x Contents
7.2 System Organization 138
7.2.1 Cache Memory Model 138
7.2.3 Coprocessor Memory Controller 140
7.2.4 The Bus Interface Controller 145
7.3.1 Block Transfer During Handshake Completion 155
7.4.1 Varying the Number of Addressed Locations 159
7.4.2 Varying the Block Size 162
7.4.3 Varying the Number of Memory Accesses 164
7.4.4 Speedup Achieved 166
7.4.5 Miss Rate with Random Address Locations 167
7.5 Summary 169
8. ADVANCED TOPICS AND FURTHER RESEARCH 173
8.1 Conclusions and Achievements 173
8.2 Advanced Topics and Further Research 176
8.2.1 Complete VHDL Model 176
8.2.2 Cost Evaluation 177
8.2.3 New Configurations 177
8.2.4 Interface Synthesis 177
8.2.5 Architecture Synthesis 177
8.2.6 Framework for co-design 177
8.2.7 General Formalization 178
Appendices 185
A Benchmark Programs 185
B Top-Level VHDL Model of the Co-design System 191
C Translating PALASMTM into VHDL 199
D VHDL Version of the Case Study 205
References 219
Index 225

List of Figures
2.1 The co-design flow 11
2.2 Typical CLB connections to adjacent lines 19
2.3 Intel FLEXlogic iFX780 configuration 21
2.4 Target architecture with parameter memory
in the coprocessor 24
2.5 Target architecture with memory-mapped
parameter registers 25
2.6 Target architecture using a general-purpose
processor and ASICs 26
3.1 Development route 31
3.2 Hardware synthesis process 34
3.3 Run-time system 37
3.4 Run-time system and interfaces 38
3.5 Target architecture 39
3.6 Bus interface control register 43
4.1 Main system configuration 59
4.2 Coprocessor board components 60
4.3 Logic symbol for the microcontroller 60
4.4 VHDL model for the clock and reset generator 62
4.5 Writing into the coprocessor control register 63
4.6 The busy-wait model 64
4.7 The interrupt routine model 65
4.8 Completing the handshake, by negating Ncopro st 66
4.9 Algorithmic state machine for the bus arbiter 67
4.10 Algorithmic state machine for memory read/write 70
xi

xii List of Figures
4.11 Logic symbol for the DRAM 16 72
4.12 Algorithmic state machine for the DRAM 73
4.13 Logic symbol of the coprocessor 74
4.14 Logic symbol of the coprocessor clock generator 75
4.15 Flowchart for the coprocessor clock generator 75
4.16 Logic symbol of the coprocessor data buffers 76
4.17 Flowchart for the coprocessor input buffer control 77
4.18 Flowchart for the coprocessor output buffer control 78
5.1 C program of example 83
5.2 Modified C program 84
5.3 Passing parameter table to the coprocessor 86
5.4 Sampling of the bus request input signal (Nbr) 88
5.5 Bus arbitration without contention 89
5.6 Bus arbitration when using busy-wait 90
5.7 Handshake completion when using busy-wait 91
5.8 End of coprocessor operation with interrupt 92
5.9 Handshake completion when using interrupt 93
5.10 Graphical representation for Tbw and Tint, in terms of
iterations 97
5.11 Graphical representation for Tb and Ti,
in terms of accesses 99
5.12 Relation between Nmemfin and mem fin,
for busy-wait 103
6.1 Logic symbol of the dual-port memory 108
6.2 Arbitration logic 110
6.3 Main system architecture 111
6.4 Coprocessor board for the dual-port configuration 112
6.5 Logic symbol of DRAM16 112
6.6 State machine for the dual-port memory model 114
6.7 Logic symbol of the coprocessor for the
dual-port configuration 115
6.8 Logic symbol of the bus interface controller 115
6.9 Logic symbol of the coprocessor memory controller 116
6.10 State machine of the coprocessor memory
accesses controller 117
6.11 State machine of the DRAM controller 118
6.12 Logic symbol of the main controller 119

List of Figures xiii
6.13 Chart for Tb and Ti, in terms of iterations 123
6.14 Coprocessor memory access 124
6.15 Synchronization between memory controller
and accelerator 125
7.1 Addressing different memory levels 135
7.2 Block placement policies, with 8 cache blocks
and 32 main memory blocks 136
7.3 Coprocessor board for the cache
memory configuration 138
7.4 Logic symbol of the cache memory model 139
7.5 Flowchart for the cache memory model 140
7.6 Logic symbol of the coprocessor for the
cache configuration 140
7.7 Logic symbol for the coprocessor memory controller 141
7.8 Virtual address for the cache memory configuration 141
7.9 Cache directory 142
7.10 Algorithmic state machine for the coprocessor
memory controller 143
7.11 Logic symbol of the bus interface controller for the
cache configuration 146
7.12 Algorithmic state machine for the block transfer 147
7.13 Algorithmic state machine for the block updating 149
7.14 Coprocessor cache memory write 151
7.15 Bus arbitration when there is a cache miss 152
7.16 Transferring a word from the cache to the
main memory 153
7.17 End of the block transfer during a cache miss 155
7.18 End of coprocessor operation and beginning
of block update 157
7.19 End of transfer of block 0 158
7.20 Handshake completion after block updating 159
7.21 C program example, with random address locations 168

List of Tables
2.1 Some characteristics of the XC4000 family of FPGAs 18
3.1 Performance results for PLUM 47
3.2 Performance results for EGCHECK 48
5.1 Performing 10 internal operations and a single
memory access per iteration 94
5.2 Performing 100 internal operations and one
5.3 Performing 10 iterations and a single memory access
per iteration 96
5.4 Performing 10 iterations and 10 internal operations 98
5.5 Performing 10 internal operations and no
memory accesses 100
5.6 Performing 10 internal operations and 2 memory
accesses per iteration 101
6.3 Performing 10 iterations and a single memory
access per iteration 127
6.4 Performing 10 iterations and 10 internal operations 128
xv

xvi List of Tables
7.1 Performing 10 operations and 1 memory access
per iteration with BS = 512 bytes 160
per iteration, with BS = 256 bytes 163
per iteration, with BS = 128 bytes 164
7.4 Performing 10 iterations and 10 internal
operations, with BS = 512 bytes 165
access per iteration, with BS = 512 bytes and
random address locations 167
per iteration, with BS = 128 bytes and random
address locations 169

Preface
In this Book, we are concerned with studying the co-design methodology,
in general, and how to determine the more suitable interface mechanism in a
co-design system, in particular. This will be based on the characteristics of
the application and those of the target architecture of the system. We provide
guidelines to support the designer’s choice of the interface mechanism.
The content of this book is divided into 8 chapters, which will be described
in the following:
In Chapter 2, we present co-design as a methodology for the integrated
design of systems implemented using both hardware and software components.
This includes high-level synthesis and the new technologies available for its
implementation. Recent work in the co-design area is introduced.
In Chapter 3, the physical co-design system developed at UMIST is then
presented. The development route adopted is discussed and the target architec-
ture described. Performance results are then presented based on experimental
results obtained. The relation between the execution times and the interface
mechanisms is analysed.
In order to investigate the performance of the co-design system for differ-
ent characteristics of the application and of the architecture, we developed, in
Chapter 4, a VHDL model of our co-design system.
In Chapter 5, a case study example is presented, on which all the subse-
quent analysis will be carried out. The timing characteristics of the system are
introduced, that is times for parameter passing and bus arbitration for each inter-
face mechanism, together with their handshake completion times. The relation
between the coprocessor memory accesses and the interface mechanisms is
then studied.
In Chapter 6, a dual-port shared memory configuration is introduced, in
substitution to the single-port shared memory of the original configuration. This
new configuration aims to reduce the occurrence of bus contention, naturally
present in a shared bus architecture. Our objective is to identify performance
xvii

xviii Preface
improvements due to the substitution of the single-port shared memory by the
dual-port shared memory.
In Chapter 7, A cache memory for the coprocessor is later on introduced into
the original single-port shared memory configuration. This is an alternative
to the dual-port memory, allowing us to reduce bus contention, while keeping
the original shared memory configuration. The identification of performance
improvements, due to the inclusion of a cache memory for the coprocessor in
the original implementation, is then carried out.
In Chapter 8, we describe new trends in co-design and software acceleration.
N. Nedjah and L. M. Mourelle

Acknowledgments
We are grateful to FAPERJ (Fundação de Amparo à Pesquisa do Estado do
Rio de janeiro, http://www.faperj.br) and CNPq (Conselho Nacional de
Desenvolvimento Cientı́fico e Tecnológico, http://www.cnpq.br) for their
continuous financial support.
xix

Chapter 1
INTRODUCTION
In a digital system, hardware is usually considered to be those parts of the
system implemented using electronic components, such as processors, registers,
logic gates, memories and drivers. Software is thought of as the sub-systems
implemented as programs stored in memory as a sequence of bits, which are
read and executed by a processor. In a traditional design strategy, the hardware
and software partitioning decisions are fixed at an early stage in the development
cycle and both designs evolve separately (Kalavade and Lee, 1992; Kalavade
and Lee, 1993; N. S. Woo and Wolf, 1994). Certain operations are clearly
implemented by hardware, such as high-speed data packet manipulation; others
by software, such as recursive search of a tree data structure; and there are
usually a collection of further operations that can be implemented either by
hardware or by software. The decision to implement an operation in hardware
or software is based on the available technology, cost, size, maintainability,
flexibility and, probably most importantly, performance.
Advances in microelectronics have offered us large systems containing a
variety of interacting components, such as general-purpose processors, com-
municationsub-systems, special-purpose processors (e.g., Digital Signal Pro-
cessors–DSP),micro-programmedspecial-purposearchitectures, off–the-shelf
electronic components, logic-array structures (e.g., Field Programmable Gate-
Arrays – FPGAs) and custom logic devices (e.g., Application Specific Inte-
grated circuits – ASICs) (Subrahmanyam, 1992; Subrahmanyam, 1993; Wolf,
2004).
Today’s products contain embedded systems implemented with hardware
controlled by a large amount of software (G. Borriello, 1993). These sys-
tems have processors dedicated to specific functions and different degrees of
1

2 Introduction
programmability (Micheli, 1993) (e.g., microcontrollers), namely the appli-
cation, instruction or hardware levels. In the application level, the system is
running dedicated software programs that allows the user to specify the desired
functionality using a specialized language. At the instruction level, program-
ming is achieved by executing on the hardware, the instructions supported by
the architecture. hardware-level programming means configuring the hardware,
after manufacturing, in the desired way. There have also been advances in some
of the technologies related to design system, such as logic synthesis, and sys-
tem level simulation environments, together with formal methods for design
specification, design and verification (Subrahmanyam, 1992; Subrahmanyam,
1993).
In this chapter, we discuss the concept of synthesis and design approaches.
Later on, the co-design concept is introduced, together with a methodology for
its application. Finally, the objective of this book is then presented, together
with its structure.
1.1 Synthesis
Synthesis is the automatic translation of a design description from one level
of abstraction to a more detailed, lower level of abstraction. A behavioral
description defines the mapping of a system’s inputs to its outputs and a struc-
tural description indicates the set of interconnected components that realize the
required system behavior. The synthesis process offers reduction in the over-
all design time and cost of a product, together with a guarantee of the circuit
correctness. However, the synthesized design may not be as good as one pro-
duced manually by an experienced designer. Architectural synthesis allows the
search for the optimal architectural solution relative to the specified constraints
(E. Martin and Philippe, 1993).
High-level synthesis is the process of deriving hardware implementations
for circuit s from high-level programming languages or other high-level speci-
fications (Amon and Borriello, 1991). In order to have a behavioral description
of the system, we use a hardware Description Language (HDL), which offers
the syntax and semantics needed. As examples of suitable HDLs, we have
the Specification and Description Language (SDL) (Rossel and Kruse, 1993;
A.A.JerrayaandIsmail, 1993), theVeryhighspeedintegratedcircuitshardware
Description Language (VHDL) (Ecker, 1993a; Ecker, 1993b; Navabi, 1998),
the high-level description language HardwareC (Gupta, 1993; R. K. Gupta and
Micheli, 1992a; R. K. Gupta and Micheli, 1992b; R. K. Gupta and Micheli,
1994; Gupta and Micheli, 1992; Gupta and Micheli, 1993; Ku and Micheli,
1990). Instead of a hardware description language, it is possible to use a high-
level programming language, such as C or C++, to describe the system behav-
ior, making the translation to a hardware description language at a later stage of
the design process (M. D. Edwards, 1993; Edwards and Forrest, 1994; Edwards

Design Approaches 3
and Forrest, 1995; Edwards and Forrest, 1996a; Edwards and Forrest, 1996b;
P. Pochmuller and Longsen, 1993).
Using high-level synthesis techniques, we can synthesize digital circuits
from a high-level specification (Thomas, 1990; D. E. Thomas and Schmit,
1993) which have the performance advantages offered by customizing the arc-
hitecture to the algorithm (Srivastava and Brodersen, 1991; M. B. Srivastava
and Brodersen, 1992). Nevertheless, as the number of gates increases, the
cost and turnaround time, i.e., the time taken from the design specification
until its physical implementation, also increase, and for large system designs,
synthesized hardware solutions tend to be expensive (Gupta, 1993; Gupta and
Micheli, 1993).
Despite the increase in power and flexibility achieved by new processors,
users are always asking for something more. In order to satisfy this demand,
it would be necessary to add special-purpose modules to a processor sys-
tem. However, this would constrain the system and the usually small market
generated for a specialized function discourages companies from developing
hardware to satisfy such needs. A solution to this problem would be the use
of a reconfigurable system, based on, say, Field-Programmable Gate Arrays
(FPGAs), which could be attached to a standard computer, for performing
functions normally implemented by special-purpose cards (D. E. Van den Bout,
1992). This kind of implementation offers faster execution, low cost and low
power, since the necessary logic is embedded in the ASIC component.
1.2 Design Approaches
For a behavioral description of a system implemented as a program, running
on a processor, we have a low cost and flexible solution. Typically, the pure
software implementations of a system are often too slow to meet all of the
performance constraints, which can be defined for the overall time (latency) to
perform a given task or to achieve predetermined input/output rates (R. K. Gupta
and Micheli, 1992b). Depending on these constraints, it may be better to have
all or part of the behavioral description of the system implemented as a hard-
ware circuit. In this kind of implementation, hardware modifications cannot be
performed as dynamically as in a software implementation and the relative cost
is higher, since the solution is customized.
System designers are faced with a major decision: what kind of imple-
mentation is the best, given a behavioral description of a system and a set of
performance constraints – a software or a hardware solution? Cost-effective
designs use a mixture of hardware and software to accomplish their overall
goals (Gupta, 1993; Gupta and Micheli, 1993). Dedicated systems, with hard-
ware and software tailored for the application, normally provide performance
improvements over systems based on general-purpose hardware (Srivastava
and Brodersen, 1991; M. B. Srivastava and Brodersen, 1992). Mixed system

4 Introduction
designs, using ASICs, memory, processors and other special-purpose modules
reduce the size of the synthesis task by minimizing the number of application-
specific chips required, while, at the same time, achieving the flexibility of
software reprogramming to alter system behavior. However, the problem is
usually more complex, since the software on the processor implements system
functionality in an instruction-driven manner with a statically allocated memory
space, whereas ASICs operate as data-driven, ıreactive elements (Chiodo and
Sangiovanni-Vincentelli, 1992; Gupta and Micheli, 1992). Nevertheless, addi-
tional problems must also be solved (R. K. Gupta and Micheli, 1992a; Gupta
and Micheli, 1992), such as:
modeling system functionality and constraints;
determining the boundaries between hardware and software components in
the system model;
specifying and synthesizing the hardware-software interface;
implementing hardware and software components.
1.3 Co-Design
Co-design refers to the integrated design of systems implemented using both
hardware and software components (Subrahmanyam, 1992; Subrahmanyam,
1993), given a set of performance goals and an implementation technology. In
this way, it is not a new approach to designing systems. What is new is the
requirement for systematic, scientific co-design methods (Wolf, 1993). The
co-design problem entails characterizing hardware and software performance,
identifying a hardware-software partition, transforming the functional descrip-
tion of a system into such a partition and synthesizing the resulting hardware
and software (D. E. Thomas and Schmit, 1993).
From a behavioral description of the system, that is an implementation ind-
ependent one, a partitioning could be performed into hardware and software
components based on imposed performance constraints. hardware solutions
may provide higher performance by supporting the parallel execution of ope-
rations, but there is the inherent cost of fabricating one or more ASICs. On
the other hand, software solutions will run on high-performance processors,
which are available at lower cost due to high-volume production. However, the
serialization of operations and the lack of specific support for some tasks can
decrease performance (Micheli, 1993).
Designers might start with an all-software implementation, in which case
it is said to be a software-oriented approach (M. D. Edwards, 1993; Edwards
and Forrest, 1994; Edwards and Forrest, 1995; Edwards and Forrest, 1996a;
Edwards and Forrest, 1996b; Ernst and Henkel, 1992; R. Ernst and Benner,

Co-Design 5
1993) and check the implementation’s functionality. Later on, they might refine
the design over time to get a mixed hardware-software design (M. D. Edwards,
1993; Edwards and Forrest, 1994; Edwards and Forrest, 1995; Edwards and
Forrest, 1996a; Edwards and Forrest, 1996b; N. S. Woo and Wolf, 1994;
N. S. Woo and Dunlop, 1992), in which ASIC components are chosen to
complement performance or add functionality not achievable by pure program
implementations alone (Gupta and Micheli, 1992), such as floating-point oper-
ations. On the other hand, it is possible to start with a hardware implementation,
called a hardware-oriented approach (R. K. Gupta and Micheli, 1992b), and try,
gradually, to move hardware functions to software, taking into account timing
constraints and synchronization requirements.
Agood design trade-off is to improve the event that happens more frequently.
The impact of making some occurrence faster is higher if the occurrence is
frequent. Therefore, the point now is to decide what the frequent case is and
how much performance can be improved by making that case faster. We will
return to this subject in Chapter 3, when the co-design system developed at
UMIST is discussed.
1.3.1 Methodology
In recent years, several integrated CAD environments for the automatic gen-
eration of ASICs have been developed, that have resulted in a reduction in the
overall design time of a system (Srivastava and Brodersen, 1991). On the other
hand, computer aids are available in order to assist with the structured design
of software systems. In practice, we may want to (Chiodo and Sangiovanni-
Vincentelli, 1992):
formally verify a design in order to check whether the system satisfies a
number of properties that specify its correctness;
simulate to check whether the system responds correctly to the stimuli that
the environment is supposed to produce;
automatically synthesize an implementation consistent with user-defined
criteria, such as speed and area.
The chosen synthesis methodology may be for general-purpose applica-
tions (M. D. Edwards, 1993; Edwards and Forrest, 1994; Edwards and Forrest,
1995; Edwards and Forrest, 1996a; Edwards and Forrest, 1996b) or for domain-
specificapplications, suchasDSPs(KalavadeandLee, 1992;KalavadeandLee,
1993) or ASIPs (A. Alomary, 1993). Some tools are available using high-level
synthesis techniques to generate a purely hardware implementation of a system,
such as CATHEDRAL II (J. Rabaey, 1988), OLYMPUS (G. De Micheli and
Truong, 1990), SystemArchitecture’s Workbench (Thomas, 1990) and CONES
(Stroud, 1992).

6 Introduction
A framework for co-design means a methodology along with a comple-
mentary set of tools for specification, development, simulation/prototyping and
testing (Subrahmanyam, 1992; Subrahmanyam, 1993). It must provide esti-
mates of the performance metrics, such as size, power, cost, maintainability,
flexibility and modifiability. In (Kalavade and Lee, 1992; Kalavade and Lee,
1993), a framework called PTOLEMY is used for simulating and prototyping
heterogeneous systems, while in (Buchenrieder and Veith, 1992; Buchenrieder,
1993; Buchenrieder and Veith, 1994) another framework called CODES is used
as a environment for concurrent system design.
1.3.2 Simulation
Another interesting problem is related to the simulation of hardware, taking
into account the existence of the associated software. This is known as
co-simulation (D. Becker and Tell, 1992; D. E. Thomas and Schmit, 1993).
In this case, both software and hardware are expected to be developed in par-
allel and their interaction is analyzed, using the simulation of the hardware
components.
POSEIDON (R. K. Gupta and Micheli, 1992a; Gupta and Micheli, 1992) is a
tool that allows for the simulation of multiple functional modules implemented
either as a program or as behavioral or structural hardware models.
1.3.3 Architecture
In a co-design system, the target system architecture usually consists of a
software component, as a program running on a re-programmable processor,
assisted by application-specific hardware components (M. D. Edwards, 1993;
Edwards and Forrest, 1994; Edwards and Forrest, 1995; Edwards and Forrest,
1996a; Edwards and Forrest, 1996b; Gupta, 1993; R. K. Gupta and Micheli,
1992a; R. K. Gupta and Micheli, 1992b; R. K. Gupta and Micheli, 1994; Gupta
and Micheli, 1992; Gupta and Micheli, 1993). Some aspects that lead to this
kind of implementation are (Srivastava and Brodersen, 1991; Subrahmanyam,
1993):
the increasing diversity and complexity of applications employing embed-
ded systems (D. D. Gajski and Gong, 1994);
the need for decreasing the cost of designing and testing such systems;
advances in some of the key enabling technologies, such as logic synthesis
and formal methods.
1.3.4 Communication
From the hardware/software co-design point of view, it is important to ensure
the proper communication between the hardware and software sub-systems.
If we take a closer look at software running on a processor, we recognize

Structure and Objective 7
that hardware/software communication is nothing else but hardware/hardware
communication (Monjau and Bunchenrieder, 1993) at the lower levels. Thus,
if we are able to map the abstract communication to distinct protocols for
the hardware parts, we can also do this for the communication between the
hardware and software parts. From a software perspective, communication
with the hardware processes of the system has to be performed via some special
device driver software and associated system calls provided by the processor’s
operating system (Rossel and Kruse, 1993).
Due to the parallelism associated with embedded systems, they can be exp-
ressed as a set of concurrent sequential processes communicating via message
queues (Monjau and Bunchenrieder, 1993; M. B. Srivastava and Brodersen,
1992). Amon (Amon and Borriello, 1991) discusses the problem of sizing
synchronization queues, in order to implement constructs such as send and
receive.
1.4 Structure and Objective
In the rest of the book, we present co-design as a methodology for the
integrated design of systems implemented using both hardware and software
components. The initial system specification is partitioned into hardware and
software sub-systems that will have to communicate during the execution of
the application. The objective of this research is to analyze the behavior of
the co-design system, based on different interface mechanisms between the
hardware and software sub-systems. As a result of this analysis, we provide
some guidelines to support the designer in the choice of the most suitable
interface, according to the of the application and of the co-design system
under consideration.
In Chapter 2, the co-design methodology is discussed in more detail. High-
level synthesis is also presented, together with the new technologies available
for its implementation. Along with the discussion, recent work in the co-design
area is introduced as examples. In Chapter 3, the physical co-design system
developed at UMIST is discussed. The development route is outlined and the
target architecture is described. performance results are then presented based
on experimental results obtained. The relation between the execution times and
the interface mechanisms employed is then discussed.
In Chapter 4, we present the VHDLmodel of our co-design system. Since we
have already a physical implementation of the system, the procedure adopted for
modeling it is explained. Most of the components will be manually translated
from their previous description into VHDL, in a quite straightforward process.
Others, such as the global memory, will have to be modeled based on their
behavior and how they interface with the rest of the system.
In Chapter 5, the simulation of the VHDL model of the co-design system
is described. A case study example is presented, on which all the subsequent

8 Introduction
analysis will be carried out. The timing of the system are introduced, that is
times for parameter passing and bus arbitration for each interface mechanism,
together with their handshake completion times. The relation between the
coprocessor memory accesses and the interface mechanisms is then analyzed.
In Chapter 6, we continue the simulation process, based on a dual-port shared
memory configuration. The new system’s architecture is presented, together
with the necessary modifications to the original VHDL models and the deriva-
tion of new models. Once again, the timing of the new system are introduced.
performance results are obtained based on the same case study used in the pre-
vious chapter. Our aim is to identify any performance improvement due to the
substitution of the single-port shared memory, in the original implementation,
by the dual-port shared memory.
In Chapter 7, a cache memory for the coprocessor is introduced into the
original single-port shared memory configuration. The concept of memory
hierarchy design is discussed, in order to provide the necessary background
for the subsequent analysis. So far, the new organization of the system is pre-
sented, together with the necessary modifications to the existing VHDL models
and the derivation of new modules. Continuing our study of the system’s per-
formance, timing are then presented. performance results are obtained based
on the same case study used in the two previous chapters. The identification
of performance improvements, due to the inclusion of a cache memory for the
coprocessor in the original implementation, is carried out. In Chapter 8, we
present some conclusions based on this research and some ideas for future work
are also outlined. A comparison between the single shared memory configu-
ration, the dual-port shared memory configuration and the coprocessor cache
configuration is undertaken, based on the simulation results obtained.

Chapter 2
THE CO-DESIGN METHODOLOGY
Computing systems are becoming increasingly complex and often contain
large amounts of both hardware and software. The need for methodological sup-
port in managing the development process of such systems, therefore, becomes
more urgent. The user’s requirements are partitioned into functional and non-
functional subsets, from which a functional view and an architectural view, i.e.,
the environment the system has to function in, can be derived. The subject of
computing is then split between hardware and software at an early stage. The
hardware development will be based on cost and performance, whilst the soft-
ware development will be guided by the functional requirements of the system.
Each development process will have its own models in its own environment.
Problems discovered during integration and test, but after hardware fabrica-
tion, cause projects to run over budget, behind schedule and result in systems
that may not fully satisfy user needs (Kuttner, 1996). Hence, it is important to
produce systems that are “right first time”.
The design of heterogeneous hardware/software systems is driven by a desire
to maximize performance and minimize cost. Therefore, it is necessary to use
an integrated design environment, which is capable of investigating and model-
ing the performance and process functionality of the hardware/software system
(Cooling, 1995). The design process can be defined as a sequence of transfor-
mations that begins with a system specification and leads to an implementation
of the system. The steps in the sequence are defined by system models in dec-
reasing levels of abstraction and, at every step in the sequence, an input model
is transformed into an output model (Monjau and Bunchenrieder, 1993).
This chapter presents the co-design methodology and recent developments
in this area. High-level synthesis is also discussed as it is central to the
9

10 The Co-design Methodology
implementation of mixed hardware/software systems. New implementation
technologies are presented followed by a review of the available synthesis tools.
2.1 The Co-Design Approach
Co-design refers to a methodology for the integrated design of systems imp-
lementedusingbothhardwareandsoftwarecomponents(Subrahmanyam, 1993),
given a set of performance goals and an implementation technology. In this
way, it is not a new approach. What is new is the requirement for system-
atic, scientific co-design methods (Wolf, 1993). The co-design problem entails
(D. E. Thomas and Schmit, 1993):
characterizing hardware and software performance;
identifying a hardware/software partition;
transforming the functional description into such a partition;
synthesizing the resulting hardware and software.
From a behavioral description of the system, that is implementation inde-
pendent, a partitioning could be done into hardware and software compo-
nents, based on imposed performance constraints (R. K. Gupta and Micheli,
1992a; R. K. Gupta and Micheli, 1992b; Gupta and Micheli, 1992), cost,
maintainability, flexibility and area, in terms of logic and space requirements
(N. S. Woo and Wolf, 1994). hardware solutions may provide higher perfor-
mance by supporting the parallel execution of operations, but there is the cost
of fabricating one or more ASICs1. On the other hand, software solutions will
run on high-performance processors available at low cost due to high-volume
production. However, the serialization of operations and the lack of specific
support for some tasks can decrease performance (Micheli, 1993).
A framework for co-design means a methodology along with a complemen-
tary set of tools for the specification, development, simulation/prototyping
and testing of systems. It may be suitable for general-purpose applications
(M. D. Edwards, 1993; Edwards and Forrest, 1994; Edwards and Forrest,
1995; Edwards and Forrest, 1996a; Edwards and Forrest, 1996b) or for a spe-
cificdomain(KalavadeandLee, 1992;KalavadeandLee, 1993), but, ingeneral,
the co-design methodology consists of the steps presented in Figure 2.1. The
following sections introduce each step.
An example of a framework for co-design is PTOLEMY (J. Buck and
Messerschmitt, 1990; University of California and Science, 1992), a soft-
ware environment for the simulation and prototyping of heterogeneous sys-
tems. It uses object-oriented software technology to model sub-systems using
different techniques and has mechanisms to integrate these sub-systems into a
complete model.

System Specification 11
Figure 2.1. The co-design flow
Another example of framework for co-design is POLIS (F. Balarin, 1997),
which makes use of a methodology for specification, automatic synthesis and
validation of embedded systems (D. D. Gajski and Gong, 1994). Design is
done in a unified framework, with unified hardware/software representation,
so as to prejudice neither hardware nor software implementation (Wolf, 2002).
This model is maintained throughout the design process, in order to preserve
the formal properties of the design. POLIS uses the PTOLEMY environment
to perform co-simulation. Partitioning is done using this co-simulation, thus
allowing a tight interaction between architectural choices and performance/cost
analysis.
The COSYMA system (Ernst and Henkel, 1992; R. Ernst and Benner, 1993)
is a platform for co-synthesis of embedded architectures. It follows a software-
oriented co-synthesis approach, in which as many operations as possible are
implemented in software. External hardware is generated only when timing
constraints are violated. COSYMA uses the OLYMPUS (G. De Micheli and
Truong, 1990) high-level synthesis tool for hardware synthesis and simulation.
2.2 System Specification
For system specification, we can use a hardware description language, such
as VHDL (Ecker, 1993a; Ecker, 1993b; Wendling and Rosenstiel, 1994). The
development of VHDL as a general design tool was to overcome the problem
of a design becoming target dependent. In this way, a design may be created
in VHDL and the target technology chosen after the fact. The design may then
be synthesized into a target technology by the application of synthesis tools.
Once the technology changes, it will be necessary to re-synthesize the design
only, instead of a complete logic redesign. The resulting benefit to the user

is a dramatic reduction in time-to-market by saving on learning curve time,
redesign time and design entry time.
Another possibility is of using a high-level description language, such as
HardwareC (Gupta, 1993; R. K. Gupta and Micheli, 1992a; R. K. Gupta and
Micheli, 1992b; R. K. Gupta and Micheli, 1994; Gupta and Micheli, 1992;
Gupta and Micheli, 1993) for the system specification. The HardwareC lang-
uage (Ku and Micheli, 1990) has a C-like syntax and supports timing and res-
ource constraints. This language supports specification of unbounded and
unknown delay operations that can arise from data dependent decisions and
external synchronization operations.
A high-level programming language, such as C or C++, can also be used
for system specification (M. D. Edwards, 1993; Edwards and Forrest, 1994;
Edwards and Forrest, 1995; Edwards and Forrest, 1996a; Edwards and Forrest,
1996b). In this case, we can say that the design follows a software-oriented
approach, in contrast to the hardware-oriented approach provided by VHDL
and HardwareC. The translation to a hardware description language is made at
a later stage in the design process.
There are some languages used for specific applications, such as the Specifi-
cation and Description Language (SDL) (Rossel and Kruse, 1993), for commu-
nicationsystems, andPROMELA(A.S.WenbanandBrown, 1992), ahigh-level
concurrent programming language used for communication protocol specifica-
tions. In (N. S. Woo and Wolf, 1994; N. S. Woo and Dunlop, 1992), an Object-
Oriented Functional Specification language (OOFS) is used, in order to avoid
biasing the initial specification to hardware or software.
When using PTOLEMY(Kalavade and Lee, 1992; Kalavade and Lee, 1993),
the specification of the system is described in domains, which provides a differ-
ent computational model, such as the Synchronous Data Flow (SDF ) domain,
for filters and signal generators, and the digital-hardware modeling (Thor)
domain, for digital hardware.
2.3 Hardware/Software Partitioning
Given some basis for evaluating system performance, it is possible to decide
which tasks should be implemented as hardware and which as software. If
a task interacts closely with the operating system, software may be the only
feasible implementation. Likewise, if a task interacts closely with external
signals, implementing it in hardware may be the only practical solution. We
can determine which to pursue according to the following criteria:
dynamic properties of the system: a characterization of how the execution
time of a task impacts system performance;
static properties of the task: the difference in execution times between
hardware and software implementations of the task;

Hardware/Software Partitioning 13
hardware costs: the amount of custom hardware required to realize a
hardware implementation of the task.
The first consideration takes into account how the system performance dep-
ends on the execution time of each task, which in turn depends on the criterion
by which system performance is measured. In the second case, some tasks
are inherently much better suited for hardware implementation than others.
To quantify these differences, we must identify properties of a task behavior
that indicate how software and hardware implementations of the task will per-
form. In considering the amount of custom hardware necessary to reduce a
task execution time, we must see that, for some tasks, custom hardware imple-
mentations might perform well, but be impractical due to high gate counts or
memory requirements. For others, there may be a range of achievable perfor-
mance gains, depending on how much of the custom hardware is devoted to
the task.
In the case of embedded systems (D. D. Gajski and Gong, 1994; Wolf, 2002),
a hardware/software partition represents a physical partition of the system func-
tionality into application-specific hardware (coprocessor) and software execut-
ing on one or more processors. The hardware/software interface strongly affects
partitioning. The aim in this kind of architecture is to improve the system per-
formance. In this sense, partitioning seeks to maximize the overall speedup for
a given application. The speedup estimation can be done by a profiling analysis
that takes into account typical data sets over which the application behavior is
estimated. Due to this data dependence, in some application areas the speedup
may not be a well-defined metric or it may not be a useful metric either, par-
ticularly in those with real-time response requirements. In such cases, the size
of the implementation and timing constraint satisfaction are used to drive the
partitioning decision. Some partitioning strategies are discussed in (Micheli
and Gupta, 1997).
In (M. D. Edwards, 1993; Edwards and Forrest, 1994; Edwards and Forrest,
1995; Edwards and Forrest, 1996a; Edwards and Forrest, 1996b), from a system
specification written in C, partitioning is based on the identification of perfor-
mance critical regions, using an interactive profiling tool. The partitioning tool
(Wright, 1997) then translates the C code for the body of a critical region to
a hardware description language representation, in order to enable high-level
hardware synthesis. The identified C source code for a critical region is adapted
to implement a “hardware” call/return mechanism, which invokes the associ-
ated operations in the hardware component (see Section 3.1.2).
Another method implements partitioning based on the fact that some oper-
ations are best performed by hardware, others by software and some either by
hardware or by software (N. S. Woo and Wolf, 1994; N. S. Woo and Dunlop,

1992). This yields three groups of operations: hardware (H), software (S) and
co-design (C). Each object and operation in the S group is defined in the C++
language. Each object and operation in the H group is defined in C++ in order
to emulate the object and its operation. These C++ programs will be used for
a simulation of the whole system. Each object and operation in the C group
is defined in OOFS (Object-Oriented Functional Specification). The system
designers indicate whether each specification in the last group will be imple-
mented by software or by hardware, which will define the translation from
the co-specification language to C++ or BESTMAP-C (Laboratories, 1992), a
hardware description language, respectively.
The HardwareC description used in (Gupta, 1993; R. K. Gupta and Micheli,
1992a; R. K. Gupta and Micheli, 1992b; R. K. Gupta and Micheli, 1994; Gupta
and Micheli, 1992; Gupta and Micheli, 1993) is compiled into a system graph
model based on data-flow graphs. This graph consists of vertices representing
operations and edges which represent serialization among operations. Overall,
the system graph model is composed of concurrent data flow sections, which
are ordered by the system control flow. Considering an initial solution in hard-
ware, some operations are selected for moving into software, based on a cost
criterion of communication overheads. With the serialization of the operations
and analysis of the corresponding assembly code, delays through the software
component can be derived. The movement of operations to software is then con-
strained by the satisfaction of timing constraints. As a second approach to sys-
tem partitioning, the effect of non-determinism is taken into account, which is
caused either by external synchronization operations (send, receive) or by inter-
nal data-dependent delay operations (loops, conditionals). System partitioning
is performed by decoupling the external and internal points of non-determinism
in the system model. The external non-deterministic points are implemented
using application-specific hardware and the internal non-deterministic points
are implemented in software. If the initial partition is feasible, then it is refined
by migrating operations from hardware to software, in search for a lower cost
feasible partition. The partition is indicated by “tagging” the system graph’s
vertices to be either hardware or software.
In (Ernst and Henkel, 1992; R. Ernst and Benner, 1993), as many operations
as possible are implemented in software, using a subset of the C language,
called C. External hardware is only generated when timing constraints are vio-
lated or in the case of I/O functions. The C-system description is parsed into a
syntax graph CGLincluding all constraints, on which partitioning is performed.
Those statements, which shall be implemented in software, are then translated
to regular C. The original program structure is kept throughout the partitioning
process.

Hardware Synthesis 15
In PTOLEMY (Kalavade and Lee, 1992; Kalavade and Lee, 1993), par-
titioning is performed manually, based on speed, complexity and flexibility
requirements. The specification to be implemented in custom hardware and
written in SDF2 is translated to SILAGE (Hilfinger, 1985), a functional lan-
guage. This provides a link to high-level synthesis systems, that use SILAGE
as specification of their inputs (Goosens, 1993; Rabaey, 1991).
POLIS (F. Balarin, 1997) provides the designer with an environment to eval-
uate design decisions through feedback mechanisms, such as formal verifica-
tion and system co-simulation. As a result of partitioning, we find finite state
machine sub-networks chosen for hardware implementation and those chosen
for software implementation.
COSYMA (R. Ernst and Benner, 1993) executes hardware/software parti-
tioning on a graph representation of the system by marking nodes to be moved
to hardware. It follows an iterative approach, including hardware synthesis,
compilation and timing analysis of the resulting hardware/software system.
Simulation and profiling identify computation-time-intensive system parts. An
estimation of the speedup is obtained through hardware synthesis and the com-
munication penalty for nodes moved to hardware.
The communication between the processor and the application-specific hard-
ware implies additional delays and costs related to the interface circuit and pro-
tocol implemented. Once the integration phase has finished, simulation results
should be returned to the partitioning stage, so that these additional parameters
may be used to obtain a better hardware/software partition, i.e., one that will
provide a better performance/cost trade-off.
2.4 Hardware Synthesis
Hardware synthesis is employed to generate the logic network for the hard-
ware component. Synthesis is concerned with a reduction in design time and
projectcost, togetherwithaguaranteeofcorrectnessforthecircuit. Thestrategy
for the synthesis process, given the behavioral specification of the system and
a set of constraints, consists of finding a structure that implements the behavior
and, at the same time, satisfies the constraints. A fundamental concept in the
design of synthesis tools is that, from an implementation independent system
specification, and based on the target technology libraries and user constraints,
a number of possible implementations can be obtained (Jay, 1993).
With the complexity found in new technologies, it is crucial to employ
automatic synthesis tools (G. De Micheli and Truong, 1990), as part of the
design process. Automatic synthesis presents some facilities, such as:
shorter design cycle, which means that a product can be completed faster,
decreasing the cost in design and the time-to-market;

fewer errors, since the synthesis process can be verified, increasing the
chance that the final design will correspond to the initial specification;
the ability to search the design space, since the synthesis system can offer
a variety of solutions from the same specification, i.e., a particular solution
can be chosen by the designer in order to satisfy tradeoffs between cost,
speed or power;
documenting the design process, which means keeping track of the decisions
taken and their effects;
availability of integrated circuit technology to more people, as more design
expertise is moved into the synthesis system, allowing non-expert people to
produce a design.
2.4.1 High-Level Synthesis
High-level synthesis (M. C. McFarland and Camposano, 1990) obtains an
optimized register-transfer description from an algorithmic one, which can be
written in a high-level programming language or a hardware description lan-
guage. The register-transfer description consists of an interconnected set of
functional components (data path) together with the order in which these com-
ponents are activated (control path). An example of high-level synthesis tool
is the System Architect’s Workbench (Thomas, 1990).
From the algorithmic description, a Control and Data Flow Graph (CDFG)
can be derived, which specifies a set of data manipulation operations, their data
dependencies and the order of execution of these operations. This graph can
be optimized through the use of transformations similar to those found in a
software compiler. Later on, scheduling and allocation are undertaken.
The scheduling process means assigning data operations for execution in
particular clock cycles. This allows the minimization of the number of clock
cycles needed for the completion of the algorithm, given a set of hardware
resources, which involves maximizing the number of operations that can be
done in parallel, in each cycle. Some scheduling algorithms are considered in
(Micheli and Gupta, 1997).
The allocation task (M. C. McFarland and Camposano, 1990) assigns data
operations to hardware resources, minimizing the amount of hardware required,
in order to meet cost, area and performance constraints. A sub-task is module
binding, where known components are taken from a hardware library. If there
are not adequate components, then it might be necessary to generate a special-
purpose hardware, through the use of a logic synthesis tool. For the control path,
an implementation must be found using finite state machines with hardwired or
micro-programmed control.

2.4.2 Implementation Technologies
We can identify three types of logic devices (Coli, 1993):
standard logic;
programmable ASICs;
masked ASICs.
Standard logic devices are not specific to any particular application, being
connected together to build an application. Programmable Application Spe-
cific Integrated Circuits (ASICs) include simple Programmable Logic Devices
(PLDs), complex PLDs and Field Programmable Gate Arrays (FPGAs) (Wolf,
2004). Programmable ASICs are purchased in their un-programmed state and,
then, programmed by the user for a specific application. MaskedASICs include
gate-arrays and standard cells, being designed by the user for a specific applica-
tion, tooled by the chosen supplier and, finally, purchased as a custom product.
Circuit density and input/output count generally increase as one moves from
standard logic to programmable ASICs and, then, to masked ASICs.
Standard logic has the appeal of being purchased as a standard product,
but compromises system integration by restricting the designer to interconnect
many “catalogue” circuits. Masked ASICs are the opposite situation, in which
they can be easily customized for the user’s specific application, but must be
custom tooled and, therefore, purchased as a custom product. Programmable
ASICs are a good compromise, because they are purchased as a standard prod-
uct, but may be used as a custom product.
The configuration of Field Programmable Logic Devices (FPLDs) (York,
1993) is achieved by either EPROM technology, anti-fuse or embedded register.
EPROM and embedded registers are erasable, while the anti-fuse approach is
one-time programmable. The embedded register configuration technique is
commonly referred to as embedded RAM. All of the devices that are based
on an embedded register produce the configuration data using shift registers,
which, by its nature, is a serial process. The time-consuming delays, which
arise due to the complexity of silicon processing, are avoided and this helps to
facilitate a shorter time-to-market. It is now possible to implement systems of
appreciable complexity on a single field programmable chip.
A logic description of the circuit to be implemented in a Field Programm-
able Gate Array (FPGA) is created and, then, synthesized into a netlist. Syn-
thesis is a critical step in the FPGA design process. For this purpose, there
is a variety of input/output formats and tools available. The common goal
of all these tools is to simplify the design process, maximize the chance of

Table 2.1. Some characteristics of the XC4000 family of FPGAs
Device XC4002A XC4008 XC4020
Approximate gate count 2,000 8,000 20,000
CLB matrix 8 × 8 18 × 18 30 × 30
Number of CLBs 64 324 900
Number of flip-flops 256 936 2280
Max decode inputs (per side) 24 54 90
Max RAM bits 2,048 10,368 28,800
Number of IOBs 64 144 240
first-time-success and accelerate time-to-market. Unlike masked ASIC tools,
which are workstation based, a wide variety of FPGAtools are available on PCs
as well as workstations. This can lower the design cost of an FPGA. The high
quality and variety of FPGA CAE/CAD tools enhance FPGA design produc-
tivity. The availability of these tools on PCs and with open frameworks lowers
barriers to use and promotes user-friendly design (Coli, 1993).
FPGAs took advantage of the concept of multiple AND/OR arrays and
local connectivity, introduced by complex PLDs (Coli, 1993; Wolf,
2004). An FPGA die offers many small arrays, called logic cells, dispersed
around the chip. These logic cells are connected like a gate array using pro-
grammable interconnections. An example of FPGA is the XC4000 logic cell
array family, produced by Xilinx (Xilinx, 1992; Xilinx, 1993), using CMOS-
SRAM technology. It provides a regular, flexible, programmable architecture
of Configurable Logic Blocks (CLBs), interconnected by a powerful hierarchy
of versatile routing resources and surrounded by a perimeter of programmable
Input/OutputBlocks(IOBs). Figure2.2showsaCLBandprogrammableswitch
matrixes, which allow for the connectivity between other CLBS and IOBs. The
devices are customized by loading configuration data into the internal memory
cells. The FPGAcan either actively read its configuration data out of an external
serial or byte-parallel PROM (master mode) or the configuration data can be
written directly into the FPGA (slave and peripheral modes). Table 2.1 shows
the characteristics of some FPGAs from the XC4000 family.
The XC4000 family is the first programmable logic device to include on-chip
static memory resources. An optional mode for each CLB makes the memory
look-up tables usable as either a (16 × 2) or (32 × 1) bit array of read/write
memory cells. The RAMs are very fast: read access is the same as a logic
delay, about 5ns; write time is about 6ns; both are several times faster than
any off-chip solution. This feature creates new possibilities for the system

Figure 2.2. Typical CLB connections to adjacent lines
designer: registered arrays of multiple accumulators, status registers, index
registers, DMA counters, distributed shift registers, LIFO stacks and FIFO
buffers are all readily and easily implemented.
The Xilinx FPGAs are configured by the XACT design tools (Xilinx, 1994),
the Xilinx development system, running on PCs or popular workstations. After
schematic – or equation-based entry, the design is automatically converted to a
Xilinx Netlist Format (XNF). XACT interfaces to popular design environments
like Viewlogic, Mentor Graphics and OrCAD. The XC4000 series devices are
used within our co-design environment and the basic steps for their configura-
tion is presented in Section 3.1.3.
Another example of a commonly used FPGA is the Intel FLEXlogic iFX780
family (Intel, 1994), which is fabricated using 0.8µ CHMOS EPROM technol-
ogy. These devices are widely used in the target architecture of our co-design
system. It consists of 8 Configurable Function Blocks (CFBs) linked by a global
interconnect matrix. Each CFB can be defined either as a 24V10 logic block
(i.e., 24 input/output lines between the block and the global interconnect matrix,
and 10 input/output lines between the block and the external pins) or as a block

of 128 × 10 SRAM, as described in Figure 2.3. Any combination of signals
in the matrix can be routed into any CFB, up to the maximum fan-in of the
block (24). This combination will provide approximately 5,000 gates of logic.
The SRAM has a minimum read/write cycle of 15ns, comparable to off-chip
commercial ones. The combination of features available in the iFX780 makes
it ideal for a wide variety of applications, such as bus control, custom cache
control and DRAM control. The combination of SRAM and logic in a single
device becomes a big advantage when designing communication controllers
or bus interface controllers, where memory is required for buffering data in
addition to the logic for the controller itself.
The Intel FLEXlogic FPGA family is supported by industry standard design
entry/programming environments, including Intel PLDshell PlusTM software
(Intel, 1993), which runs on PCs. Third party tools support will be provided
by vendors like Cadence, Data I/O, Logical Devices, Mentor Graphics, Minc,
OrCAD, Viewlogic.
2.4.3 Synthesis Systems
The purpose of a synthesis system is to provide the designer with automatic
synthesis tools, which lead to an implementation configuration from an imple-
mentation independent specification of the system and is based on the target
technology. Besides synthesis itself, it usually provides the designer facili-
ties for validation and simulation of the system specification, before the final
configuration is obtained in the form of a gate netlist.
COSMOS (A. A. Jerraya and Ismail, 1993) is an example of synthesis env-
ironment that allows the translation of a system specification written in SDL
into VHDL, at the behavioral and register-transfer levels. Another example
is AMICAL (I. Park and Jerraya, 1992), an interactive architectural synthesis
system based on VHDL, which starts with a behavioral specification in VHDL
and generates a structural description that may feed existing silicon compilers
acting at the logic and register-transfer levels. The Princeton University Behav-
ioral Synthesis System (PUBSS) (W. Wolf and Manno, 1992) and the Siemens
High-Level Synthesis System (CALLAS) (J. Biesenack, 1993; Stoll and Duzy,
1992) are also examples of synthesis systems that use VHDL for the initial
specification of a system.
The OLYMPUS synthesis system (G. De Micheli and Truong, 1990) was
developed at Stanford University for digital design. It is a vertically integrated
set of tools for multilevel synthesis, technology mapping and simulation. The
system supports the synthesis ofASICs from behavioral descriptions, written in
HardwareC.Internalmodelsrepresenthardwareatdifferentlevelsofabstraction
and provide a way to pass design information among different tools. The
OLYMPUS system includes behavioral, structural and logic synthesis tools.
Since it is targeted for semi-custom implementations, its output is in terms of

Software Compilation 21
Figure 2.3. Intel FLEXlogic iFX780 configuration
gate netlists. Instead of supporting placement and routing tools, OLYMPUS
provides an interface to standard physical design tools, such as MISII (Brayton,
1987) for multiple-level logic optimization. Examples of co-design systems
using OLYMPUS for hardware synthesis can be found in (M. D. Edwards,
Forrest, 1996a; Edwards and Forrest, 1996b).
Another example of synthesis system is ASYL+/Programmable Logic Syn-
thesizer (ASYL+/PLS) (Technologies, 1995), which is dedicated to the FPGA/
CPLD3 user. It maps directly to physical cells in an optimized way. Xilinx
designs, for instance, are mapped to CLBs or F-map and H-map primitives.
Automatic migration is also implemented, so a design captured using the prim-
itives associated with one FPGA or PLD family and even an ASIC library can
be targeted to another. ASYL+/PLS comprises the ASYL+/VHDL tool, which
accepts all classical constructs of synthesizable VHDL in one of the broadest
VHDL support sets available.
2.5 Software Compilation
In PTOLEMY (Kalavade and Lee, 1992; Kalavade and Lee, 1993), the parts
of the SDF specification to be implemented as software are sent to a code
generation domain, that will generate the code for the target processor. Hence,

we can find an SDF domain synthesizing C code and a domain synthesizing
assembly code for DSP.
For communication protocols written in PROMELA (A. S. Wenban and
Brown, 1992), a software compiler translates the PROMELA program into
C++, suitable for embedded controllers. The user may need to supply addi-
tional C++ code, in order to support any external hardware interfaces.
1995; Edwards and Forrest, 1996a; Edwards and Forrest, 1996b), from a sys-
tem specification written in C, performance-critical regions are selected for
hardware implementation, using an interactive profiling tool. The identified
C source code for a critical region is then adapted to implement a “hardware”
call/return mechanism, which invokes the associated operations in the hardware
component. A more detailed description will be presented in Section 3.1.2.
In POLIS (F. Balarin, 1997), the finite state machine-like sub-network cho-
senforsoftwareimplementationismappedintoasoftwarestructurethatincludes
a procedure for each machine. The first step consists of implementing and opti-
mizing the desired behavior in a high-level, processor-independent representa-
tion of the decision process similar to a control/data flow graph. Subsequently,
the control/data flow graph is translated into portable C code to be used by any
available compiler, to implement and optimize it in a specific, microcontroller-
dependent instruction set.
2.6 Interface Synthesis
Interface synthesis involves adding latches, FIFOs or address decoders in
hardware and inserting code for I/O operations and semaphore synchronization
in software. The hardware interface circuitry can be described in a separate
behavioral model.
PTOLEMY offers some options, such as inter-processor communication
(IPC)orcommunicationbetweencustomhardwareandprocessors. Inmodeling
software, we represent an I/O system call, such as read or write to the hardware
device, by an appropriate inter-process communication primitive. In the case
of a process described in a hardware description language, where data transfer
and synchronization are often represented as explicit port operations, a single
inter-process communication primitive represents the set of port operations that
perform the data transfer and associated synchronization.
1995; Edwards and Forrest, 1996a; Edwards and Forrest, 1996b), after parti-
tioning, the resulting hardware description of the critical region, selected for
hardware implementation, includes the specification for parameter and control
passing. Hence, during hardware synthesis, the hardware function is synthe-
sized together with the data transfer and synchronization controls.

System Integration 23
In POLIS (F. Balarin, 1997), interface between different implementation
domains(hardwareandsoftware)isautomaticallysynthesized. Theseinterfaces
come in the form of cooperating circuits and software procedures (I/O
drivers) embedded in the synthesized implementation. Communication can
be through I/O ports available on the microcontroller or general memory-
mapped I/O.
2.7 System Integration
Once the hardware synthesis and software compilation phases are complete,
the next step is to integrate both hardware and software components. One pos-
sibility is to use a prototyping system consisting of general-purpose processor
assisted by application-specific hardware (Ernst and Henkel, 1992; R. Ernst
and Benner, 1993; Gupta, 1993; R. K. Gupta and Micheli, 1992a; R. K. Gupta
and Micheli, 1992b; R. K. Gupta and Micheli, 1994; Gupta and Micheli,
1992; Gupta and Micheli, 1993). Another possibility is to use a reconfigurable
system, for the hardware component, and a computer system, for the soft-
ware component. It is also possible to use a framework, such as PTOLEMY
(Kalavade and Lee, 1992; Kalavade and Lee, 1993), in order to implement
co-simulation and verify the performance of the co-design system. In each
of these approaches, the performance results obtained during the system in-
tegration phase may be used to change the system partitioning, if the initial
constraints, such as speed, cost and logic size, are not satisfied.
In PTOLEMY, the SDF domain supports simulation of algorithms and also
allows functional modeling of components, such as filters. The Thor domain
implements the Thor simulator, which is a functional simulator for digital hard-
ware and supports the simulation of circuits from the gate level to the behavioral
level. Thor, hence, provides PTOLEMY with the ability to simulate digital
components ranging in complexity from simple logic gates to programmable
DSP devices. The mixed-domain simulation is executed, using the components
synthesized so far. POLIS (F. Balarin, 1997) uses PTOLEMY as a simulation
engine.
Another example of simulator is POSEIDON, used by (R. K. Gupta and
Micheli, 1992a; R. K. Gupta and Micheli, 1992b; R. K. Gupta and Micheli,
1994) which performs concurrent execution of multiple functional models
implemented either as a program or as application-specific hardware. Input to
POSEIDON consists of gate-level descriptions of theASIC hardware, assembly
code of the software and a description of their interface. The system specifi-
cation is written using model declarations, model interconnections, communi-
cation protocols and system outputs. The interface protocol for data-transfer
between models is specified via guarded commands. The gate-level description

Figure 2.4. Target architecture with parameter memory in the coprocessor
of the hardware component is generated using structural synthesis techniques
provided by the OLYMPUS synthesis system (G. De Micheli andTruong, 1990).
The first version of the development board presented in (M. D. Edwards,
Forrest, 1996a; Edwards and Forrest, 1996b) comprised of a processor, system
memory, input/output section, custom hardware andAT bus interface. The cus-
tom hardware consisted of a parameter memory, a dual-port controller and the
coprocessor, which implemented the synthesized hardware function, as shown
in Figure 2.4. The dual-port controller was responsible for the communica-
tion between the coprocessor internal bus and the system bus, during parameter
passing. Parameters were transferred between the coprocessor parameter mem-
ory and the system memory as either 16-bit integers, pointers or data arrays,
using Direct Memory Access (DMA).
In the present version (Edwards and Forrest, 1995; Edwards and Forrest,
1996a), described in Chapter 3 with more details, parameters are transferred
directly to the coprocessor as either 16-bit integers or pointers, as can be seen

System Integration 25
Figure 2.5. Target architecture with memory-mapped parameter registers
from Figure 2.5. Data arrays are kept in the system memory and only their
pointers are passed to the coprocessor. The coprocessor bus interface con-
tains memory-mapped registers for configuring and controlling operation of
the coprocessor.
Another example of a development board is the HARP reconfigurable com-
puter (Hoare and Page, 1994a; Hoare and Page, 1994b; de M. Mourelle, 1998;
Page, 1994; Page, 1995; Page and Luk, 1993), a computing platform developed
at Oxford university. It consists of a 32-bit RISC microprocessor, with 4MB
DRAM, closely coupled with a Xilinx FPGA processing system with its own
local memory. The microprocessor can download the hardware configuration
into the FPGA via the shared bus.
The target architecture used in (Ernst and Henkel, 1992; R. Ernst and Benner,
1993; Gupta, 1993; R. K. Gupta and Micheli, 1992a; R. K. Gupta and Micheli,
1992b; R. K. Gupta and Micheli, 1994; Gupta and Micheli, 1992; Gupta and
Micheli, 1993) consists of a general-purpose processor assisted by application-
specific hardware components (ASICs), as shown in Figure 2.6. The hardware
modules are connected to the system address and data busses. Thus, all commu-
nication between the processor and the other hardware modules takes place over
a shared medium. The re-programmable component is always the bus master.
Inclusion of such functionality in the application-specific component would
greatly increase the total hardware cost. All the communication between the
re-programmable component and theASIC components is achieved over named
channels, whose width is the same as the corresponding port widths used by
read and write instructions in the software component. The re-programmable
component contains a sufficient number of maskable interrupt input signals.
These interrupts are un-vectored and there exists a predefined unique destina-
tion address associated with each interrupt signal.

Figure 2.6. Target architecture using a general-purpose processor and ASICs
Computer designers can connect the gates of FPGAs into an arbitrary sys-
tem merely by loading the chip’s internal RAM with configuration data. By
combining FPGAs with external RAMs, microprocessors and digital signal
processors, designers can create a Reconfigurable System (RS). Plugged into
a standard PC, the reconfigurable system would perform functions normally
performed by special-purpose cards. Such an arrangement has the following
advantages:
faster execution – since FPGAs operate at circuit speeds, they can compute
much faster than pure software functions; however, their wiring and logic
delays make them slower than equivalent mask-programmed gate array s or
ASICs;
low cost – an RS is much cheaper for each new application than an ASIC;
configuring an RS for a new task requires that the PC user reprograms the
connections of the logic gates in each FPGA;
low power, small volume – one RS can take over the non-concurrent func-
tions of several dedicated, special-purpose cards, reducing the size and
power consumption of the PC system;
increased innovation – because reconfiguring an RS is similar to loading
a new software program, the costs of creating a new system will be much
lower.
These reconfigurable systems can be used as testbeds for co-design, pro-
viding a board for implementing the hardware component, along with the
means for communicating with the software component. Examples of testbed

Summary 27
implementations are SPLASH (M. Gokhale, 1991), ANYBOARD (D. E.
Van den Bout, 1992), Rasa Board (D. E. Thomas and Schmit, 1993) and the
multiple-FPGA-based board presented in (Wendling and Rosenstiel, 1994).
2.8 Summary
In this chapter, we introduced the co-design approach. Then, the co-design
methodology was outlined by describing each of the steps involved, together
with recent work in this area. In the next chapter, we will discuss the co-design
system developed at UMIST, along with experimental results obtained.

Notes
1 Application Specific Integrated Circuits.
2 SDF stands for Synchronous Data Flow.
3 CPLD stands for Complex PLDs.

Chapter 3
THE CO-DESIGN SYSTEM
The purpose of hardware/software co-design is to engineer systems con-
taining an optimum balance of hardware and software components, which
work together to achieve a specified behavior and fulfill various design cri-
teria, including meeting performance targets (Wolf, 1994). A general-purpose
co-design methodology should allow the designer to progress from an abstract
specification of a system to an implementation of the hardware and software
sub-systems, whilst exploring tradeoffs between hardware and software in
order to meet the design constraints. A co-design environment provides soft-
ware tool support for some, or all, of the co-design operations and may include
an integrated development system consisting of a microcomputer or micro-
controller and programmable hardware for system prototyping purposes.
The co-design in this book concentrates on the realization of hardware/
software systems where the primary objective is to enhance the performance of
critical regions of a software application, characterized as a software approach
(Edwards and Forrest, 1994; Edwards and Forrest, 1995; Edwards and Forrest,
1996b). In our case, a critical region is part of an application where either
a software solution cannot meet the required performance constraints, and a
hardware solution must be found, or the overall performance can be usefully
accelerated by implementing that region in hardware. In order to produce viable
hardware/softwaresystems, wehavecreatedadevelopmentenvironment, which
supports the co-synthesis and performance evaluation of such systems.
An application is firstly implemented as a C program and identified criti-
cal regions are synthesized automatically for implementation in a field pro-
grammable gate array (FPGA).
29

30 The Co-design System
3.1 Development Route
The development route consists of a sequence of stages for the translation
of a C source program into machine code for a microcontroller and FPGA con-
figuration data, as shown in Figure 3.1, following the co-design methodology
presented in Section 2.4.
Profiling consists of identifying performance critical regions in the C source
program. The Amdahl’s law (Amdahl, 1967) can be employed to determine the
performance gain that can be obtained by implementing these critical regions
in hardware. It states that “the performance improvement to be gained from
using some faster mode of execution is limited by the fraction of the time the
faster mode can be used” (Amdahl, 1967). The speedup that can be gained
corresponds to the ratio in (3.1).
speedup =
execution time of software-only implementation
execution time of software/hardware implementation
(3.1)
As presented in (Edwards and Forrest, 1996b), the overall speedup of an
application Shs can be defined as in (3.2)
Shs =
Ssc
1 + µ(Scs − 1)
(3.2)
wherein Scs corresponds to the speedup obtained by executing the critical region
in hardware and µ to the fraction of the computation time in the software imple-
mentation that is not enhanced by the hardware implementation. As Scs tends to
infinity, the overall speedup Shs obtainable becomes inversely proportional to µ.
Therefore, the overall speedup increases as the frequency of use of the software
implementation that is enhanced by the hardware implementation increases.
This provides a good design trade-off in selecting potential critical regions for
hardware implementation.
Hardware/software partitioning consists of translating performance critical
regions in the C source program into a hardware description for input to a
hardware synthesis system. The identified C source code for a region is adapted
toimplementa“hardware”call/returnmechanism, whichinvokestheassociated

Development Route 31
Figure 3.1. Development route
operations in the FPGA. The modified C source program is, then, prepared for
compilation.
During hardware synthesis, the hardware description of a critical region is
synthesized, through a series of synthesis tools, into a netlist for the specific
FPGA. The configuration data is, then, translated into an initialized C array.
Software compilation stage accepts the modified C source program and trans-
lates it into machine code to be executed by the co-design system.
The run-time system consists of the necessary hardware to download the
modified C code into the development hardware, execute it and return perfor-
mance statistics.
3.1.1 Hardware/Software Profiling
Hardware/software profiling permits the identification of performance crit-
ical regions in the C source program. Deterministic, accurate timing analysis
has been used to estimate program execution time against bounds in real time
systems (Park and Shaw, 1991; Shaw, 1989). Knowledge about the dynamic
behavior of the programs have also been used to estimate their performance
(J. Gong and Narayan, 1993; Narayan and Gajski, 1992).

32 The Co-design System
In a first approach (Edwards and Forrest, 1994; Edwards and Forrest, 1995;
Edwards and Forrest, 1996a; Edwards and Forrest, 1996b), the profiling soft-
ware is PC-based and critical regions are identified interactively and can be
either single functions or sequences of statements within a function. Perfor-
mance statistics for a program and selected regions can be readily obtained by
compiling and executing the code. Critical regions are identified by running
the program with representative data. The performance information is acquired
by the run-time system using timers of the development system hardware. The
current values of a timer are read when the profiled region is both entered and
exited. The profiling system temporarily modifies the original code, so that
“time stamps” can be used to indicate entry and exit times from the regions
selected by the user. The time stamps are generated by the hardware timers of
the system hardware. Figures of the minimum, maximum and average execu-
tion times for a selected region, together with the number of times the region is
executed, are computed and stored in the system memory of the development
hardware. From this information, it is possible to ascertain where a program
spends most of its time and, hence, which regions could benefit from software
acceleration. At this stage, we naively assume that the execution time of a
program is determined and does not depend on any asynchronous activities.
We are, however, experimenting with a “statistical” form of profiling, where
the value of the program counter of the microprocessor is sampled at random
intervals. This allows us to determine the dynamic execution characteristics of
a program and is useful for profiling interrupt-driven applications.
In another approach (Nikkhah, 1997; B. Nikkhah and Forrest, 1996), the
selection of candidate functions is performed automatically, based on profiling
data. Functionsaretheunitoftranslation, butdesignerscanreadilyrewriteother
regions as functions. A hybrid static/dynamic policy for timing assessment is
adopted, where the duration of each “basic block” in a program is estimated
statistically for a particular processor. Program regions are compared by their
relative timing characteristics. The program is run in a workstation environment
and the estimated times of the executed basic blocks are summed up to give an
estimated time for the program on the target environment. In a C program, basic
blocks are identified by noting the occurrences of “for”, “while”, “do”, “if” and
switch constructs. Constructs such as “break”, “continue” and “return” may
denote the end of these blocks. The basic block execution time is estimated
using the source code on an instruction-by-instruction basis. The estimation is
independent of the processor on which the source program is executed. The
processor dependent timing data, extracted from the manuals in clock cycles,

Development Route 33
is held for each basic operation of a C instruction. profiling and software
timing estimation is done without executing the source program on the target
architecture.
In (Nikkhah, 1997; B. Nikkhah and Forrest, 1996), after the selection of
candidate functions based on the software timing estimation, the area size est-
imation is performed. This allows the designer to eliminate those candidates
that do not satisfy the area constraint.
3.1.2 Hardware/Software Partitioning
Partitioning (Edwards and Forrest, 1994; Edwards and Forrest, 1995;
Edwards and Forrest, 1996a; Edwards and Forrest, 1996b) consists of
translating the C code of a critical region into VHDL, in order to enable high-
level hardware synthesis of the identified region. The C source code of the
critical region is adapted to implement the parameter passing and a “hardware”
call/return mechanism, which invokes the associated operations in the FPGA.
The implemented protocol consists of:
parameter passing from the processor to the hardware sub-system;
instigating the function in the FPGA;
waiting until the hardware sub-system completes the operation, which
depends on the interface mechanism adopted;
accessing parameters returned by the hardware sub-system.
The partitioning tool (Wright, 1997) generates a VHDL behavioral descrip-
tion of the critical region, as well as the adapted C source program. Special-
purpose hardware/software interface logic is generated automatically to
implement the transfer of parameters and control between the two sub-systems,
which is embedded in the VHDL description. An example of the application of
this tool is provided in Appendix A.
3.1.3 Hardware Synthesis
The hardware synthesis tool is UNIX-based. It accepts the VHDL code
for a critical region, generated by the partitioning tool, and produces the logic
network for a Xilinx FPGA XC40xx . During this phase, different tools are
used according to the type of output required, as described in Figure 3.2.
Optimization. The VHDL behavioral description of a critical region may
follow a structured programming style, i.e., include procedures and functions.
This may yield a very large synthesis space. In order to be able to handle such
a large space, high-level synthesis tools impose some constraints on the type
of hardware description that can be handled, i.e., the synthesis tool may not
support record types, some kind of “loop” statements (“loop . . . end loop”),

Random documents with unrelated
content Scribd suggests to you:

olisi lauennut. Veritulva ruiskahti ukon kyljestä. Huudahtaen:
»Lempo teidät vieköön!» vaipui Jeremias hiljaa maahan.
Nyt tuli Hannun ja Sannan tila vielä entistä vaarallisemmaksi.
Pyssyn laukaus kaikui metsässä. Ampuja kirosi julmasti iloiten.
Seuraus laukauksesta ja ampujan huudosta oli, että toisetkin
viholliset tännepäin kiirehtivät.
Nyt valmisti Hannu itseään kuolemaan; sillä nyt oli hänestä hänen
turvapaikkansa vallan turvaton. Mutta usein, kun hätä on suuri, on
odottamaton apu lähellä. Ampuja tosin käveli paikalle, missä ukko oli
kaatunut, mutta varovammasti kuin ennen kulki hän nyt. Hän pelkäsi
nähtävästi väjyjiä jokaisessa pensastossa. Kun hän huomasi
toverinsa olevan elossa ja jo pystyssä ja luuli ukko Jeremiaksen
kuolleeksi, ei ollut hänellä mielestänsä mitään enää täällä tehtävää.
Ennen lähtöään antoi hän kaatuneelle ukolle aika potkauksen,
silmäili epäileväisesti ympärilleen ja läksi kiroilevan toverinsa kanssa,
joka ukon iskuista oli vähin tyrmistynyt, varovasti palavaa taloa kohti.
Kun menevien äänet kuuluivat yhä etäämmältä, silloin vasta
uskalsivat Hannu ja Sanna nousta piilostaan. Hiljaa kulkivat he
kaatuneen ukon luo.
»Tätä työtä et ole ilmaiseksi tehnyt, venäläinen, jos minä vaan
kostaa voin; sen lupaan ja vannon kautta Jumalan!» puhui Hannu ja
nosti hiljaa ukkoa kantoa vastaan.
Mutta nyt hämmästyi nuorukainen, ja samassa leimahti ilon hohde
hänen silmistänsä. »Sinäkö se olet?» sanoi kuolleeksi luultu hiljaisella
äänellä.

»Jumalan kiitos, hän elää! Mutta kuinka verissään!» oli Sannan
vastaus.
Verissä oli ukko; mutta juuri veritulvaansa tuli hänen arvattavasti
kiittää siitä, että hän vielä hengissä oli. Kun hän tunsi luodin
sattuneen kylkeensä, oli hän ilman omaa tahtoansa kaatunut. Mutta
tyrmistyksiin hän ei tästä kumminkaan vaipunut. Hän päätti olla
olevinaan kuolleena, sillä vastarintaa tehdä oli hänelle nyt mahdoton,
sen havaitsi hän.
Ja taasen nousi nuorten ja ukon välillä kysymys: »Mitä nyt on
tehtävänä?» Mutta nyt oli Sannan vuoro vastata:
»Ensiksi on ukko Jeremiaksen haava sidottava, jottei veri pääse
kuiville juoksemaan».
»Aivan niin; se on ensimäinen työ!» vastasi Hannu. Ja nyt koetti
hän varovaisesti riisua takkia ukon yltä. Mutta jos ukko olikin maassa
maatessaan vähemmässä määrässä tuntenut haavansa kipua, niin
hän nyt, kun häntä liikutettiin, parahti kovasti.
»Hiljaa, Jumalan tähden!» puhui Sanna pelästyneenä. »Se on
minun työni! Johonkin minäkin kelpaan». Ja naisen aistilla riisui hän
takin ukon yltä, niin varoin, niin hiljaa, että vaikka ukko oli
tuskissansa, hän kumminkin saattoi huutoansa pidättää. Sitten
rievuilla ja reduilla, mitkä käsillä olivat, koetti Sanna veren tulvaa
estää. Ja tässä työssään onnistui hän, vaikkei täydellisesti,
kumminkin niin, että ukko, tosin heikkona ja horjuen, voi pystyyn
nousta.
Näitten seikkojen tapahtuessa oli päivä ehtoolle kulunut ja ehtoo
alkanut yöksi muuttua. Pohjolan yö, kesäinen yö on kaunis ja

lämmin. Aurinko, joka ei pitkäksi aikaa levolle laskeu, valaisee
hohteellaan sitä. Mutta kumminkin, kun jo kesäsydän on kulunut ja
päivät yhä lyhetä alkavat, vallitsee, kun aika syksylle kuluu, öisin
aina yhä enemmän tummeneva hämäryys. —
Hiljainen vaalea yö, joka jo hämäryyden rajoja lähestyi, ympäröitsi
pakenioita, kun he metsässä seisoivat, haavoitettu keskuudessaan.
Ei savua eikä tulta enää näkynyt Myrrältä. Ilma oli tyyni, lehti puussa
ei liikkunut; ylentävä hiljaisuus asui luonnossa. Tämä — yön
hiljaisuus — saattoi kummallisen, oudon, viehkeän tunteen
pakolaisten sydämiin, tunteen, joka sai heidät laskeumaan polvilleen
nöyryydessä kiittämään Luojaa kummallisesta pelastuksesta. Pelko
oli heidän rinnoistansa poistunut ja ajatteleva järki ottanut sijansa
heidän sydämissään. Mutta kumminkin asui näissä sydämissä
kostonpyyntö, vaikka ei nyt enää kuitenkaan se kostonhimo, joka
vihan innossa ei tiedä muuta kuin miten pahalla pahaa palkita.
Torppaan, missä Hannu isänsä ja sisarensa kanssa asui, oli toista
virstaa. Sinne päin alkoivat pakolaiset astua. Hiljaisesti, hitaisesti kävi
kulku. Hannu talutti ukkoa, Sanna kulki heidän jälessänsä. Monta
sanaa ei tiellä vaihdettu; kullakin oli itsellään kylläksi ajattelemista, ja
mitä Hannun hiljaisissa ajatuksissa nyt päätökseksi kypsyi, se on
kohta nähtävä. Sannaansa ja haavoitettua vanhusta hän ei tahtonut
jättää, muuten olisi hän ehkä heti pannut tuumansa täytäntöön.

Maantien yli olivat pakolaiset päässeet, päässeet jo vähän matkaa
polkuakin, joka vei Hannun kotiin, kun ukko julmasti ärjäsi. Kuivunut
oksa oli koskenut hänen haavoitettuun kylkeensä, oli siirtänyt tukon,
joka haavaa peitti, oli saanut veren uudestaan vuotamaan. Siinä
täytyi pakolaisten seisahtua. Sanna sitoi uudestaan ukon haavan, ja
nyt kantoi Hannu vanhusta. Näin kävi kulku nopeammasta, ja vähän
jälkeen keskiyön olivat vaeltajamme perillä metsätorpassa. —
Sanna kiirehti sisälle. Torpassa ei ollut ketään. Autioksi oli se
heitetty. Vanhus — Hannun isä — ja Hannun nuori sisar olivat
kadonneet.
»Olisiko heitä onnettomuus kohdannut?» Tämä oli Hannun
ensimäinen surullinen miete, kun hän huomasi isänsä ja sisarensa
poissa olevan. »Olisivatko he lähteneet kylään ja siellä joutuneet
vihollisten käsiin?»
»Sitä en usko», sanoi Jeremias. »Erkki on liian kivuloinen kyliä
käymään, ja Priita, sisaresi, ei ole ukkoa heittänyt. Luultavasti ovat
he metsään hiipineet».
»Täällä olisivat kumminkin olleet hyvässä tallessa», puhui Hannu.
»Polku tänne on aivan kaita ja tuntemattomalle tuskin näkyvä.
Tänne
eivät viholliset osaa, täällä eivät ole käyneetkään, eivätkä käy.
Siis…»
Hannu ei enää jatkanut. Hän loi silmänsä Sannaan, ja
kummallinen, hellä tunne katkaisi hänen puheensa.

Sanna näki, että Hannulla oli jotakin mielessä, jotakin, jota hän ei
suoraan rohjennut sanoa. Hän katsoi vakavasti sulhoonsa ja kysyi:
»Siis, mitä aiot tehdä? Jotakin liikkuu mielessäsi».
»Siis on minun meneminen heitä etsimään», lausui Hannu.
»Jääkää te tänne siksi aikaa! Pitkiä aikoja minä en viivy».
Hannun kasvot olivat rauhalliset. Sanna ei osannut aavistaakaan,
mitä Hannun mielessä liikkui. Hän oli kumminkin juuri avata suunsa
pyytääkseen, ettei Hannu heitä jättäisi, kun tämä lisäsi:
»Jos on isäni ja sisareni metsään kätkeyneet, niin kauas eivät he
ole menneet, sillä rakas on heille tämä paikka. Laita sinä, Sanna
valkea ja keitä ruokaa; vielä on vähän vakassa jauhoja liemeen. Minä
pian palaan. — Kaikissa tapauksissa pysykää täällä, kunnes minä
tulen takaisin!»
Hannu lausui nämä sanat niin rauhallisesti, niin luottavaisesti, ettei
osannut Sanna ja vielä vähemmin ukko häntä menemästä kieltää. —
»Mene, mutta tule pian takaisin!» sanoivat he lähtevälle.
Hannu meni; hän lähti metsään päin polkua kulkemaan. Sanna
seurasi häntä silmäyksillään niinkauan kuin hän näkyvissä oli. Sitten
valmisti hän ukolle vuoteen ja rupesi tulta ahjoon laittamaan, tahi
paremmin tulta virittämään, sillä kyteviä hiiliä löysi hän tuhan alta.
Hannu oli polkua metsään päin lähtenyt kulkemaan. Hänen
muotonsa, kun hän läksi, oli ollut niin rauhallinen kuin entisinäkin
aikoina, joina hän kirves olalla tätä polkua kulki kaskea hakkaamaan.
Mutta tuskin oli hän kääntynyt selin kotiinsa, ennenkuin hänen
kasvonsa saivat toisen muodon. Kummallinen loiste hohti hänen

silmistänsä, ja hiljainen huokaus: »Näenkö Sannaa ikänä?» nousi
hänen rinnastansa.
Kulettuaan niin pitkälle metsäpolkua, ettei häntä enää sopinut
mökin ympäristöltä nähdä, poikkesi hän äkkiä vasemmalle; sitten
kiersi hän mökin ympäri metsän suojassa ja seisoi pian polulla
taasen; mutta nyt seisoi hän kylään päin. Jo arvaat, lukiani, mikä
hänellä oli mielessä. Isäänsä ja sisartaan hän ei lähtenyt metsästä
hakemaan, vaikka hän, kun arveli niiden sinne paenneen, ei
valehdellut. Sanna oli hänelle kalliin maailmassa, vaikka ei hän
ymmärtänyt eikä paljon ajatellutkaan, kuinka kallis hänelle
morsiamensa oli. Sannan tahtoi hän ensin saada rauhalliseen
turvapaikkaan, ennenkuin uskalsi tehdä, mitä sydämensä hänelle
käski. Nyt oli Sanna suojapaikan löytänyt. Hän itse, Hannu, oli
pienellä valheella päässyt vastuksetta lähtemään. Hän oli tästä
mielissään.
Hän kulki hiljaa ja varovasti. Hänellä oli aseena kirves kädessään.
Sen oli hän kotoansa ottanut. Sanna sen kyllä hänellä näki, mutta ei
sitä ensinkään kummastellut. Yön hiljaisuus vallitsi vielä; linnutkin
oksilla nukkuivat, kulkian askeleet eivät niitä herättäneet.
Näin tuli hän maantielle; hän seisahtui tien syrjään ja silmäili
ympärilleen. Ei mitään pelättävää näkynyt eikä kuulunut. Hiljaa kulki
hän Myrrälle päin. Talo oli poroksi palanut. Viimeiset hirret kytivät,
samaten kuin vanha pölkky nuotiossa, jonka ympärillä viholliset
päivällä olivat istuneet lehmänpaistia syöden. Mutta nyt vihollisia ei
näkynyt eikä kuulunut missään. Hannu ihmetteli, ja kummallinen
kammo täristytti hänen ruumistaan, kun hän surmatun Ollin
ruumiilliset jäännökset näki. Vähän aikaa katseli hän talon raunioita,

sitten lähti hän kulkemaan Kauniaisten kartanolle. Entistä vielä
varovaisemmasti kulki hän nyt. Ja syytä olikin hänellä siihen.
Noin kivenheittämän talosta seisahtui hän äkkiä. Pian ihan hänen
vieressään puuta vastaan nojaten, selin häneen päin, näki hän
vihollisen. Nukkuiko tämä, oliko hän valveilla, sitä ei Hannu tiennyt.
Mutta että vihollinen tähän oli pantu vartiamieheksi, sen hän
ymmärsi. Silmänräpäyksen aikaa seisoi Hannu miettien. Vihan vimma
sai hänessä taasen vallan. Hiljaa hiipien lähestyi hän vartiaa, ja nyt
huomasi hän, että tämä oli uneen vaipunut ja että hän kannolla istui.
Rohkeammasti lähestyi Hannu, nosti kirveensä ja — äänettä vaipui
vartia ijankaikkiseen uneen.
»Olisi meitä kymmenkunta miestä, niin työmme onnistuisi!»
mumisi hän korjaten kaatuneelta hänen aseensa.
»Mutta nyt!»
Toinen olisi ehkä tähän salamurhaan tyytynyt. Niin ei ollut Hannun
laita. Toinen olisi ehkä nyt paennut. Hannu astui hiljaa kartanoa yhä
lähemmäksi. Itse kartano on jotenkin korkealla mäelle, jolta näkyala
on varsin ihana ja kaunis — josta sen nimikin. Kukkulan törmä
puistoineen esti kenenkään näkemästä Hannua, jos olisi näkiää ollut.
Hannu pääsi ihan pihaa ympäröiväin huoneiden taakse. Täältä
huoneiden välistä sopi hänen nähdä, miten pihalla oli asiat. Keskellä
sitä oli nuotio, joka oli sammumaisillaan; sen ympärillä makasi
joukko vihollisia, mikä päin, mikä jaloin tulta kohden, ja kaikki
näkyivät lepäävän syvimmässä unessa. Hannun sydän tykytti entistä
kovemmin. Jos hän yksin näitä vastaan rupeisi taistelemaan, olisi
hänen kuolemansa varma. Ja kumminkin… Kuta enemmän aikaa hän
kujastansa makaavia katseli, sitä enemmän kohosi hänen intonsa,
hänen halunsa antautua epätasaiseen tappeluun. Kiväärit olivat

pystytetyt toisiansa vastaan vähän matkaa nuotiosta. Jos hän
hiljaisuudessa voisi varastaa pois piikivet, niin eivät pyssyt hänelle
vahinkoa tekisi.
Tuskin oli tuo ajatus johtunut hänen mieleensä, ennenkuin hän jo
oli päättänyt. Kirves kädessä astui hän hiljaa, varovasti pihalle, hiipi
kiväärien luo ja ryhtyi työhönsä. Maassa maaten, kirves vieressään,
pakoon valmiina, aina tuon tuostakin luoden silmänsä nukkuviin
askaroitsi hän. Kolmessa kohden oli nuotion ympärillä kiväärejä
pystytetty, kolme kussakin kohdassa. Suurella vaivalla oli hän jo
kuusi kivääriä, piikivet niistä ottamalla, tehnyt vahingoittamattomiksi.
Hänen kyntensä olivat nyt kuluneet, hänen sormensa päät veressä.
Hän ei enää voinut jatkaa; piikivet istuivat lujassa. Silloin ei ollut
hänellä neuvoa muuta kuin kaataa pois sankkiruuti vielä jälellä
olevista. Mutta silloin huomasi hän, mitä hän ei ennen ollut
huomannut. Kiväärejä oli useammissa kohdin. Kujastansa ei hänen
sopinut nähdä muuta kuin puoli pihaa. Nyt huomasi hän
asuinhuoneen seinää vastassa olevan useampia ja ymmärsi samassa
vaivansa turhaksi.
Toinen olisi ehkä tähän tyytynyt ja nauraen miettinyt venäläisten
kummastusta, kun he herättyänsä piikivet kadonneiksi huomaisivat.
Hannu ei sitä ajatellut. Hän oli nyt kerran intoon joutunut. Hän,
vaikka yksin, oli tullut miehuullisemmaksi, kun havaitsi, miten
sikeässä unessa viholliset nukkuivat. Hän nousi ja lähestyi tuskin
hengittäen nuotiota. Siinä tunsi hän miehen, joka Jeremiasta oli
ampunut, ja nyt ei hän enää omaa vaaraansa miettinyt. Mies makasi
jalat nuotioon päin selällänsä. Hänen luoksensa kulki nuorukainen.
»Sinulle minä ainakin annan passin», mumisi hän, ja kuten rankaa
ennen metsässä, iski hän voimainsa takaa miestä kirveen terällä
päähän.

Mutta jos oli vartiamies äänettä kuollut, niin tämä ei. Ennenkuin
hän päivänsä lopetti, ennätti hän kertansa ärjähtää ilkeästi, josta
hänen vieressänsä makaavat toverit puoleksi heräsivät.
Jos nyt Hannulla olisi ollut vähänkään malttia, jos hän olisi
moniaita silmänräpäyksiä odottanut, niin, ken tietää, miten olisi
hänen työnsä onnistunut; mutta kun innostunut nuorukainen
kuolevaisen ärjähdyksen kuuli, luuli hän itsensä huomatuksi, luuli
väestön heränneeksi ja päätti surmata niin monta kuin
tyrmistyneistä, unenhorroksissa olevista ennätti. Kiireesti repäisi hän
kirveen kuolleen päästä, mutta kohta kolauttaakseen sillä toista.
Kolme oli pihalla täten surmansa saanut, ennenkuin muut ehtivät
jalkeille. Vielä kahteen koski kipeästi kirveen terä, ennenkuin
nuorukainen näki parhaaksi paeten hakea pelastustansa. Miten hiljaa
hiipiväisesti hän pihalle oli tullut, yhtä kiireesti rientäen pyrki hän
sieltä pois. Ja kiire nyt olikin. Sillä jo ennenkuin hän oli kujaan
ehtinyt, kuuli hän takanansa kiväärinlukkujen räiskeen, vaikka ei siitä
mitään kummempaa seurannut.
Kujan toisessa päässä oli vähäinen kivi. Kun Hannu kujaa äsken
hiipi, ei hän sitä huomannut. Nyt paetessansa astui hän sille. Se
keikahti, ja kirves kädessä makasi nuorukainen maassa. Vasemman
käsivartensa oli hän pahasti loukannut. Mutta vaikka hän samassa oli
jalkeilla taasen, oli tämä lankeemisensa kumminkin häntä viivyttänyt
niin paljon, että hän joutui takaa-ajajain käsiin, kun hän kääntyi
puolustaakseen itseänsä. Mihin oli poika parka turvautunut, kun hän
tähän vaaraan antausi? — Sitä on vaikea sanoa. Hän oli ehkä luullut
pääsevänsä pakoon, ennenkuin uniset miehet ennättivät tointua, ja
jos tointuivatkin sitä ennen, niin — mutta arveluille emme rupea.
Jumala tiennee, ajatteliko poika parka mitään muuta kuin kostoa,

karatessaan yksin kymmenien päälle. Vähältä puuttui, ettei hän
onnistunut. Mutta vähästä paljon riippuu, ja hänen vähästään se,
että hän nyt oli surmattujen toverien vallassa.
Mitä tekevät viholliset hänelle? Surmaavat hänen paikalla, hirttävät
hänen, polttavat hänen tulisessa nuotiossa?
Moni muu syyttömämpi on tässä hirmuisessa sodassa saanut
tällaisen ja vieläpä hirmuisemman surman.
Iloiten ja riemuiten toivat viholliset hänen pihalle. Siellä oli nyt
asema toisellainen kuin ennen. Kaikki olivat nyt jalkeilla. Ei
ainoastaan ne, mitkä nuotion ympärillä lepäsivät, vaan myöskin ne,
jotka huoneissa olivat majaelleet ja joiden kiväärit Hannu oli seinää
vasten pannuiksi nähnyt, olivat pihalla. Niiden seassa huomasi
Hannu pari upseeriakin.
Töyttimällä ja potkimalla vietiin nuorukainen näiden luo.
Kun Hannu huomasi, ettei hänellä ollut muuta kuin kuolema
odotettavana, tuli hän tästä varmasta tiedosta, jos mahdollista oli,
vielä entistä rohkeammaksi. Hän katseli vakavilla silmäyksillä
ympärilleen, ja ilvehymyyn vetäysivät hänen huulensa, kun hän
huomasi useain venäläisten kummastellen kaipaavan piikiviään.
Mutta pitkää tarkastuksen aikaa ei hänelle suotu, ennenkuin hänen
tuli vastata teoistaan, ja ettei tämä vastaaminen ollut leikintekoa,
huomasi hän ympärillänsä seisovain sotilaiden riemuitsevista
kasvoista. — Mutta kumminkin tapahtui, ennenkuin häntä
vastaamaan käskettiin, tapauksia semmoisia, ettei Hannu tiennyt,
mitä hänen tuli ajatella. Niin kummallisilta näkyivät ne hänelle.

Väen päällikkö ei kääntynyt puheellansa Hannun, vaan erään
sotilaan puoleen, ja kiivaalta ja kovalta näytti hänen katsantonsa.
Hän puhui muutamia sanoja, joita ei Hannu ymmärtänyt; mutta että
upseeri sotilaille antoi joitakuita käskyjä, sen huomasi hän kohta.
Laumasta erkausi kaksi ja lähti pihalta metsään päin. Samassa
tarttuivat toiset siihen sotilaasen, jota upseeri ensinnä oli puhutellut,
ja huolimatta hänen armonpyynnöistään, heittivät he hänen
maahan, ja nyt alkoivat he onnetonta kurittaa raakalaisten
raaimmalla tavalla. Säästän lukiani tunteita, kun heitän kertomatta
tämän julman kurin laatua. Sanottakoon vaan se, että kun oli
vaivainen saanut kurinsa, makasi hän maassa ruumiina.
Tämä oli jotakin outoa, odottamatonta Hannulle. Jos olisi kurin
laatu ollut toisellainen, jos vaivainen kohta olisi kuoliaaksi ammuttu,
olisi se ehkä ollut Hannulle mieleenkin, sillä yhtähän se oli, kuka
hänen vihollisensa surmasi; mutta nyt tätä julmaa menetystä
nähdessään ummisti Hannu silmänsä, ja inho anasti vihan sijan
hänen rinnassaan.
Mutta minkätähden tämä julma kuri tuli vaivaisen osaksi? Voimme
vaan arvelulla vastata siihen. Ja arvelumme kuuluu näin: Tämä
sotilas raukka oli pantu kartanoa vartioitsemaan, ja hän oli, kuten
muutkin sotilaat, nuotion viereen nukkunut. Siinä hänen rikoksensa,
joka tuotti hänen kolmelle toverillensa surman.
Että tämä oli onnettoman rikos, näkyi siitäkin, että sillä aikaa, kun
hän tuskissansa väänteli itseään, toivat ne, jotka upseerin käskystä
olivat metsään päin vetäytyneet, etuvartian ruumiin pihalle.
Viisi henkeä oli siis tämä Hannun salainen ryntäys vihollisille
maksanut. Nyt — nyt tuli hänen vuoronsa!

Sotilaat seisoivat valmiina paikalla tottelemaan upseerinsa käskyä.
Mutta tätä käskyä ei niin pian annettu.
Venäläisten joukossa oli eräs, joka osasi suomen kieltä. Tämä
kutsuttiin esille, ja nyt alkoi kummallinen tutkimus.
»Sano hänelle», huusi upseeri tulkille, »että hän elävältä
poltetaan!»
»Minä tiedän sen; mitäpä siitä!» vastasi Hannu; ja tulkki käänsi
hänen sanansa upseerille.
»Sano hänelle, että hän ensin piestään!»
»Vähät siitä! Nuo tuolla olen minä kumminkin surmannut; se on
minun kunniani. Pieskää vaan minua!»
Nuorukaisen vakaa käytös ja jäykät vastaukset vaikuttivat
upseerissa ihan toista kuin läsnäolevat sotilaat olivat ajatelleet. Kun
upseeri oli kuullut Hannun viimeisen vastauksen, jäi hän seisomaan
katsoen pitkään poikaa. Hannu ei tiennyt muuta odottaa, kuin että
seuraava sana upseerin suusta olisi hänen tuomionsa. Hän pani
kätensä ristiin rinnallensa, ja uhkaavilla silmillä katseli hän
tuomariaan.
Kaksi ajatusta näkyi upseerissa taistelevan. Väliin loi hän silmänsä
kytevään nuotioon, väliin kuoliaaksi ruoskittuun sotilaasen päin.
Vihdoin näkyi hän päättäneen. Sanan sanoi hän ja viittasi sormellaan
kenttää. Sanaa ei Hannu ymmärtänyt, mutta mitä sana sisälsi, sen
huomasi hän; sillä samassa tarttuivat lähellä seisovat häneen, ja
voimatta suurta vastarintaa tehdä oli poika parka heitetty kumoon
kentälle.

Hannu arvasi, että sama kuolema, joka vartialle oli osaksi tullut, oli
hänelle määrätty. Ja vaikka hän jo itsekseen oli sanonut jäähyväiset
elämälleen, kävi nyt, kun kuolema oli hänen silmäinsä edessä,
kummallinen, kauhistava pelko hänen sydämensä läpi. Mutta mitä
auttaa pelko kuolemassa! Pelko ei pelasta.
»Nyt tarvitsemme kaikki järkemme», oli Hannu sanonut järvellä
veneissä istuville. Nyt, jos koskaan, tarvitsi hän itse kaiken järkensä.
Nero keinon keksii! Sen sananlaskun tunsi Hannu. Mutta jos
kysytään neroa keneltäkään, niin sitä kysytään siltä, joka
semmoiseen pulaan on joutunut, johon nuorukaisemme tässä, jos on
hänellä mieli semmoisesta pulasta päästä. Väärin sanoisimme, jos
lausuisimme Hannulla olleen tässä tällaista pelastavaa neroa. Mutta
vaikka pahoissa pulissa nero ei itseään tunne, ei ajatusten
perustuksiin nojau, niin, jos sitä kenellä on, se ihmisen itsensä siitä
tietämättä pukeutuu muotoon, tuskissa ikäänkuin irtaupi ja
synnyttää seikkoja, jotka, jolleivat kohta pelasta, kumminkin ajaksi
keskeyttävät tapausten kulun.
Kun Hannu kipeästi tunsi, mikä häntä odotti, kärsi hän sanaa
sanomatta vähän aikaa. Yht'äkkiä huusi hän: »Tätä työtä, te roistot,
ette tee kostamatta!»
Mitä hän näillä sanoilla oli sanovinaan, sitä ei hän itsekään tiennyt.
Kentiesi toivoi hän kostoa siltä isänmaalta, jota hän rakasti, vaikka
tietämättään. Olkoon miten ollee tämän hänen toivonsa laita, näissä
sanoissa oli kumminkin se syntysana, joka hänen eloon palautti. Että
hänen sanansa oli kuultu, sen huomasi Hannu kohta; sillä pyövelit
lakkasivat häntä lyömästä, ja tulkki käänsi hänen sanansa upseerille.

»Mitä näillä sanoilla tarkoitat?» oli kysymys, joka iskujen sijasta
seurasi.
Nyt oli Hannun ajatus saanut suunnan. Hän ei suoraan
kysymykseen vastannut; hän vaan lausui: »Sen sanon, että minun
voitte tappaa yhdellä tahi toisella keinolla; mutta tappakaa vaan,
itsepä sitten näette, kenenkä tapoitte!»
Nämä sanat saivat pitkän keskustelun upseerein välillä. Mutta mitä
siinä keskusteltiin, sitä ei Hannu ymmärtänyt. Että hän oli aiottu
joksikin muuksi kuin uhriksi kuolleiden vihollistensa haamuille, sen
huomasi hän siitä, että hän nostettiin ylös ja että hän vietiin
huoneesen.
Mitä siellä tapahtui, se on kerrottava, koska huoneessa kypsyivät
Hannun äsken syntyneet ajatukset, jotka saivat kertomuksemme
seikat ihan toiselle tolalle. Miksi upseerit luulivat Hannua, se tosin ei
ole tiedossamme; mutta ettei häntä enää niin halpana pidetty kuin
hän todellakin oli, sen huomasi nuorukainen kohta. Hänen hämärät
sanansa ja urhea, peloton työnsä oli tämän vaikuttanut. Hannu älysi
asemansa, vaikka ei aivan selvään, niin kumminkin osaksi.
Täällä nyt koettivat upseerit kaikin päin tiedustella Hannulta
asioita, ja hän tiesikin heille vastata. Mutta aivan paljoa viisaammiksi
eivät viholliset tulleet. Hannu osasi antaa viittauksia semmoisia,
mitkä saivat venäläiset hämmästymään. Ja kun hän kerran oli
sanoillansa ja sanomillansa sen voittanut, oli hän samalla itse voiton
puolella. Upseerit näkyivät unohtaneen, mitkä tuhotyöt hän,
yksityinen, oli aikaan saanut. Pääasialliset tiedot, joita Hannu antoi,
olivat seuraavat:

Suomalaiset olivat tarttuneet aseisin, olivat vannoneet tappaa
jok'ainoan vihollisen. Paikkakunnilla, missä venäläiset olivat käyneet,
oli väki kokoontunut ja salaa alkanut marssia heidän jäljissänsä.
Mouhijärvellä ja Kyrössä oli samaten väki tarttunut aseisin, jotta nyt,
kun venäläiset olivat suomalaisten käsissä, yleinen surma heitä
uhkasi. Siihen lisäksi tiesi Hannu kertoa, että nämä hankkeet olivat
varsin salaisesti toimitetut, jottei venäläisten pääarmeija saisi siitä
vähintäkään tietoa. Sen osan vihollisia, joka nyt Suoniemessä majaili,
sanoi Hannu suomalaisten arvanneen noin pariksi sadaksi mieheksi,
vaikkei hän voinut tätä ihan todeksi vakuuttaa. Näillä tällaisilla
tiedoilla, joita hän vähitellen ja ikäänkuin pakosta jakeli, sai hän
vihollisensa yhä enemmän hämmästymään, varsinkin kun hän lisäsi:
»Puhunko valetta vai totta, sen olette minun äskeisestä
käytöksestäni nähneet. Me olemme vannoneet oman kuolemamme
uhalla kostoa. Ettemme apua hae liittolaistemme paljoudesta, sen
olette te huomanneet. Jokainen meistä on valmis kuolemaan».
Tämä viimeinen puhe suututti kumminkin hirmuisesti toista
upseeria. Paljastetuin miekoin oli hän valmis ryntäämään Hannua
vastaan. Mutta tästä esti häntä toinen, ja pitkä keskustelu alkoi
taasen upseerein välillä. Tämän keskustelun kestäessä ennätti
Hannu taasen miettiä, ja kuta enemmän hän mietti, sitä enemmän
rupesi hän yhä toivomaan omaa pelastustaan.
Vihdoin oli keskustelu loppunut. Mutta tämä oli synnyttänyt
kummallisen esityksen, joka nyt Hannulle tehtiin.
»Elämäsi on meidän vallassamme; mutta me tahdomme armahtaa
sinua, jos sanot, mihin aikaan suomalaisten on aikomus karata
meidän päällemme. Sen lisäksi tulee sinun sanoa, millä tavalla
voimme tätä päälle karkausta välttää».

»Etten minä kuolemata pelkää, sen luulen jo teille näyttäneeni.
Mutta kumminkin, koskei minulle vihollisenkaan kuolema ole
mieleen, jos vaan sitä välttää voin tahdon vastata kysymykseenne.
Kun aurinko on täydelleen noussut taivaalle, silloin pelastakoon
itsensä kuka teistä voi. Vieläpä tahdon lisätä pelastuksen keinonkin.
Teidän hallussanne on suuri kirkkovene ja joitakuita toisia pienempiä.
Paetkaa mannermaalta jollekulle saarelle, niin kauan kuin aikaa on,
ja odottakaa siellä, kunnes suomalaiset ovat ohitse kulkeneet».
Mitä Hannu tällä neuvollansa tarkoitti, lienee varsin vaikea sanoa.
Kentiesi ei ollut hänellä mitään muuta juurta tähän lauseesensa kuin
tämä: »Joka aikaa voittaa, sille voitto koittaa».
Toinen upseereista, sama, joka olisi tahtonut paikalla surmata
Hannun, katsoi häntä kauan epäilevästi: Vihdoin kysyi hän:
»Mikä takaa, ettet sinä petä meitä?»
»Se, että teillä on veneet, että te niillä pääsette minne tahdotte»,
vastasi Hannu.
Tämä vastaus tyydytti nähtävästi epäilevää. Upseerit taasen
juttelivat keskenänsä. Seuraus tästä oli, että muutamia sotilaita
kutsuttiin sisälle ja näille annettiin nyt useita käskyjä, jotka näkyivät
kummastuttavan heitä.
Kun Hannu arveli vihollisten luvun pariksi sadaksi mieheksi, oli hän
erehtynyt. Kuljun ja Kauniaisten tienoilla ei heitä ollut viittä tahi
kuuttakymmentä enempää. Tämä tosiasia, hämmästys ja pelko
saivat upseerit uskomaan Hannun sanoja. He olivat antaneet
käskynsä Hannun neuvon mukaan, olivat aikoneet paeta pois
mannermaalta. Kuljun kirkkovene oli rannassa; rosvot olivat sen

sinne tuoneet. Sillä oli venäläisten aikomus matkustaa. Mutta jos olisi
Hannu ymmärtänyt upseerien kieltä, olisi hän myöskin ymmärtänyt,
että vihollisilla oli aikomus kulkea järven poikki Tottijärvelle päin.
Kauniina nousi aurinko. Taivas oli pilvetön kuten eilenkin, ja ilma
tyyni. Kun upseerit ja Hannu huoneesta palasivat, oli vihollisjoukko
pihalla. Sieltä nyt marssittiin rannalle. Jos Hannu parka luuli
antamainsa tietojen tähden, nyt pääsevänsä vapaaksi, niin siinä
pettyi hän. Kun joukko rannalle lähti, jäi hän seisomaan; mutta pian
huomasi hän, ettei tätä hänelle sallittu. Ja kun hän tämän huomasi
ja näki, millä vihan silmällä venäläiset häntä silmäilivät, niin aavisti
hän, että vasta kuolemassa hän vapautensa saisi. Ja ennenkuin
kuolema hänet saavuttaisi, saisi hän seurata venäläisiä, ken tietää
kuinka pitkälle. Se oli hänen ilonsa kumminkin, että viholliset olivat
koukkuun tarttuneet ja nyt olivat valmiit jättämään sen
paikkakunnan, missä Sanna asui.
Hiljaa ja hitaasti viilsi vene kirkasta järven pintaa. Hannu istui
perässä upseerein vieressä. Täällä sai hän vielä vastata moniin
kysymyksiin, joita upseerit hänelle tekivät; hän sai kertoa, mitä ja
minkälaisia maita oli järven tuolla puolen, olivatko paikat siellä asutut
j.n.e. Hannu vastasikin toden mukaisesti, kunnes hän huomasi, että
venäläisillä oli aikomus järven toiselle puolelle soutaa. Silloin rupesi
hän miettimään keinoa, miten vapaaksi päästä.
»Soutakaa saarelle», sanoi hän, »niin saatte nähdä, etten ole
valehdellut. Sieltä saatte nähdä, mikä teitä olisi uhannut, jos olisitte
maalle jääneet». — Saarelle ei ollut matka pitkä; upseerit alkoivat
miettiä keskenään, ja tämän kestäessä kypsyi Hannussa uusi ajatus.
Tavalla tai toisella tahtoi hän vankeudestaan päästä, ja tämmöistä
tapaa koki hän miettiä. — Vihdoin lensi ilon ilmaus hänen

silmistänsä. »Sekin on keino», muniisi hän hiljaa; »mutta se on
hirmuinen».
Vähän matkaa siitä paikasta, missä vene nyt oli, oli salakari. Tätä
karia kohti kulki vene. Tähän huomioon perustuivat Hannun
pelastuksen hankkeet, kun hän huomasi, etteivät viholliset aikoneet
saarelle poiketa.
Ympärilleen Hannu ei enään katsonut, alas veneen pohjaan
tuijottivat hänen silmänsä yhtämittaa. Jo koski veneen pohja
salakariin, kulki entistä kulkuaan pari kyynärää ja seisahtui. Salakari
oli vähäinen kooltansa ja juuri keskelle sitä oli vene noussut.
Nyt alkoi veneessä hirmuinen rähinä, jota upseerien
komentohuudot tuskin voivat hillitä, varsinkin kun kohta huomattiin,
mitä tämä karille puskeminen oli vaikuttanut. Perästä tulvasi vettä
ankaralla vauhdilla veneesen.
Eikä kummakaan, että niin tapahtui. Venäläiset luulivat veneen
pohjan särkyneeksi; luulivat sen saaneen reijän, josta vesi nyt tulvasi
sisään. Ei ollut kukaan huomannut, mitä Hannu oli tehnyt. Jos
olisivat tienneet, että Hannu oli vesitulvaan syyllinen, olisi hän ollut
kuoleman oma.
Mitä oli Hannu tehnyt?
Hän oli kenenkään näkemättä jalallaan potkaissut veneen pohjassa
olevan tapin irralleen ja samaten jalallaan työntänyt sen syrjälle
näkymättömiin, veneen pohjaa pitkin menevän laudan alle. Tästä
reijästä nyt tulvasi vesi; mutta jalallaan kätki Hannu alussa reijän,
jotteivät venäläiset rikkeintä paikkaa huomanneet.

Jos viholliset olivat oudot veneellä kulkemaan, vielä oudompi oli
heidän tilansa nyt tässä. Vene oli karilla; se täyttyi hiljoilleen vedellä,
eivätkä viholliset, mitkä Venäjän lakeissa sisusmaissa olivat eläneet,
tietäneet, mitä tässä oli heillä tehtävänä.
Se upseereista, joka vihan silmällä jo alusta oli Hannua katsellut ja
hänen neuvoansa petturin neuvoksi arvellut, oli melkein ainoa, joka
tässä vaarassa ei menettänyt järkeään. Hän oli noussut seisoalleen,
ja mela kädessä koetteli hän veden syvyyttä veneen molemmin
puolin. Kun hän huomasi, että karilla oli tuskin kyynärän paksulta
vettä, antoi hän muutamia käskyjä, josta seuraus oli, että muutamia
miehiä peläten ja pahasti irvistellen astui veteen ja koetti
työntämällä saada veneen karilta. Vähän aikaa heidän tässä työssä
oltuaan ja kun veneessä oleva väki oli vetäynyt perään, onnistuikin
tämä. Kukaan tästä väen tunkemisesta perään ei ollut niin iloinen
kuin Hannu, sillä yhä kiivaammalla vauhdilla pulppusi nyt vettä
veneesen, kun paino perässä eneni. Puolta polvea myöten vedessä
seisoivat miehet perässä, kun vene vihdoin saatiin liikkeelle.
Vaan tässä astui uudelleen silmiin venäläisten tottumattomuus.
Liikkeelle oli vene päässyt, mutta tuskin havaitsivat viholliset tämän,
ennenkuin he taasen kiiruhtivat kokkapuoleen sillä seurauksella, että
tämä puoli veneestä jälleen tarttui kiinni ja että vesi veneen
peräpuolesta juoksi kokkaan päin. Äskeinen temppu oli nyt taasen
uudistettava; ja siinä taasen kului aikaa. Yhä enemmän tulvasi vettä
veneesen.
Siinä hätääntyivät venäläiset, ja kuten aina hätääntyneissä tiloissa
käy, kävi nyt tässäkin. Mitä maltilla ja järjellä vähässä ajassa
saadaan tehdyksi, siihen kuluu hätääntyneiltä paljon aikaa. Vihdoin
oli vene saatu karilta irti; mutta nyt oli siinä vettä sen verran, ettei

Hannu enää pelännyt vihollistensa huomaavan, mistä vesi veneesen
pulppusi. — Enemmän kuin puolellaan vettä oli vene, kun nyt
kiireesti soudettiin saarta kohden.
Joka joskus on saanut nähdä, miten veneen vakavuus katoo,
samassa määrässä kuin se vedellä täyttyy, ymmärtää lopun, mikä
tässä pian oli tapahtuva. Venäläiset eivät osanneet rauhassa istua.
Epätasainen soutaminen kallisti veneen milloin toiselle milloin toiselle
puolelle ja esti samassa kulun. Hätä ja hämmästys enensi vaaraa.
Saarella oli pelastus, ja saarelle ei ollut pitkältä enää.
Hannu oli istunut itsekseen tyytyväisenä siitä, että hänen työnsä
oli niin hyvästi onnistunut. Jos häntä sanomme julmaksi, jos
myöntää täytynee, ettei hän rehellisesti käyttäynyt vihollisiansa
vastaan, niin — tarvinneeko meidän muistuttaa, millä aikakaudella
hän eli ja mitkä syyt häntä yllyttivät?
Neljäkymmentä kyynärää vielä, ja vene olisi ollut rannalla! Mutta
nyt heidän tämän verran matkaa rannalta ollessaan tapahtui se
seikka, jota Hannu oli odottanut.
Vene kaatui, ja suin päin syöksyivät viholliset järveen.
Tämä näkö olisi hirvittänyt kaikkia, joiden sydämissä ei
leppymätön viha vallinnut. Mutta oliko tällaista näkiää? Hannu oli itse
samassa vaarassa kuin muutkin, mutta itsensä tähden hän ei
peljännyt; hän tiesi, että hän osasi uida.
Kun vene kaatui, oli hän valmis antautumaan järven valtaan,
hakemaan pelastustaan. Hän ei veneen vedellä täyttyessä ollut
huomannut, että tuo hänen erityinen vihamiehensä, upseeri, oli
häntä kolkosti silmäillyt. Jos olisi hän sen nähnyt, olisi hän tiennyt

olla varuillansa. Nyt samassa, kun vene kaatui, tunsi Hannu
polttavan kivun päässään, ja kun vene oli kaatunut, ei Hannu, enää
uimalla osannut pelastaa itseään.
Upseerin miekka oli iskenyt suuren, tyrmistyttävän haavan hänen
päähänsä.
Hiljaa, sanaa sanomatta upposi hän juuri silloin, kun hän jo luuli
pelastuksensa pian varmaksi, sai surmansa siinä, missä hän ei ollut
tiennyt surmaa peljätä.
Ken tiesi häntä kaivata, ken hänen kuolleeksi kuuli?
Isä, sisar ja morsian!
Kauniimpaa kuolemaa voiko nuorukainen kuolla? Mitä hän osasi
tehdä pelastaakseen kotiseutunsa vihollisten vallasta, sen teki hän.
Ja vaikka pelastuksensa keinot olivatkin raa'at, ken häntä siitä
soimaa? Hän teki, mitä hän voi, eikä hän omaa henkeänsä siinä
työssään säästänyt.
Mutta miten kävi venäläisten?
Ken ihmisiä hengenhädässä on nähnyt, hän osaa itselleen kuvailla
heidän tilansa. Kumollaan keikkui suuri kirkkovene; airot, tuhdot,
melat, luottimet uiskentelivat tyynellä järven pinnalla. Niiden vieressä
käppyröitsivät, huusivat hätääntyneet, joista ainoastaan ani harvat
osasivat nimeksi uida. Suurin osa heistä sai ensiksi mikä itse, mikä
toisten avulla kiini veneestä. Mutta siitä piteleminen ei ollut helppoa.
Tuskin oli joku saanut käsillään kiini siitä, niin jo tähän onnelliseen
tarttui toinen, ja molemmat uivat taasen veden vallassa. Näin oli
pian jokainen ensi hädästä päässyt ja taasen samaan hätään

vaipunut. Ketkä voimakkaimmat olivat, he kestivät. Ystävä torjui pois
tyköään ystävän, pelastaakseen itsensä, sotilas ja upseeri! Kaikki
olivat nyt yhdessä hädässä yhden arvoisia. Henkitoreissaan oleva
sotilas tarttui kiini nuorempaan upseeriin, ja molemmat he katosivat
ensimäisinä siihen suureen hautaan, joka oli nielaissut Hannun.
»Jo saavat kalat herkkuja!» olisi ukko Jeremias sanonut, jos hän
tämän tapauksen järvellä olisi nähnyt. Mutta hän ei sitä nähnyt. Yksi
ainoa oli, joka sen näki, mutta häntä ei huomannut kukaan.
Kuoleman hädässä taistelivat venäläiset. Toinen toisensa perästä
irtausi veneestä ja upposi. Toiset huusivat ja toiset rukoilivat; toiset
koettivat kuoleman hädässään ristinmerkkiä tehdä.
Järvi on saanut saalista. Kymmenkunta on enää jälellä; enemmän
kuin toinen puoli on uponnut. Näistä oli joku saanut miekkahihnan
heitetyksi veneen yli, ja tämä keksintö pelasti jälellä olevat; sillä kun
toiset tämän huomasivat, seurasivat he esimerkkiä ja heittivät
veneen yli mitä soveliainta käsiinsä saivat. Kahden puolen venettä
venyivät sitten venäläiset, aina kaksi vastatusten.
Hiljainen virta ja vähitellen nouseva aamutuuli kuljetti venettä
saarta kohden, mutta näkymättömän hitaasti, vaikka aikaa kului
ennenkuin kukaan tätä pelastuksen ennettä huomasi. Mutta kun se
oli huomattu, oli hämmästyskin kadonnut. — Niin vähän tarvitaan!
Likimääriin tunti oli kulunut, ennenkuin vene oli kulkenut nuo
neljäkymmentä kyynärää ja ennenkuin eräs tovereista tunsi jalkansa
koskevan pohjaan. Kiireesti hän hiipi rannalle, niin pikaisesti kuin voi.
Toiset eivät viipyneet, ja pian nähtiin jälelle jääneet sotilaat
upseerinsa kanssa pelastettuina rannalla.

Mitä he siinä miettivät, sitä emme tiedä kertoa.
Sanottakoon vaan se, että uinnistansa olivat he niin typertyneet,
etteivät tienneet vetää venettään rannalle, ennenkuin se jo oli liian
myöhäistä. Saaren päähän olivat päässeet. Kun he venettä rupesivat
ajattelemaan, oli tämä jo saaresta niin kaukana, ettei sitä kukaan
enää uskaltanut mennä perimään. Alussa tuo ei heitä
murehduttanutkaan.
Vesimärkinä seisoivat venäläiset rannalla. Kaikki, mitä irtainta
heillä oli ollut, oli seurannut järven syvyyteen heidän uponneita
tovereitaan. Mutta jättäkäämme jälelle jääneet saarelle joksikin
ajaksi, ja kääntykäämme katselemaan, miten toisten tuttavaimme on
käynyt.
* * * * *
Torppaan, mihin Hannun oli aikomus syksyllä Sannansa emäntänä
noutaa, oli Sanna ja Jeremias jätetty.
Kahden kesken olivat he siellä, toinen haavoitettuna, toinen
terveenä.
Sanna täytti käskyn, minkä Hannu oli hänelle antanut.
Jeremiaksen haavan siteen avasi hän, pesi haavan puhtaaksi, sitoi
sen jälleen ja laittoi sitten vanhalle tuttavalleen ruokaa, sen mukaan
kuin varoja tähän torpassa löytyi. Sitten istui hän tulen ääreen ja
odotti Hannun sekä Hannun isän ja sisaren tuloa. Vanha Jeremias oli
laskeunut vuoteelle ja valitteli siellä hiljaisella äänellä kipujaan, tuon
tuostakin manaillen ampujaansa.

Näin kului aika päiväksi. Sanna silmäili yön vaaletessa ulos.
Kauniina nousi aurinko. Luonnon elävät heräsivät öisestä unestaan,
mutta järjellisiä ei laisinkaan nähty. Elävätä ihmistä ei. Kuolleita …
niitä asui yltä kyllin Sannan ajatuksissa.
Sanna ei tiennyt pahaa aavistaa. Hän odotti Hannua; mutta tätä ei
kuulunut. Jeremiaksen valitusääniä ei kuultu. Hän oli nukkunut
kivuistaan. Yksin hereillään oleskeli Sanna torpassa. Siellä hän
laskeusi maata sammuneen tulen viereen; mutta uni ei tullut hänen
silmiinsä. — Kummaapa kyllä! Aikaa kului. Hannua ei kuulunut;
mutta kumminkaan ei osannut Sanna pahaa aavistaa. Päin vastoin
näytteli hänen kuvituksensa hänelle kuvia semmoisia, joita ei hän
koskaan ennen ollut uneksinut. Hän näki itsensä torpan emäntänä,
Hannun vaimona. Ihanana, onnellisena kuvautui hänelle tulevaisuus.
Hän oli mielestänsä niin onnellinen, niin huoleton kuin ihminen
maailmassa voi olla. Sotaisista ajoista ei ollut hänellä vähintäkään
muistoa. Näin makasi hän silmät auki kovalla permannolla, kuullen
miten huokeasti ukko Jeremias hengitti… Vihdoin…
Vihdoin hypähti hän ylös. Hänen kauniit kuvituksensa olivat
muuttuneet. Sanomaton tuska täytti hänen sydämensä. Oli kuin olisi
joku yht'äkkiä tulisilla kourilla häneen koskenut. Hän heräsi
levottomasta unestaan; hän muisti kaikki, ja hän kaipasi Hannua.
Hän näki, ettei Hannu vielä ollut tullut takaisin. Silloin peljästyi hän;
silloin aavisti hän pahaa. Hannun sisaren vanhan hameen heitti hän
vanhan haavoitetun ukon peitteeksi, ja pian, muistamatta mitään
muuta kuin Hannua, läksi hän tuvasta. Pelkäämättä mitään,
ainoastaan Hannua muistellen, kiiruhti hän polkua pitkin, samaa
polkua, jota Hannu moniaita tuntia ennen oli kulkenut. Hän huusi
muutamia kertoja sulhoaan. Mutta kun ei hän vastausta saanut, hiipi
hän yhä kiireemmästi edelleen. Hän muisti nyt, missä vaarassa hän

Hannunsa kanssa äsken oli ollut. Hän, joka silloin pelkäsi, ei nyt
peljännyt. Hän kuvaili Hannun joutuneen vihollisten valtaan, ja hän,
joka äsken pelkäsi oman itsensä tähden, ei nyt peljännyt.
Näissä kummallisissa mietteissä kulkien tuli hän Myrrälle. Kun hän
ei nähnyt ketään, poikkesi hän sieltä polulle, joka vei Kauniaisten
kartanoon … kulki samaa tietä, astui samoille turpeille, minkä ruohot
eivät Hannun askeleiden jälkeen vielä olleet täydelleen suortuneet.
Veikö, ohjaisiko häntä tällä tiellä aavistus? Herättikö hänet hänen
kauniista kuvituksistansa ylenluonnollinen aisti? Sanoiko hänen
kuolematon henkensä, että Hannu oli tämän maallisen elämän
lopettanut samana hetkenä, jona Sannan ihana unelma hirmuiseksi
muuttui?
Vastatkoon tähän ne, jotka luulevat tietävänsä, missä yhteydessä
tämän elämän ja haudan tuolla puolen olevat henkilöt ovat!
Kauniaisten kartanon pihalle tuli Sanna. Siellä vasta seisahtui hän;
sillä siellä näki hän jotakin outoa. Hän tiesi, hän tunsi kuolleet siellä
Hannun surmaamiksi uhriksi, sillä niiden keskellä näki ja tunsi hän
Hannun verisen kirveen.
Mutta pois tästä hirmun paikasta riensi hän. Riensi … mutta
seisahtui taasen, sillä järvellä näki hän oudon näyn… Hän, hän siis
oli se ainoa, joka näki, miten venäläiset kuoleman kanssa taistelivat,
näki miten Hannu murretuin päin upposi järveen. Mutta tunsiko hän
järveen ensiksi kaatuneen armaaksensa?
Kauhistuneena seisoi hän rannalla ja näki, mitä järvellä tapahtui.
Sanna parka! Öinen unelma, jos noin levottomassa unessa kukaan
voi unelmia nähdä, oli saanut hänen koko henkisen olentonsa

murtuneeksi, ja nyt, nyt havaitsi hän aavistuksensa toteutuneeksi;
mutta Hannu, jota hän kaipasi, jota hän rakasti, häntä ei hän
kuolleenakaan nähnyt. Hän oli nähnyt veneen kaatuneena, oli
nähnyt, miten viholliset kuoleman kanssa taistelivat, nähnyt monta
niistä, joita hän nykyään oli peljännyt, ijäksi uppoovan Kuloveden
kirkkaan pinnan alle. Mitä teki hän, mitä sanoi hän tähän?
Hän ei tehnyt mitään, ei sanonut mitään. Mutta järven rannalle
laskeusi hän istumaan, ja mitä hän siinä mietti, jos hän siinä mitään
mietti, sitä emme ota sanoaksemme. Verinen kirves, Hannun kirves,
joka hänellä oli kädessä, ja mitä hän oli nähnyt — kaikki sanoi sanoja
selvemmin, mitä Hannulle oli tapahtunut. Hänen silmänsä olivat
käännetyt saarta kohden; itkua näissä silmissä ei ollut, kyyneltä ei
vierryt hänen vaaleita poskiansa myöten. Mutta jos ken häntä tuossa
olisi nähnyt, olisi hänen ensi silmäyksensä sanonut, että rannalla
istuva neitonen vapisi. Tämä näkiä olisi luullut vavistuksen syntyneen
siitä hirmuisesta tilasta, missä venäläiset taistelivat kaatuneen
veneen ympärillä. Sano sinä, lukiani, vapisiko hän, tämä nuori
Suomen neitonen, tästä syystä?
Vastaat: Ei! Ja kumminkaan eivät hänen silmäyksensä luovu
saaresta, mihin hän näkee venäläisten pelastuvan!
Rataansa kulkee aurinko, ja sen kulkiessa kuluu päivä. Kauniaisten
kartanon ympäristössä vallitsi tänä päivänä hiljaisuus. Ainoa
järjellinen, joka tätä hiljaisuutta olisi voinut häiritä, oli Sanna; mutta
hän istui rannalla ääneti.
Siinä istui hän, istui sanaa sanomatta tirkistäen saarelle päin.
Mutta surullisenkin päivä kuluu ehtoolle, epäilyksenkin alaisen
aamu loppuu!

Ehtoopuolella päivää hän nousi. Hiljaa, hitaisemmasti kuin hän oli
tullut, kulki hän polkua maantielle, ja sinne tultuaan kulki hän sitä,
kulki sivu polun, joka vei metsätorppaan, jonka emäntänä hän oli
toivonut saavansa elää ja kuolla.
Minne kulki hän?
Hän kulki sen luo, joka hänen oli laskenut ensikerran Herran
pyhälle ehtoolliselle. Sinne kävi hänen tiensä. Kirkkoherraansa oli
hän oppinut, kuten muutkin seurakunnassa, surussa turvautumaan.
Kirkkoherran luo hän kulkee.
Kaksi penikulmaa kulkee hän; ei kiireesti, ei hitaisesti. Hänen
kulkunsa on semmoisen, joka surutta ja murheetta askeloitsee.
Mutta surutta ja murheetta ei kukaan tällä tavalla, istumatta,
levähtämättä kulje kahta pitkää penikulmaa.
Aurinko oli laskenut, kun hän Huidan talon sivu kulki; yö oli jo
kulumassa, kun hän Koljaan ja Mäenpään tiluksien poikki astui;
keskiyön aika oli, kun hän Karkun pappilaan ehti. — —
Useita vuosia on kulunut siitä, kun tämän tarinan »Sadan
leukaluista» kuulin eräältä vanhalta ukolta Suoniemessä. Kun ukko
kertomuksessaan tuli siihen kohtaan, missä Sanna pappilaan ehti,
keskeytin häntä kysymyksilläni:
Mitä mietti tyttö? Miten kävi hänen pappilassa; siellähän majaili
myöskin venäläisiä?
Ja ukko vastasi: »Mitä Sanna mietti, sen tiennee Jumala! Muuten,
niin, mitäpä siinä oli miettimistä!»

Ja ukolla oli oikein. Sanna tahtoi purkaa sydäntänsä, tahtoi saada
lohdutusta. Ja hän tarvitsi sitä. —
Toiseen kysymykseen vastasi ukko: »Pappilassa oli venäläisiä;
hyvä että sen muistatte!» Ja että vihollisia siellä oli, sen muistat
sinäkin, hyvä lukiani; sillä tiedäthän, mitä edellisenä yönä oli
pappilassa ja pappilan tienoilla tapahtunut.
Muistat myös, mihin tilaan jätimme kirkkoherran, kun käännyimme
Hannun ja Sannan luo.
Kirkon ylisillä lepäsi hän — jos sanaa lepäsi voi tässä käyttää —
viimeksi kuluneen yön paimenpojan kanssa. Siellä vapisi hänkin
niistä tapahtumista, joita hänen omat silmänsä olivat aamulla
nähneet; siellä vietti hän pitkän päivänsä ruuatta, juomatta,
uskaltamatta liikkua mihinkään. Ja pitkä oli hänelle tämä päivä! Unta
hän ei sen kuluessa silmiinsä saanut, niinkuin hänen nuori
kumppaninsa heidän pimeässä piilossaan.
Vihollisten vallassa oli pappila ja naapuritalot. He olivat nähtävästi
aikeissa näillä seuduin viipyä useitakin päiviä; sillä mitään ei
huomattu, joka olisi ennustanut heidän poislähtöään.
Pappilaa kohden, missä venäläisten tänpuolinen päällikkö majaili,
kulki Sanna keskiyönä. Kuta likemmäksi hän pappilaa tuli, sitä
kiireemmin hän nyt kulki. Mutta kun hän taloa liki tuli, seisahtui hän
äkkiä. Yön hämärässä näki hän pihalla vähän matkaa
asuinhuoneesta venäläisen sotilaan, joka siinä vartiana seisoi. Sanna
tunsi tämän heti venäläiseksi.
»Niin muodoin on pappilakin heidän vallassansa», sanoi hän.
»Mutta missä, missä ovat pappilan asukkaat?»

Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.
More than just a book-buying platform, we strive to be a bridge
connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.
Join us on a journey of knowledge exploration, passion nurturing, and
personal growth every day!
ebookbell.com

Codesign For System Acceleration A Quantitative Approach 1st Edition Nadia Nedjah

More Related Content

Featured (20)

Codesign For System Acceleration A Quantitative Approach 1st Edition Nadia Nedjah