c
 

 








  
 



 
: 


 




 
 
 

    
  

 !"#$%

Mobile:- 9878970826
Call me for assignments and term papers
Course Code: - CAP 208

Course Instructor: Mr. Sandeep Sharma

Date Of Submission: 05/05/10

Student¶s Roll No. ± A09

Section: D3801

Topic: Pipeline Architecture

Declaration: - I declare that this term paper is my individual

work. I have not copied it from any other student work or
from any other source except where due acknowledgement
is made explicitly in the text. Not as any part being written
for me by another person.

Student¶s Signature:
Himanshu Gautam










 












Y

YYYYYYYYY
 
Y

I am heartily thankful to my teacher, Mr. Sandeep Sharma

whose encouragement, guidance and support from the
initial to the final level enabled me to develop an
understanding of the subject.

Lastly, I offer my regards and blessings to all of those who

supported me in any respect during the completion of the
project.

Ä

 Y
A 
 is a message queue. A message can be anything. A 
 is a process, thread, or
other component that perpetually reads messages from an input pipe, one at a time,
processes each message, then writes the result to an output pipe. Thus, it is possible to form


 of filters connected by pipes:

     
V
 V
 V
 V


The inspiration for pipeline architectures probably comes from signal processing. In this
context a pipe is a communication channel carrying a signal (message), and filters are
signal processing components such as amplifiers, noise filters, receivers, and transmitters.
Pipelines architectures appear in many software contexts. (They appear in hardware
contexts, too. For example, many processors use pipeline architectures.) UNIX and DOS
command shell users create pipelines by connecting the standard output of one program
(i.e., cout) to the standard input of another (i.e., cin):

 

  


In this case pipes (i.e., "|") are inter process communication channels provided by the
operating system, and filters are any programs that read messages from standard input, and
write their results to standard output.
LISP programmers can represent pipes by lists and filters by list processing procedures.
Pipelines are built using procedural composition. For example, assume the following LISP
procedures are defined1[1]. In each case the nums parameter represents a list of integers:

KK
 



V

V
V



KK
  
 



V
  

KKV





V


We can use these procedures to build a pipeline that sums the squares of odd integers:

V

    

Here's the corresponding LISP definition:

KKV V



V
 

   V



Pipelines have also been used to implement compilers. Each stage of compilation is a filter:

   

  



The scanner reads a stream of characters from a source code file and produces a stream of
tokens. A parser reads a stream of tokens and produces a stream of parse trees. A translator
reads a stream of parse trees and produces a stream of assembly language instructions. We
can insert new filters into the pipeline such as optimizers and type checkers, or we can
replace existing filters with improved versions.

There's even a pipeline design pattern:

 
 &
 [POSA]
' 
Pipelines
 
The steps of a system that processes streams of data must be reusable, re orderable, replaceable,
and/or independently developed.
  

Implement the system as a pipeline. Steps are implemented as objects called filters. Filters
receive inputs from, and write outputs to streams called pipes. A filter knows the identity of its
input and output pipes, but not its neighboring filters.


Y



 Y
There are four types of filters:    ,    ,    , and   . A
producer is a producer of messages. It has no input pipe. It generates a message into its
output pipe. A consumer is a consumer of messages. It has no output pipe. It eats messages
taken from its input pipe. A transformer reads a message from its input pipe, modulates it,
then writes the result to its output pipe. (This is what DOS and UNIX programmers call
filters.) A tester reads a message from its input pipe, then tests it. If the message passes the
test, it is written, unaltered, to the output pipe; otherwise, it is discarded. (This is what
signal processing engineers call filters).

Filters can also be classified as 

 or 

. An active filter has a control loop that
runs in its own process or thread. It perpetually reads messages from its input pipe,
processes them, then writes the results to its output pipe. An active filter needs to be
derived from a thread class provided by the operating system:



 

!"
An active filter has a control loop function. Here's a simplified version that assumes the
filter is a transformer:
  

#
!
 $

 !
  % 

&  '
  

V
'KK


  & $ 
'
 "
"
We will explore active filters in Chapter ?.

When activated, a 


 reads a single message from its input pipe, processes it,
then writes the result to its output pipe:

    
!
 % 

&  '
 

V
'KK


 & $ 
'
"
There are two types of passive filters. A (


 is activated when another filter
writes a message into its input pipe. A (


 is activated when another
filter attempts to read a message from its empty output pipe.

Y 
Y

 Y


 Y

Assume a particular data-driven pipeline consists of a producer connected to a transformer,

connected to a consumer. The producer writes a message to pipe 1, the transformer reads
the message, transforms it, then writes it to pipe 2. The consumer reads the message, then
consumes it:

 (*
 
(&  (&  ()
V  (& 



 
$ 


V
 

$   



 



Y

 Y
 Y
A data-driven pipeline pushes messages through the pipeline. A demand-driven pipeline
pulls messages through the pipeline. Imagine the same set up using demand-driven passive
filters. This time read operations propagate from the consumer back to the producer. A
message is produced and written to pipe 1. The transformer reads the message, transforms
it, then writes it to pipe 2. This message is the value returned by the consumer's original
call to read():



Y Y
Y 



Y Y  
Y


Y


Y


Y

 Y

Y 


Y

 Y

Y  Y

Y Y
½oth diagrams reveal a design problem. How does the transformer know when to call
pipe1.read()? How does the data-driven consumer know when to call pipe2.read()? How
does the demand-driven producer know when to produce a message? Active filters solve
this problem by polling their input pipes or blocking when they read from an empty input
pipe, but this is only feasible if each filter is running in its own thread or process.

We could have the producer in the data-driven model signal the transformer after it writes a
message into pipe 1. The transformer could then signal the consumer after it writes a
message into pipe 2. In the demand-driven model the consumer could signal the
transformer when it needs data, and the transformer could signal the producer when it
needs data. ½ut this solution creates dependencies between neighboring filters. The same
transformer couldn't be used in a different pipeline with different neighbors.

Our design problem fits the same pattern as the problem of how the reactor in Chapter 2
communicates with its unknown monitors. We solved that problem by making the reactor a
publisher and the monitors subscribers. We can use the publisher-subscriber pattern here,
too. Pipes are publishers and filters are subscribers. In the data-driven model filters
subscribe to their input pipes. In the demand-driven model filters subscribe to their our
output pipes.

  YY  YY

We can separate the pipeline into two categories.

Instructional pipeline:
where different stages of an instruction fetch and execution are handled in a
pipeline.
Arithmetic pipeline:
 where different stages of an arithmetic operation are handled along the stages of a
pipeline.
Y




 YY   Y
1.Y The cycle time of the processor is reduced, thus increasing instruction issue-rate in
most cases.

2.Y Some combinational circuits such as adders or multipliers can be made faster by
adding more circuitry. If pipelining is used instead, it can save circuitry vs. a more
complex combinational circuit.

Y




 YY   Y
1.Y A non-pipelined processor will have a stable instruction bandwidth. The
performance of a pipelined processor is much harder to predict and may vary more
widely between different programs.

2.Y A non-pipelined processor executes only a single instruction at a time. This

prevents branch delays (in effect, every branch is delayed) and problems with serial
instructions being executed concurrently. Consequently the design is simpler and
cheaper to manufacture.

3.Y The instruction latency in a non-pipelined processor is slightly lower than in a

pipelined equivalent. This is due to the fact that extra flip flops must be added to the
data path of a pipelined processor.