lab 28 bus arbitration objective: global domain · 2005. 4. 8. · bus arbitration logic and hidden...

ee454l_lab28_bus_arbitration_r1.fm 4/7/05

Lab 28

Designed by: Gandhi Puvvada

Bus Arbitration

Objective:

Our objective in this lab is to familiarize you with bus arbitration and exchange of the control of bus between processors so as to communicate with a global memory. Need for byte-swapping in a system with both 16-bit and 8-bit processors is demonstrated in this lab. Synchronization of signals crossing clock domains is one of the issues covered by this lab.

Please refer to the schematics constantly as you read this lab write-up.

Global domain:

In this lab, we are interfacing a 16-bit wide global memory to two microprocessors (8086 and 8088) through a single glo-bal bus. Please refer to top-level bus_arbitration schematics (bus_arbitration.1, bus_arbitration.2) . In the top-level schematic, we basically instantiate the two processor subsystems and the global memory subsystem. Besides these, we have the common bus arbitration logic (74F148 and 74F138).

Byte-Swap operation:

Like in the case of Intel Multibus, here we assume that the global memory would not know if a byte access request pre-vailing on the bus has originated from the 16-bit processor or the 8-bit processor. Hence the bus specification requires that the 8-bit data for a byte access is always exchanged on the global bus data lines GD[7:0] (even if the byte is an ODD-addressed byte exchanged with the 16-bit processor 8086). That's why we use (as shown above)

(a) a swap XCVR in the 16-bit memory sub-system to transfer data between the lower 8 bits of the

8088

8086

Even Bank

Odd Bank

XCVR

XCVR

XCVR

XCVR XCVR

XCVR

XCVR

swap swap

GMD[7:0]

GMD[15:8]

BD[7:0]

BD[7:0]

BD[15:8] GD[15:8]

GD[7:0]

GD[7:0]

Memory

8086sub_sys

8088sub_sys

Glob_mem_sub_sys

74F148

74F138

1/28 Copyright 2005 Gandhi PuvvadaC


global data bus GD[7:0] and the higher 8 bits of the memory GMD[15:8]and

(b) a swap XCVR in the 16-bit processor sub-system to transfer data between the lower 8 bits of the global data bus GD[7:0] and the higher 8 bits of the 16-bit processor sub-system BD[15:8].

Bus Requester bus_requester.1 (the 8289):

In the 8086 family of chips, there is a device called 8289 which is placed in each processor node. Its job is to ask for the bus once there is a need to perform a global access (determined by the address generated by the processor). The 8289 chip receives a global access request from an address decoder, submits a bus request (BREQ) to a common bus arbitration logic, waits for the grant (BPRN), waits for the bus to be available (BUSY = 1), grabs the bus (drives BUSY to 0), and eventually informs the rest of the items in the processor node that it has the bus (AEN = 0). The Bus Requester compo-nent in our design emulates the essential functionality of the 8289 chip.

Global Bus Controller glob_bus_controller1.1 (the 8288):

Notice that the need for a Global Access is detected during T1, when the processor puts out an address. Then bus requester takes a few to several 10’s of clock cycles to obtain the bus. By that time, T2 and T3 states have already passed. Because of the normally-not ready system implemented in the processor nodes, the processor goes into Tw wait-states. With-in the processor node, the address became valid during T1, and the control signal (MEMR or MEMW) became active at the beginning of T2. Since global memory is a traditional SRAM, it needs address setup time before the start of the write operation. Hence, on obtaining the bus (AEN = 0), we can’t simply put address, data, and MEMW control signal on the global bus, all at once (simultaneously); we have to provide the global memory with the address first and then (after a reasonable length of time to cover the address setup time) the MEMW control signal . Later at the end of the transac-tion, we need to inactivate MEMW first and keep the address for a while to cover the write-recovery time specification of the global memory. This sequencing of the control signals is the job of the Bus Controller chip 8288 in the Intel 8086 fam-ily of chips. In our implementation, the Global Bus Controller component emulates the essential functionality of the 8288 chip.

Bus arbitration logic and Hidden Bus Arbitration:

In this lab we’ve used “parallel priority resolving bus arbitration technique”. This piece of logic is located outside the pro-cessor nodes in the global area and consists of a priority encoder (74F148) and a 3 to 8 decoder (74F138). It receives all the requests (BREQ) and grants the highest priority request by activating the corresponding BPRN signal. However, the bus control can not be taken away abruptly from the current bus master preempting its current bus cycle. So the current master can hold on to the bus until finishing its current bus cycle. Then it relinquishes its bus control by inactivating the BUSY line. The master with an active BPRN will monitor the BUSY line to see if the bus became idle. If BUSY becomes inactive, then the master waiting to become the next master, will start driving the BUSY line active, there by asserting its control of the bus. The bus arbitration logic’s responsibility is only to prioritize the prevailing requests and issue BPRN . Receiving BPRN, monitoring BUSY and eventually driving BUSY is the responsibility of the Bus Requester logic. Please notice that a microprocessor sub-system with an active BPRN, who is waiting for the bus, can lose this privilege if another processor with higher priority asks for the bus. On every bus clock (without waiting for the bus to become idle), the bus arbitration logic detects the highest priority request currently prevailing and indicates to that master that it was chosen to become the next bus master though BPRN. This is called HIDDEN arbitration as the time taken to arbitrate is hidden and is not added to the bus exchange overhead delay. Different processors may be running at different local clocks. Hence, if BREQ signals are produced in synchronism to the individual local clocks, then they will all be asynchronous to each other. The global bus has its own clock, the BCLK . The BCLK is supplied to every Bus Requester so that the bus requester produces BREQ signal in synchronism to the negative edge of the BCLK.



Bus requester State Diagram:

Please refer to the incomplete state diagram of the bus requester at the end of this write-up. This state machine performs state transitions on the negative edges of the bus clock (BCLK), so all the BREQ signals are produced in synchronism to the BCLK. Notice that the two signals (SYNC_GLOB_ACSS and SYNC_RELEASE) sent to it by the processor address decoder and the bus controller respectively are synchronized to the negative edges of the BCLK . The BUSY and the BPRN signals are already BCLK clock domain signals. The AEN signal produced by this state machine shall be syn-chronized to the local clock of a processor node before sending to the Bus Controller since the Bus Controller works on the negative edges of the local clock. Please complete the state diagram.

Global Bus Controller State Diagram:

Please refer to the incomplete state diagram of the Global Bus Controller at the end of this write-up. This state machine runs on the negative edges of the local clock CLK. Among the signals it reacts to are two signals, AEN and XACK, which originate from the BCLK domain. Note that these two signals are synchronized to the local clock CLK and the SYNC_AEN and SYNC_XACK are sent to this controller state machine.

This controller produces three control signals, RELEASE, BUS_ENABLE, and BRD_WR_AUTH. The BUS_ENABLE signal enables the address from the processor node onto the global bus. It also lets the processor drive the following signals on the system bus: GBYTE (global 8-bit byte request), GHALF_WORD (global 16-bit word request), GWORD (global 32-bit word request), ~GDEN (global data enable signal based on local ~BDEN signal), GDT/R~ (glo-bal data transmit/receive~ based on local DT/R~). It (BUS_ENABLE) also lets the local BRD signal to appear as global GRD and local BWR signal to appear as GWR .However the local BRD and the local BWR signals are conditioned (timed) by the BRD_WR_AUTH . The BRD_WR_AUTH signal enables the local MEMR~ signal as local BRD signal and the local MEMW~ signal as BWR signal.

This controller, after receiving SYNC_XACK, goes through Qta33 and Qta4 before going to Qd where it advises the Bus Requester state machine to RELEASE the bus. The Qta33 state allows time for the processor to come out of its wait states based on the READY signal derived from SYNC_XACK by the clock generator 8284. The Qta4 state allows time for the write-recovery of the global memory. In Qd state, this state machine will activate the RELEASE signal. This RELEASE signal produced in CLK clock domain is synchronized to BCLK clock domain as SYNC_RELEASE and then conveyed to the Bus Requester. Then the Bus Requester stops driving the BUSY line and releases the bus.

Processor nodes:

In this design we’re using two processors; 8088 and 8086. For each of these processor sub-systems we’ve created a top symbol which we call the “processor node”. If you refer to the first page of the global schematic (bus_arbitration.1) you can see these symbols and their pin outs. We have external reset (EXRESET), system clock (SYS_CLK), bus clock (BCLK), bus-priority-in (BPRN), and trans-fer acknowledge (XACK) as inputs to each system. The outputs consist of bus request (BREQ), global read and write (GRD, GWR), global data enable and global DT/R~ (~GDEN, GDT/R~), global addresses (GA[19:0]), BYTE, HALF_WORD, and WORD. The BYTE pin will go high when the processor is requesting an 8-bit wide transaction. The HALF_WORD pin goes high when the processor is requesting a 16-bit wide transaction. The WORD pin is used for 32-bit wide transactions and won’t be activated in this design at all. Please pay attention to the fact that all these output signals are tri-stated and won’t drive the global bus unless that processor is the bus master (AEN=0).



Bus busy (BUSY) and global data (GD[15:0] or GD[7:0]) pins are both input and output (bidirectional) pins. The BUSY signal line is driven to low by the current bus master using an open-collector gate. An open-collector gate can drive a signal to logic ‘0’ but it can’t drive it to logic ‘1’. Because of pull-up resistance, the BUSY signal line goes to its inac-tive HIGH value if no one is driving the same.

Now please look at the underlying schematic for each of the processor nodes. (8088sub_sys.1 or 8086sub_sys.1) In the first page you have the processor with the address latches and data transceivers. To provide clock, ready and reset signals to the processor, we’ve used the clock generator chip 8284. The difference between these sub-systems and what we had in lab 21 designs is that here we use two ready signals and two AEN signals as inputs of 8284. AEN1 and AEN2 act as qualifiers for RDY1 and RDY2 respectively. Here we are using RDY1 for the local memory and RDY2 for global mem-ory. In this design, we wish to treat the local memory as fast memory requiring no wait states. Hence we have connected RDY1 to power. This permanent ready will not go through unless we are having a local access. If we’re having a global access, the low-active AEN1 (driven by the active-high GLOB_ACSS) will not go active. Similarly, during global access, AEN2 is activated by SYNC_AEN and RDY2 is driven by the inverted SYNC_XACK . Unless the processor is the bus master the transfer acknowledge XACK from the global memory should not reach the processor as READY.

We create the GLOB_ACSS signal with a simple decoding logic. Please read the decoding logic to produce GLOB_ACSS signal, decoding logic to produce local memory chip-select signals and local memory interface.

Synchronization of signals crossing clock domains in the processor nodes: In each processor node, we have a bus_requester (bus_requester.1) and a global_bus_controller (glob_bus_controller1.1). As you know, the bus_requester and the global_bus_controller run on different clocks. Please pay attention to the fact that a signal created in one clock domain can’t be used in the other clock domain unless it is synchronized with the clock of the receiving sys-tem. Usually synchronization is done using the same edge as the edge governing state transitions (negative edge for the two state machines here). This allows the state machine, which is receiving the synchronized input signal, a complete clock to react to the signal. However, since the clocks are slow in this design, and since next-state logic is very simple and fast, we are using the opposite edge (opposite to the edge governing state transitions). This allows the next-state logic only half clock (actually 33% clock because of the duty cycle is 33%) for it to respond to the synchronized input signal.

Please read the schematic to see how signals of a node are connected to the global bus via tristate buffers and transceivers.Notice that there are 3 global transceivers in 8086 node and only one in 8088. Data from global memory passes through transceivers in the global memory subsystem and comes on to the global bus, then passes through the global transceivers within a processor node and finally through the primary transceivers at the foot-steps of the processor and reaches the pro-cessor.

Global memory subsystem:

This subsystem basically consists of the two banks of the 16-bit global memory, three transceivers (including the swap xcvr), unidirectional 2-state buffers for receiving address and control, and global wait-state generator running on the neg-ative edges of the BCLK to produce XACK .

Your assignment:

The schematics provided to you are incomplete in a few respects. Please extract the files for this project by executing these two commands:

cd ~/pv/ee454l/

~ee454/ee454l_bus_arbitration.shar

sch/bus_arbitration.1 sch/bus_arbitration.2sch/74f245top.1 sch/74f244top.1 sch/tbuf20.1 sch/8086sub_sys.1sch/8086sub_sys.2 sch/8086sub_sys.3 sch/8086sub_sys.4sch/8086sub_sys.5 sch/8086sub_sys.6 sch/8088sub_sys.1sch/8088sub_sys.2 sch/8088sub_sys.3 sch/8088sub_sys.4sch/8088sub_sys.5 sch/bus_requester.1 sch/glob_bus_controller.1sch/glob_bus_controller.2 sch/glob_mem_sys.1 sch/glob_mem_sys.2sch/glob_mem_sys.3 sym/74f245top.1 sym/74f244top.1 sym/tbuf20.1sym/8086sub_sys.1 sym/8088sub_sys.1 sym/glob_mem_sys.1sym/bus_requester.1 sym/glob_bus_controller.1cmd/bus_arbitration_86_88.cmd cmd/bus_requester_test.cmdcmd/glob_bus_controller_test.cmd global86.c global88.c

Note: This is the list of files you will receive.



1. Bus arbitration logicRefer to the second page of the schematic in global domain (bus_arbitration.2). Complete the connec-tions to the two chips 74F148 and 74F138. Unused outputs may be left open. Connect BREQ86 and BREQ88 to the 74F148 inputs and BPRN86 and BPRN88 to the outputs of the 74F138. Refer to the function tables repro-duced from the TI (Texas Instruments web site). BREQ86 shall be given higher priority compared to BREQ88.Please include a printout of this page in your report.

Show in your report, how you would replace 74F148 and 74LS138 combination with simple SSI (small scale integrated circuit) logic (example: using SSI gates such as OR-gate, NAND-gate, etc.).

2. Bus Requester designa) Go over the explanation for bus requester at the beginning of this hand out. b) Try to complete the state diagram of bus requester provided at the end of this hand out. Have your TA approve it.c) Open bus_requester.1 schematic and complete the state machine design. Make sure that the names of the signals you chose are the same as the bus_requester symbol pin names. Please pay attention to the type of gate driving the BUSY in the OFL (output function logic) of the state machine. What kind of gate is that? Open-collector output / Totem-pole 2-state output / Totem-pole 3-state output ? Why? Test bus_requester.1 completed schematic with the command file bus_requester_test.cmd. d) Please include a copy of the completed state diagram, a copy of the completed schematic, and a copy of the waveform together with answers to the following questions:

d.1 The gate driving the BUSY is a/an ________________________________________ output gate.d.2 The BUSY signal is ___________________ (an output of / an input to / an input to as well as an

output of) this state machine.d.3 What happens if the BPRN becomes inactive before the bus becomes available (BUSY = 1)?

Can it happen? How?

3. Global bus controllera) Go over the explanation for global bus controller at the beginning of this hand out.b) Try to complete the state diagram of bus controller provided at the end of this hand out. Have your TA approve it.c) Open the bus_controller.1 schematic and complete the state machine (including OFL). Make sure that the names of the signals you chose are the same as the glob_bus_controller symbol pin names. Test your design with the command file bus_controller_test.cmd.

BREQ86

BREQ88

BPRN86

BPRN88

From Texas Instruments web site



d) Please include one copy of the completed state diagram, the completed schematic and the waveforms together with answers to the following questions:

d.1 Are the outputs generated in Qta1 state different from Qta2 state? Yes/No. Explain.d.2 What is the purpose of Qta4?

4. BRD, BWR, and BDENThe logic creating these signals in each of the two processor nodes (sheet 4/6 in the case of 8086 and sheet 4/5 in the case of 8088) is either incorrect or incomplete. Correct/complete the logic. (Hint: refer to the explanation of global bus controller)

6. 8086 processor subsystem and bus_requester and glob_bus_controllerInside each processor node, there is one bus_requester and one glob_bus_controller. Please look at the inputs and outputs of these components in 8088 sub-system. Now complete the design for 8086 processor node by labeling the inputs and outputs properly. If any input needs to be synchronized, please create it using the flip-flops provided.

7. global tri-state buffer’s enablePlease enable the global tri-state buffers inside each processor node with the correct signal.

8. XCVRs Please refer to the global data XCVRs inside each node. Set the direction and enable them properly. Please do the same for the XCVRs in global memory subsystem as well.

9. BUSY signal in Global domainHow come all the BUSY pins of the processor nodes are connected to the same signal BUSY? (we know that inside each node, unlike other outputs, BUSY doesn’t pass through a tri-state buffer (or does it?!) Doesn’t it cause collision? Why do we have a pull-up resistance on BUSY? Include your answer in your report.

10. Fair exchange of bus control: you can see, although 8086 has the highest priority, it is not the bus master at all the times. The 8088 processor could also get the bus. How did it happen? Can 8088 processor “starve” (meaning it never gets the bus)?

11. Waveform analysis: After you simulate, browse through the waveform to see if there are any “RED” areas on the data lines indicat-ing perhaps bus contention. Try to distinguish real bus contention from fictitious RED due to simulator behavior.If you buffer the contents of a floating bus, do you get floating output at the output of the buffer (when the buffer is in 2-state driving mode)? What do you expect to see on a real board and what do you expect to see in simula-tion?Did you see RED areas during READ cycles or WRITE cycles; during the beginning of the DEN activation time or towards the end of the DEN activation time; on the GMD (global memory data bus) or GD (global data bus) or on the BD (buffered data lines with in a processor node), if so in the 8086 processor node or in the 8088 proces-sor node; if it is 8086 processor node, is it on BD15_8 or BD7_0 ?

12. Run the design, hand in the schematic and waveforms (and answers to all questions)Compile the .c files of each processor.

compile_pcl global88.c 8088.PCL

compile_pcl global86.c 8086.PCL

Simulate using bus_arbitration_86_88.cmd. Include one copy of only those schematic sheets modified by you in your report. (bus_arbitration, 8088sub_sys, 8086sub_sys, glob_bus_controller,



7/28

bus_requester).

The transactions conducted in the global88.c and global86.c are shown below.

If your simulation is successful, you will be able to filter (using the following grep command) the successful messages from the log file as shown below. Take a printout of these successful messages and include in your report.nunki.usc.edu(2): more bus_arbitration.log | grep 8086up

| 8086up: writing 55H to loc. 68000. | 8086up: writing AAH to loc. 68001. | 8086up: reading back data from loc. 68000. | 8086up: local memory loc. 68000 write & read successful. | 8086up: reading back data from loc. 68001. | 8086up: local memory loc. 68001 write & read successful. | 8086up: writing 66H to loc. 09200. | 8086up: writing 99H to loc. 09201. | 8086up: reading back a word from loc. 09200. | 8086up: global memory word loc. 09200 write & read successful. | 8086up: writing 11BBH to word loc. 09202. | 8086up: reading back a byte from loc. 09202. | 8086up: global memory byte loc. 09202 write & read successful. | 8086up: reading back a byte from loc. 09203. | 8086up: global memory byte loc. 09203 write & read successful. | 8086up: reading loc. 00000 -- neither local, nor global.nunki.usc.edu(3): more bus_arbitration.log | grep 8088up| 8088up: writing 55H to loc. 68000. | 8088up: reading back data from loc. 68000. | 8088up: local memory loc. 68000 write & read successful. | 8088up: writing AAH to loc. 68003. | 8088up: reading back data from loc. 68003. | 8088up: local memory loc. 68003 write & read successful. | 8088up: writing 11H to loc. 09000. | 8088up: reading back data from loc. 09000. | 8088up: global memory loc. 09000 write & read successful. | 8088up: writing CCH to loc. 09003. | 8088up: reading back data from loc. 09003. | 8088up: global memory loc. 09003 write & read successful. | 8088up: reading loc. 00000 -- neither local, nor global.

Please make a readable set of plots for two sections of the final waveform showing a global transaction by 8088 processor and a global transaction for the 8086 processor. The global transaction section shall start with the start-ing bus-idle condition (BUSY = 1) and shall end with the ending bus-idle condition (BUSY = 1).

int l_byte_68000, l_byte_68003, g_byte_09000, g_byte_09003;/* ----------------------------------------- */ /* Write and read back a few local RWM locations *//* ----------------------------------------- */ write(0x68000,0x55); l_byte_68000 = read (0x68000); write(0x68003,0xaa); l_byte_68003 = read (0x68003);/* ----------------------------------------- */ /* Write and read back a few Global Memory locations *//* ----------------------------------------- */ write(0x09000,0x11);

g_byte_09000 = read (0x09000);

write(0x09003,0xcc); g_byte_09003 = read (0x09003);/* ----------------------------------------- */ /* read operation -- neither local, nor global */ read (0x0000);

int l_byte_68000, l_byte_68001, g_byte_09200, g_byte_09201;int g_word_09200, g_byte_09202, g_byte_09203;/* ----------------------------------------- */ /* Write and read back a few local RWM locations *//* ----------------------------------------- */ write( 1,0x68000, 0x55); write( 1,0x68001, 0xAA); l_byte_68000 = read (1 ,0x68000); l_byte_68001 = read (1 , 0x68001); /* ----------------------------------------- */ /* Write and read back a few Global Memory locations *//* ----------------------------------------- */ write(1,0x09200,0x66); write(1,0x09201,0x99); g_word_09200 = read (2,0x09200);/* ----------------------------------------- */ write(2,0x09202,0x11bb); g_byte_09202 = read (1,0x09202); g_byte_09203 = read (1,0x09203);/* ----------------------------------------- */ /* read operation -- neither local, nor global */ read (1 ,0x00000);

global88.c global86.c

Copyright 2005 Gandhi PuvvadaC


RESET = 0

BUSY = and/orBPRN=

BUSY = and/or

BPRN=

SYNC_GLOB_ACSS = 0

SYNC_GLOB_ACSS = 1

SYNC_RELEASE =

Qi

Qw

Qbm

Qd

BREQ = 1AEN = 1

BREQ = 0AEN = 1

BUSY = BREQ = 1AEN = 0

BUSY = BREQ = 1AEN = 1

BUS REQUESTER (runs on neg. edge of the bus clock BCLK)

EXERCISE

SYNC_RELEASE =

BUSY =

BUSY =

I = Idle state waiting for the processor to ask for a global accessW = Submit bus request and wait until grant is issued and bus becomes IDLEBM = Bus Master, wait until you may releaseD = Done; release the bus (BUSY = )

?

?

?

?

?

?

??

?

??



Qtw

Qti

Qta1

Qta2

Qta3

Qta33

QdRelease = 1

bus_enable = 1brd_wr_auth = 1

Release = 1bus_enable = 1brd_wr_auth = 1

Release = 0bus_enable = 1brd_wr_auth = 1

Release = 0bus_enable =brd_wr_auth =

Release = 0bus_enable = brd_wr_auth =

Release = 0 bus_enable = brd_wr_auth =

Release = 0bus_enable =brd_wr_auth =

Reset

=

= glob_acss = 1

= 0glob_acss = 0

=

SYNC_AEN

SYNC_AEN =

SYN

C_XA

CK

=

SYNC_XACK =

GLOBAL BUS CONTROLLER (runs on neg. edge of local processor clock CLK)EXERCISE

Ti = Idle state waiting for global access request by the processorTw = Wait until the Bus Requestor requests and gets the busTa1 = send out address onto the busTa2 = send out Read_Write requestTa3 = wait for XACK from the glob memTa4 = keep addr. for one clock before releasing the busd = done; release the bus and wait until

SYNC_A

EN

SYN

C_A

EN

you get a positive response

Qta4Release = 0

bus_enable =brd_wr_auth =

?

?

?

?

??

??

?

?

?

?

?

?

??



$3

I11

1


lab 28 bus arbitration objective: global domain · 2005. 4. 8. · bus arbitration logic and hidden...

Documents