CS501 Advance Computer Architecture GDB Close Date 7th to 8th August 2014

[vuassignments]

View more random threads:

• mgt111 2nd GDB spring idea solution May 2011
• CS401 Computer Architecture and Assembly Lan GDB Solution &...
• mgmt630 GDB solution 2011
• ECO403 VU Current GDB solution Fall 2011-2012 solution
• cs410 GDB idea solution july 2011
• Mgt611 GDB No. 3 July Spring 2011 idea solution
• Eco401 first GDB statement Solution fall 2011 on November...
• GDB of MTH603 July, 2010
• MGT402 Cost and Managment Accounting GDB Solution May10,2010
• solution ofGDB 503 need

CS501 Advance Computer Architecture GDB Discussion and Solution Close Date 7th to 8th August 2014

Sponsored Links



Topic:

In computer architecture why does a “system interface unit” provide separate queues for “read” and “write” transactions?
Is it possible for a “write queue” to directly execute without interference of “read queue”?
Answers must be to the point and justified with reasons.Note: Your answer should not be more than 300 words.

[Vuhelper]

Read Queue

Only a few entries are needed to be effective: 2-4 is typical. Reads fetch a whole cache line (by bursting multiple reads onto the main memory bus). However, the requested word could be the last in the cache line, leading to an intolerable delay (with the CPU blocked waiting for the data) while the first words are read. Thus the SIU must also ensure that the requested word is read first and transferred to the cache (and on to the read request in the main pipeline) followed by the remainder of the cache line. So a burst transaction for 8 words (32 bytes) on a 64-bit bus will not always read the words in order

(0 and 1, 2 and 3, 4 and 5, 6 and 7)
but may read them out-of-order, eg word 5 is requested, so the order is

(4 and 5, 6 and 7, 0 and 1, 2 and 3)
Bus clocks (typically 30-60MHz) are much slower than processor clocks (typically 200-600MHz) so the penalty for not re-ordering the bus transactions is extreme!

Write Queue

As with the read queue, a small number of entries suffice: 2-3 is typical. Transactions in the write queue are only selected for execution if the read queue is empty. This is a key function of the SIU - giving priority to read transactions that could block the CPU.

Note that read requests must be checked against pending transactions in the write queue: the write queue may have the latest value written to a memory location (the main memory has not yet been updated - a coherence problem) and its this value which should be supplied to the read operation.

[Vuhelper]

Read Queue

Only a few entries are needed to be effective: 2-4 is typical. Reads fetch a whole cache line (by bursting multiple reads onto the main memory bus). However, the requested word could be the last in the cache line, leading to an intolerable delay (with the CPU blocked waiting for the data) while the first words are read. Thus the SIU must also ensure that the requested word is read first and transferred to the cache (and on to the read request in the main pipeline) followed by the remainder of the cache line. So a burst transaction for 8 words (32 bytes) on a 64-bit bus will not always read the words in order

(0 and 1, 2 and 3, 4 and 5, 6 and 7)
but may read them out-of-order, eg word 5 is requested, so the order is

(4 and 5, 6 and 7, 0 and 1, 2 and 3)
Bus clocks (typically 30-60MHz) are much slower than processor clocks (typically 200-600MHz) so the penalty for not re-ordering the bus transactions is extreme!

Write Queue

As with the read queue, a small number of entries suffice: 2-3 is typical. Transactions in the write queue are only selected for execution if the read queue is empty. This is a key function of the SIU - giving priority to read transactions that could block the CPU.

Note that read requests must be checked against pending transactions in the write queue: the write queue may have the latest value written to a memory location (the main memory has not yet been updated - a coherence problem) and its this value which should be supplied to the read operation.

[Entboy]

The SIU will manage separate queues for read and write transactions - taking requests from the read queue in preference to those in the write queue. Once the processor has despatched a command to write a result to main memory, it can assume that the operation is complete and continue immediately to the following operation.
Detecting read requests for data in write buffers
All read requests must be checked against transactions waiting to be written in the write buffers. This is an example of a coherence requirement - the data in the main memory is not the most recent value of the addressed location. If read requests "hit" data in the write queues, then the request must be satisfied from data in the write queue - not the data in main memory