1) A scheduler for a crossbar is given below. Assume that packet lengths are fixed. (a)
Suppose we use the random scheduling algorithm for a crossbar scheduler (meaning that the pointers’ values are randomly set in each iteration). Compute the throughput of a NxN (N is very large) crossbar if we can perform one iteration in each packet transmission time. Note that in the design, each input controller will launch N requests in each iteration. (b) Repeat (a) if we can perform two iterations in one packet transmission time. (c) Repeat (a) if we can only launch two requests (randomly selected) in each iteration. (d) Repeat (b) if we can only launch 2 requests in each iteration.
Pointer
A
1
VOQ 1,1
VOQ 1,2
VOQ 1,N
: :
: :
Output
Controller 0
Pointer
G
1
Pointer
VOQ N,1
: :
Pointer
VOQ N,2
A
N
G
N
Output
VOQ N,N
Controller N
(a) The probability of a particular input controller not receiving a grant from one output is:
N
N

1

1

1
N
Then, the probability of the input controller not receiving any grant from output is:
( 1

1
N
)
N  e

1
(N is very large)
Therefore, the throughput is 1

( 1

1
N
)
N 
1
 e

1 
63 .
2 %
(b) In the second iteration, only the input controllers that haven’t received a grant will launch N requests, and only those whose grant is not selected will send out grant.
Similar as the first iteration, we can easily derive that probability of one the remaining input controllers getting at least one grant is 1
 e

1
, according to the result of (a).
Therefore, the throughput is ( 1
 e

1
)
 e

1
( 1
 e

1
)

1
 e

2 
86 .
5 %

(c) The probability of an output controller receiving a request from a given input controller is: 1

C
2
N

1
C
N
2

1

N

2

N
2
N
The probability of one of the two requests for a given input controller not selected by the output controller is: k


1 N 

0
C k
N

1
N k

1 

0
2
N k

1
(
2 k k
 k

1 )!
e

2 
2
N e

2


N

1
 k
 k k

1
 k
N 

1

0
2 k k !
k

1 N 

0






1
2 k
N 

1
2 k k !


 e

2
(
1
2 e
2 
1
2
)

1
2

1
2 e

2
2

N

1

N k !
k





1

2
N
N

1
 k
 k k

1
Where, k is the number of the requests an output controller might receive except the one from the given input.
Then, the probability of the given input controller not receiving any grant is:
1
2
1
2
2 e

2
Therefore, the probability of the input that can transmit the data packet is:
1

1
2
1
2
2

2 e
That is, the throughput is 1

1
2
1
2 e

2
2

67 .
8 %
(d) Similar as (b), we can get,
The throughput is




1

1
2
1
2 e

2
2




1
2
1
2 e

2
2




1

1
2
1
2 e

2
2




1

1
2
1
2 e

2
4

89 .
6 %

2) In the design of a crossbar scheduler, we need three phases in one iteration as shown below. The reason we need the final selection phase is that if we want to perform multiple iterations, an output controller needs to know if its grant is selected or not. request grant final selection
In order to perform more iterations in one packet transmission time, we need to shorten the amount of time in each iteration. So one idea is to use a pipelined scheme as shown below. Are there any problems with this method? If yes, how do you fix it?
Note that the signals (request, grant, or final selection) will not be stable until the end of each phase.
Request Grant final selection
There’re some problems with the shown method.
If input controller sent out Request of the next iteration immediately after finishing sending that of the current iteration, the controller will not know if it could get a grant, so the input controllers that will receive at least one grant would launch Requests again, and might receive a grant later. This results in redundant requests as well as wasted grant. Likely, the output controller might not send out any grant since it does not know if its grant is selected, which makes the second iteration useless.
We can make a small modification as shown below:
Request Grant final selection
Request Grant final selection
In the fixed version, only those input controllers that haven’t received any grant will launch requests. And only those output controllers whose grant is not selected will give out an grant in the next iteration, avoiding the problems addressed above.