CA1233265A - Data processor having multiple bus cycle operand cycles - Google Patents

Data processor having multiple bus cycle operand cycles

Info

Publication number
CA1233265A
CA1233265A CA000479228A CA479228A CA1233265A CA 1233265 A CA1233265 A CA 1233265A CA 000479228 A CA000479228 A CA 000479228A CA 479228 A CA479228 A CA 479228A CA 1233265 A CA1233265 A CA 1233265A
Authority
CA
Canada
Prior art keywords
operand
bus
cycle
address
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired
Application number
CA000479228A
Other languages
French (fr)
Inventor
David S. Mothersole
Jay A. Hartvigsen
Robert R. Thompson
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Motorola Solutions Inc
Original Assignee
Motorola Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Motorola Inc filed Critical Motorola Inc
Application granted granted Critical
Publication of CA1233265A publication Critical patent/CA1233265A/en
Expired legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38Information transfer, e.g. on bus
    • G06F13/42Bus transfer protocol, e.g. handshake; Synchronisation
    • G06F13/4204Bus transfer protocol, e.g. handshake; Synchronisation on a parallel bus
    • G06F13/4234Bus transfer protocol, e.g. handshake; Synchronisation on a parallel bus being a memory bus
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38Information transfer, e.g. on bus
    • G06F13/40Bus structure
    • G06F13/4004Coupling between buses
    • G06F13/4009Coupling between buses with data restructuring
    • G06F13/4018Coupling between buses with data restructuring with data-width conversion

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Bus Control (AREA)

Abstract

DATA PROCESSOR HAVING MULTIPLE BUS CYCLE OPERAND CYCLES

Abstract of the Disclosure In a data processor adapted to perform operations upon operands of a given size, a bus controller is provided to communicate the operands with a storage device having a data port which may be a submultiple of the operand size. In response to a signal from the bus controller requesting the transfer of an operand of a particular size, the storage device provides a size signal indicating the size of the data port available to accommodate the requested transfer.
Depending upon the size of the operand to be transferred and the size of the data port of the storage device, the bus controller may break the operand transfer cycle into several bus cycles in order to completely transfer the operand. In the process, the bus controller compensates for any address misalignment between the operand and the data port. In order to distinguish individual operand cycles from the several bus cycles which may comprise the operand cycle, the bus controller provides an operand cycle start signal only at the start of the first bus cycle of each operand cycle.

Description

I

DATA PROCESSOR HAVING MULTIPLE BUS CYCLE OPERAND CYCLES

Cross Reference to Related Applications Related subject matter is disco Ed in Canadian Patent Application Serial Number 479,213 entitled DATA PROWESSES
HAVING DYNAMIC GUS SIZING, inventors David S. Mother sole, Lester M. Crudely, James Tietjen and Robert R. Thompson, filed on April 16, 1985 and assigned to the Assignee hereof Field of the Invention The present invention relates generally to data processors and, more particularly, to a data processor which is capable of communicating operands using a plurality of consecutive bus cycles.

Background of the Invention In general, most data processors communicate operands with all of the different types of system resources using single bus cycles. However, data processors such as that described in cop ending Canadian Patent Application Serial Number 479,213 are capable of communicating with system resources having data port sizes which are a submultiple of the data port size of the data processor. Due to operand misalignment or port size incompatibility, operand cycles frequently extend over multiple bus cycles. Unfortunately, certain specialized types of system resources, such as emulators, bus state analyzers, and other debugging tools, need to be able to reassemble the bus cycles into the respective operand cycles. Heretofore, no known system provided such a capability.

Summary of the Invention Accordingly, it is an object of the present invention to provide a data processor which provides an output signal which distinguishes the first bus cycle of an operand cycle from subsequent bus cycles of the same operand cycle.

I,,.

- 1~33~6~:i More generally, it is an object of the present invention to provide the capability in any bus matter to provide an indication Which distingul~hes the fluorite buy cycle of an operand cycle from all subsequent bus cycles of that same operand cycle.
These and other objects are accomplished in a data processor which is adapted to communicate an operand with a storage device using an operand cycle comprising a plurality of bus cycles. In the preferred form, the data processor includes a circuit which provides a ~lgnal to the storage device during at least a portion of the first bus cycle of each operand cycle to indicate the tart of the operand cycle.
In a more general sense, the present invention may be used in any buy master which is adapted to communicate an operand with a bus slave using an operand cycle comprising a plurality of bus cycles. In this generic case, the buy master includes a circuit which provides an indication to the bus slave during at least a portly of the first bus cycle of each operand cycle to distinguish the start of the operand cycle.

grief ~escriptiQn of the Invention Figure 1 is a block diagram of a data processor having a buy controller constructed in accordance with the present in~entlon.
Figure 2 is a block diagram of the address bus interface of the data processor of Figure 1.
Figure 3 it a block diagram of the A and Al interfaces of the address bus interface of Figure 2.
Figure 4 is a detailed schematic of the address restore portion of the AYE interface of Figure I
Figure 5 it a detailed schematic of the A interface of Figure 3, the Al interface being identical.
Figure 6 is a block diagram of the A through Aye interfaces of the address bus interface Or Figure 2.

~L~3;~6~

Figure 7 lo e block dl~gra~ of the Aye through Aye interfaces of the Audrey buy lnterf~ce of Figure 2.
Figure 8 I a do d ~chematlc of the I interface of Figure 6, the A, A, A, ~10, Aye, ~14, Aye, ~18, ~20, A
Aye, Aye, Aye, ~30 end Aye lnterf~ce being identical.
Figure 9 I detailed schematic of the A lnterf~ce of figure 6, the do, A, A, dull, J~13, Aye, Jo Alp, Aye, Aye, Aye ~27, Aye and Aye interfaces being identical.
Figure lo I a block diagram of the data buy interface of the data processor ox Figure t.
Figure 11 I 8 detailed schematic diagram to the internal data buy recharge portion of the data buy interface of lure to .
Figure 12 I a detailed ~chematlc diagram of the input enable portion of the data buy interface of Figure 10.
Figure 13 lo a block dlagr&m of the Do through Do interfaces of the data bus interface of Figure 10.
Figure 14 I a detailed couch dlagra0 of the control for the D0-D7 interface of Figure 13.
Figure 15 I a block dl~gram of the Do through D15 interfaces of the data bus lnter~ace of Figure 10.
Figure 16, appearing with Figures 3 and 4, is a block diagram of the control for the D8-D23 interfaces of the data bus interface of Figure 15.

Figure 17 I a detailed catwalk diagram of the control for the D8-D15 interface of the data bus interface of Figure 16.
Figure 18 I a detailed ~chematlc diagram of the control for the Dl6-D23 interface of the data buy interface of Figure 16.
Figure 19 it brook diagram of the D16 through D23 interface of the data buy Inter foe of Figure 10.
lure 20 lo block diagram of the D24 through D31 lnterfa~e~ of the data bus interface of Figure 10.
Figure it I a detailed shoptalk dlagr~ of the D31 interface ox the data buy interface of Figure 20, nil of the other lnt~rface~ Do through D30 being identical.

I
it to I

Figure 22 I a detailed schematic diagram of the control of the D24-D31 interface of Figure 20.
Figure 23 it a block diagram of the buy controller of the data processor of Figure 1.
Figure 24 is detailed schematic diagram of the lye control circuit of the bus controller of Figure 23.
Figure 25 lo a detailed ~chematlc diagram of the byte latch control of the buy controller of Figure 23.
Figure 26 lo a detailed schematic diagram of the next address control of the byway controller of Figure 23.
Figure 27 , appearing with figures 3 and 4, us a detailed schematic diagram of the data address buffers of the buy controller of Figure 23.- -Future 28 is a block diagram of the mlcro~equencer of the bus controller of Figure 23.
Figure 29 lo a detailed schematic diagram of the data size input synchronizer of the mlcrosequencer of Figure 28.
Figure 30 Is a detailed schematic diagram of the termination control of the mlcrosequencer of Figure 28.
Figure 31 is a detailed schematic diagram of the state control of the mlcrosequencer of Figure 28.
Figure 32 1 a detailed ~chemstlc diagram Or the tart bug cycle control of the mlcrosequencer Or Figure 28.
Figure 33 it a detslled ~chematlc diagram of the operand cycle tart buffer of the mlcrosequencer of Figure 28.

pescriDtlon of the InventlQn Shown in Figure 1 I a data processor 10 oomprl~lng a central processing unit (CPU) 12, a bus controller 14, an address bus interface 16, a data bus interface 18, and a storage device 20. In general, the CPU 12 execute a user specified sequence of ln~tructlona, each of high lo compiled ox one or more blowout words. Each of these lnatructlon~ mutt be read from the storage Dallas 20 in the appropriate sequence. In the course of extolling each such ln~Sructlon, the CPU 12 may be required to perform a ~peclfled operation upon an 8-bit byte, a 1 6-bit word or a 32-b1t long word. Most of these data operands must be either read from or written to the storage device 20. In order to assure optimum performance on long word operations, the CPU 12 is provided with 32-bit data port. On the other Rand, it may be advantageous (or unavoidable that the storage device 20 have a data port which is smaller than that of the CPU 12. Even when the port sizes are the tame, the operand required by the CPU 12 may toll reside at an address within the Storage device 20 which does not align evenly with the data port of that particular storage device 20. It is the responsibility of the bus controller 14 to coordinate the activities of the address bus interface 16 and the data bus interface 18 in actually transferring the requested data or instruction operands between the CPU 12 and the storage device 20, regardless of operand misalignment or any mismatch between the port sizes of the CPU 12 and the storage device 20.
In general, the CPU 12 requests an operand transfer by aqsertlng an OPeration-PENDing signal (APPEND) to the buy controller 14. Simultaneously, the CPU 12 will provide a ReadtWrite-ReQuest signal (RQRW) indicating the direction of operand transfer and a Requested-Size signal ~RQStO:1]) $ndicatlng the size of the operand to be transferred. The CPU
12 also provides a 32-bit Address (Aye]) to or from Which the operand is to be transferred on a 32-bit Internal Address Bus (~IAB~0:31]).
Assuming for the moment that the CPU 12 has requested an operand write, the bus controller 14 will briefly assert a Start-OPerand-CYcle signal (SWOOPS) directing the address bus interface 16 to latch the operand address on the IAMB The bus controller 14 will also provide a buffered form of the SWOOPS as a brief Operand-Cycle-Start signal (-OHS) to indicate to the storage device 20 that the bus cycle Utah starting is the first bus cycle of an operand cycle. Simultaneously, the bus controller 14 will negate a TRISTATE signal (*TRISTATE~ to 3~6 enable the Audrey buy interface 16 to transfer the address to the storage device 20 on a blowout external ADDRESS BUS
(ADDRESS BUS). A brief time later, the buy controller 14 will assert an Addre~s-Strobe signal (WAS) to the storage device 20 indicating that a valid operand address it on the ADDRESS BUS.
The bus controller 14 will then assert a Data-Output-Buffer-to-Internal-Data-Bus signal (DOBIDB) directing the CPU
12 to provide the operand to the data buy interface 18 on a 32-bit Internal Data Bus (IDB[0:31]). The bus controller 14 will also provide to the data bus interface 18: a CURrent-Size signal (COORS]) indicating the size of the operand to be placed on the DATABASE; a DATA-ADDre~s signal (DOTTED) corresponding to the two low order address bits A and Al of the address on the ADDRESS BUS; and a CURrent-Read/~rlte signal (COWORKER) corresponding to the current state of the ROW
signal.
In the illustrated form, the ID is partitioned into four bytes: IO consisting of internal Data bits D31 through D24; It consisting of Data bits D23 through D16; It consi~tlng of internal Data bits D15 through Do; and It consisting of internal Data bits Do through DO. Depending upon the size of the operand being transferred, these internal bytes must be selectively coupled to the external DATABASE which is alto partitioned into four bytes: HO consisting of external Data blowout D31 through D24; En consisting of external Data bits D23 through D16; En consisting of external Data bits D15 through Do; and En consisting of external Data bit Do through DO.
Depending upon the current operand size (corset) and the current operand address (DOTTED]), the data bus interface 18 will provide the available bytes on the IAMB to the appropriate bytes on the DATABASE as follows:

CURS DOTTED DUETS
Q 1 0 1 HO El En En O O O O Tao O O O ~I~IQlIllI21 O O 1 O IIOII1 Isle l O O 1 1 lIQlIOlil RIO -0 1 x x I It I It l Ill % ! I ? lo l I 2 O x 1 lI~lI21I~lI?I
0 0 1UlI21I~!iQI
1 1 0 1 isle 1 1 1 0 Isle 1 1 1 1 II1II1li21IlI
where small "i" indicates a connection for convenience rather than a required connection. After the data bus interface 18 ha had sufficient lime to eatable the operand on the DATABASE, the bus controller 14 will assert a Data-Strobe signal (ADS) to advise the storage device 20 that the operand on the DATABASE it valid.
Upon receiving the Address-Strobe (WAS), the storage device 20 will decode the Audrey on the ADD~ESSBUS. If the address it determined to be within the Audrey range for that particular storage device 20, the storage device 20 will prepare to latch the operand. To best facilitate this, the storage device 20 has its data port connected to the DATABASE
90 that the high order byte ~00) of the data port of the storage device 20 will be aligned with the high order byte (EON of the DATABASE as follow:
ETA PORT HO El 2 En 32-bits 1001011D210~l 16-bits 100101 l Betty 10~1 Thus, upon receiving the Data-Strobe (ADS) 7 the storage device I will always be able to latch at least the high order portion ox the operand Turing the first buy cycle of every operand cycle. After successfully capturing the respective portion of the operand, the storage device 20 will provide a Data-tran~fer-and-S~ze-ACKnowledge signal ~DSACK[0:1]) acknowledging the operand transfer. In addition, however, the 4DSACK signal alto indicates the size of the data port of that particular storage device 20 as follow :
SACK WIDTH OF
Q 1 Data PORT
O O tubs cycle incomplete) 0 1 8-bits 1 0 Betty 1 1 32-bits Using the known operand Size (S[0:1]) and CURrent-ADdress (cardiology), and the size of the port (~DSACKtO:1]), the bus controller 14 can determine the size of residual portion of the operand, if any, which has not yet been received, as follows:
current returned : next cycle So SO Al A. DSACK1 Seiko : So SO don?
O 1 0 0 0 0 : x x 0100 0 1 :xxy 0 1 0 0 1 0 : x x y o 1 o o 1 1 : x x y 0 1 0 1 0 0 : x x 0 1 0 1 0 1 : x x y 0 1 0 1 1 0 : x x y 0 1 0 1 1 1 : x x y 0 1 1 0 0 0 : x %
0 1 1 0 0 1 : x x y 0 1 1 0 1 0 : x x y O 1 0 1 1 : x % y O 1 1 0 0 : x x 0 1 1 1 û 1 : x x y O 1 î 1 1 0 : x x y x x y current returned : next cycle So I Lo A DS,~CK1 Salk ,_ Seiko O O : x x 0 0 0 0 1 : 0 1 n 0 0 0 - O : x x y 0 0 0 1 1 : x x y 0 0 1 0 0 : x i 0 0 1 0 1 : 0 1 n 0 0 1 1 O : 0 1 n 0 0 1 1 1 : % x y 0 0 0 : X X
0 1 0 0 1 : 1 n 0 1 0 1 0 : % x y 0 1 0 1 1 : X X y 0 o : X X
0 1 1 0 1 : 0 1 n 0 1 1 1 0 : 0 1 n 0 1 1 1 1 : 0 1 n 0 0 0 0 : % x 0 0 0 1 : 1 0 n 0 0 1 0 0 1 n 0 0 1 1 : x x y 0 1 0 û : x x 0 1 0 1 : 1 0 n 0 1 1 0 : 1 0 n 0 1 1 1 : x x y 0 0 0 : x x 0 0 1 : 1 0 n 0 1 0 : 0 1 n 0 1 1 : 0 1 n 0 0 : x x 0 1 : 1 0 n t 1 1 1 1 0 : 1 Q n 0 n O O O O O O : x x current returned: next cycle So I Al AQDSACK1 SUE So I Dow?
O O O O 0 1 : 1 1 n O O O 0 1 0 : 1 0 n O 1 - 1 : x x y O O 0 1 0 0 : x x O O 0 1 0 1 : 1 1 n O O 0 1 1 0 : 1 1 n O O 0 1 1 1 : 0 1 n 1 O O : x x p O O 1 O 0 1 : 1 1 n O 0 1 0 O D 1 0 n O 0 1 0 1 1 : 1 0 n O 0 1 1 0 0 : x x O 0 1 1 0 1 1 1 n O 0 1 1 1 0 : 1 1 n O 0 1 1 1 1 : 1 1 n where: x -> don't care i => buy cycle incomplete y => operand cycle complete n => operand cycle incomplete Thus, for example, if the port size of the storage device 20 is the tame a the size of the DATABASE or if the lye of the operand is less than or equal to the port size of the storage device 20, the bus controller 14 will know that all of the operand hag been received and that the operand cycle can be terminated. At this time, if another bus master (not shown) it awaiting use of the communication bus, the bus controller 14 will assert the ~TRISTATE signal to force the address buy interface 16 to remove the address from the ADDRESS BUS. In any event, the bus controller 14 will then assert a Triqtate-Data-Bus signal t~TSDB) to force the data bus interface 18 to remove the operand from the DATABASE.
Simultaneously, the bus controller 14 will assert an OPerand-CYcle-COMplete sl~nal (OPCYCOM) to addle the CPU 12 I
, 1 that the requested operand write has been completed. Finally, the bus controller 14 will terminate the bus cycle by neBat~ng the Address and Data Strobes (-AS and ADS). In response, the storage device 20 will withdraw the SACK q~gnal. At this time, the communication buy again becomes available for use by the CPU 12 or any other bus master (not one which may be present in the system.
If additional bus cycles are required to complete the operand cycle, the bus controller 14 Jill recompute the two low order bits A and Al of the address of the residual operand as follows:
CURED SACK : NXTA address 1 0 1 0 : 1 0 rollover?
O O O O : % x p 0 0 0 1 : 0 1 n 0 0 1 Q : 1 0 n O O 1 1 : x x x 0 1 0 0 : x x p 0 1 0 1 : 1 0 n 0 1 1 0 : 1 0 n 0 1 1 1 : O O y 0 0 0 : % x p 1 0 0 1 : 1 1 n 0 1 0 : O O y 0 1 1 : O O y 0 0 : x x p 0 1 : O O y 0 : O O y : O O y where: x -> don't care p => buy cycle incomplete n -> no address rollover y _> address rollover.
The buy controller I will then provide a NeXT-Address signal (NXTA[0:1]) to the address bus interface 16 indicating the new L~33ZÇi5 low order address bit A and Al. If the communication bus has been used by a different bus master (not shown) since the previous bus cycle of the current operand cycle the bus controller 14 will assert an Address-Restore signal (RESTORE) requesting the address bus interface 16 to restore the original higher order address bits (idyll]), but use the two new low order address bits (NXTA[0:1]), On the other hand, if the new address bits have rolled over, the bus controller 14 will assert an Increment A Thor signal (IONIC) requesting the address bus interface 16 to increment the original higher order address bits (IDEA]), and use the incremented address together with the two new low order address bits (NXTA[0:1]). In anticipation of this request, the address bus interface 16 has already incremented the higher order address bits AYE. Thus, the bus controller 14 can immediately assert a Start-NeXT-Bus-Cycle signal (SNXTBC) requesting the address bus interface 16 to start the next bus cycle using the new address. From this point on, the bus controller 14 cooperates with the address bus interface I and the data bus interface 18 as described above, except that the Operand-Cycle-Start signal OHS will not be provided, thus distinguishing all such subsequent buy cycles from the first bus cycle of the operand cycle If necessary, this sequence is repeated until all of the requested operand has been received and latched into the storage device 20.
In general, the write operand cycle can be summarized with respect to any bus master writing an operand to a bus slave as follows:

BUS MASTER:
1) Briefly as oft Operand-Cycle-Start OHS
2) Drive Address on ADDRESS BUS
3) Drive Size (Sty])
4) Set Read/Write (ROY to Write
5) Assert Addre~s-Strobe (WAS)
6) Drive operand byte(s) on DATABASE
7) Assert Data-Strobe DO

BUS SLAVE.
1) Decode Address on ADDkESSBUS
2) Latch operand Betsy on DATABASE
3) Assert Data-transfer-and-S~ze-ACKnowledge (~DSACK[0:1]) GUS MRSTE~;
8) Negate Data-Strobe (ADS)
9) Negate Address-Strobe (WAS)
10) Remove operand byte from DATABASE

GUS SLAVE
4) Negate Data-transfer-and-Size-ACKnowledge (~DSACK~0:1]) GUS EASTER:
11) If all operand byte(s) not received, recompute Address and Size and return to I
12) Otherwise, operand cycle complete Aye now that the CPU 12 ha requested an operand read.
As in the write case, the bus controller 14 will again briefly assert the Start-OPerand-CYcle signal (SWOOPS) directing the address bus interface 16 to latch the operand Address on the IT The bus controller 14 will alto briefly assert the Operand-Cycle-Start signal OHS to indicate to the storage device 20 that the bus cycle just turtling it the first bus cycle of an operand cycle. Simultaneously, the bus controller 14 will negate XTRISTATE (if then averted) to enable the addre.qa bus interface 16 to transfer the Aiders to the storage device 20 on the ADDRESS BUS. The buy controller 14 will alto provide ROW in the Read state.
A brief time later, the buy controller 14 will surety WAS
to the storage device 20 indicating that a valid operand Address it on the ADDRESS BUS. Internally) the buy controller 14 will assert a Data bus-Start-PreCHarGe signal (DSPCHG) directing the data buy interface 18 to tart recharging the ID. In addition, the bus controller 14 will pays the current operand lye (COORS), the current low order address bits (DOTTED, and the current direction of operand transfer (COWORKER) to the data bus interface 18.
Upon receiving WAS, the storage device 20 will decode the address on the ADDRESS BUS. If the address it determined to be within the address range for that particular storage device 20, the storage device 20 will provide on the DATABASE a much of the requested operand as pueblo for the port size of that particular storage device 20. The storage device 20 will then provide SACK to indicate that the requested operand (or at least a portion thereof) lo available on the DATABASE. A
explained above, the SACK signal alto indicates the size of the data port of that particular storage device 20.
Depending upon the size of the port ~IDSACK[0:1~), the current operand size (COORS]) and adore s tDATADDDtO:1]), the data buy interlace 18 can determine which byte (Eta]) of the DATABASE are valid, as follow:
IDSACR CURS DOTTED : valid E byte 1 0 1 0 1 0 _ ROW :_ 0 1 2 x x % x x x O : O O O
x x O 1 0 0 : 1 0 0 0 o x n 1 o 1 1: 1 o o o x O 1 0 1 1 : 0 1 0 0 o X 1 1 o 1 : 1 o o o o o 1 1 o 1 : 1 o o 3L~3;~

ID SACK CURS DOTTED : valid E bytes 1 . _ 1_ 0 1 QRW : 0 1 2 _ 0 1 1 01 : O 0 1 0 O x 0 1 1 11 : 1 0 0 0 O 0 1 1- 11 : O 1 0 0 0 1 1 11 : O O O - 1 x x 1 0 0 01 : 1 1 0 0 O X 1 0 1 01 : 1 X O O
0 1 0 1 01 : 1 1 0 O
0 1 C1 : O 0 O x 1 0 0 11 : 1 0 x O
x 1 0 0 11 : 0 1 1 0 O x 1 0 1 11 : 1 0 x O
0 1 0 1 11 : O 1 x O
0 1 11 : O O x x x O O O O
O x O O O 11 : 1 0 x x % O O 0 11 : O
O x O 0 1 01 : x O O
0 0 0 1 01 : 1 1 0 0 0 0 1 01 : O O
O x O 0 1 11 : 1 0 x O
0 0 0 1 11 : O 1 x O
0 0 1 11 : O O x O x 1 1 0 11 : 1 0 x x x 1 1 0 11 : O
O x 1 1 1 01 : 1 x O O
0 1 1 1 01 : 1 1 0 0 01 : O 0 O x 1 1 1 11 : 1 0 x O
0 1 1 1 11 : 0 1 x O
O O x x % 1 1 0 01 : 1 1 1 x where x => don ' t care .

Depending upon the current operand lye (corset]) and the current operand address (DATAADDto~ the data bus interface 18 will couple the valid byte on the DATABASE to the proper byte(s) of the ID as described above. Using just the current operand Swiss), the buy controller 14 can then provide a Data-Bus-INput:Latch-Byte signet (DBINLB~0:3]) indicating which bytes (Iota]) of the ID are valid, as follow:
So SO : IO It It___ It O 0: 1 1 1 1 0 1 : O O 0 0 : O 0 In response to the DBINLB signal, the CPU 12 will latch the valid bytes provided by the data bus interface 18 on the ID
into the appropriate destination register (not Shown).
Using the current operand size sty]) and address tYCURADtO:1~) and the size of the port t~DSACK[0:1]~, the bus controller 14 can determine how much of the requested operand remains to be provided by the storage device 20, in a similar manner to that described above in the write case. Thus, for example, if the port size of the storage device 20 is tube same as the size of the DATABASE or if the lye of the operand is less than or equal to the port size of the storage device 2Q, the by controller 14 will know that all of the operand has been received and that the operand cycle can be terminated.
In this event, the bus controller 14 Jill terminate the bus cycle by negating WAS and ADS. Simultaneously, the bus controller 14 will assert ~TSDB to force the data bus interface 18 to decouple from the DATABASE. The bus controller to Jill also remove DBINLB and then assert OPCYCOM to advise the CPU 12 that the requested operand read ha been completed. A brief time later, if another bus master snot how) has requested the use of the communication bus, the bus controller 14 will assert ~TRISTATE to force the address bus - 17- issue interface 16 to remove the address from the ADDRESS BUS In response to the negation of WAS and ADS, the storage device 20 will withdraw the operand byte from the DATABASE, and then terminate SAC At this time, the ~ommunicatlon buy again becomes available for use by the CPU 12 or any other buy Easter (not shown) which may be present in the system.
If additional buy cycles are required to complete the operand cycle, the bus controller 14 will recompute the two low order bits A and Al of the address of the no ideal operand as described above. The bus controller 14 Jill then provide the address bus interface 16 with the new low order address bits A and Al tNXTA~0:1]). If the communication bus has been used by another bus master (not shown) since the previous bus cycle of the current operand cycle, the bus controller 14 will assert RESTORE requesting the address bus interface to restore the original hither order address bit (IDEA]), but use the two new low order address bits (NXTA~0:1]). On the other hand, if the new address bits have rolled over, the bus controller I will assert IONIC
requesting the address bus interface 16 to increment the original higher order address bits (IDEA]), and use the resultant address together with the two new low order address bits (NXTA[0:1]). As indicated before, the address bus interface 16 has already incremented the hither order address bits AYE in anticipation of this request. Thus, the bus controller 14 can immediately assert tSNXTBC) requesting the address bus interface 16 to tart the next bus cycle using the new address. From this point on, the bus controller 14 cooperates with the address bus interface lo and the data bus interface 18 as described above, except that the Operand-Cycle-Start signal OHS will not be provided, thus distinguishing all such subsequent bus cycle from the first bus cycle of the operand cycle. If necessary, they'll sequence it repeated until all of the requested operand hag been received and latched into the CPU 12.

In general, the read cycle can be summarized with respect to any bus master reading an operand from a bus slave as follow:
GUS MUTT
1) Briefly assert Oper~nd-Cycle-Start OHS
2) Set Read/Write to Read 3) Drive address on ADDRESS BUS
4) Drive Size (Stow 5) Assert Address-Strobe (WAS) 6) Assert Data-Strobe (ADS) US SLAVE:
1) Decode address on ADDRESS BUS
2) Drive operand byte(s) on DATABASE
3) Assert Data-transfer-and-Size-ACKnowledge (~DSACKtO:13) S MASTER;
7) Latch operand byte(s) into register 8) Negate Data-Strobe (ADS) 9) Negate Address-Strobe (WAS) Us YO-YO
4) Remove operand byte(s) from DATABASE
5) Negate Data-transfer-and-Size-ACKnowledge (~DSACK[0:1]) BY MATTER:
10) If all operand byte not received, recompute Address and Size and return to 2) 11) Otherwise, operand cycle complete A shown in Figure 2, the preferred embodiment of the Audrey bus interface 16 is comprised of an AYE interface 22, an AYE interface 24, sod an AYE interface 26. A can be seen in lure 3, the Oat interface 22 l comprised of an Address Restore 28, an A interface 30 and an Al interface 32 - 1 9 ~2~3~6~
which is identical to the A interface I Detailed schematic diagrams of the ADDRESS 28 and the A interface 30 are one in Flogger 4 and 5, respectively. A shown in Figure 6, the AYE interface 24 is comprised of A through Aye interface 34 through 62; respectively. Similarly, the AYE interface 26 is comprised of Aye through Aye interfaces 64 through 92, re~pecti~ely. A detailed schematic diagram is shown in Figure 8 of the A interface 34, the A, A, A, Aye, Aye, Aye, Aye, Aye, Aye Aye, Aye, Aye, Aye, and Aye interfaces 38, 42, 46, 50, 54, I 62, 66, 70, 74, 78, 82, 86 and 90, respectively, being identical. Similarly, a detailed schematic diagram is shown in Figure 9 of the A interface 36, the A, A, A, All, ~13, Aye, Aye, Aye, Aye, Aye, Aye, Aye, Aye, and Aye interfaces 40, 44, 48, 52, 56, 60, 64, 68, 72, 76l 80, I 88 and 92, respectively, being identical.
As shown in Figure 10, the preferred embodiment of the data bus interface 18 it comprised of an Internal Data Buy Recharge (IDBPCHG) 94, and INPUT Enable (INPUT EN) 96, a D0-D7 interface 989 a D8-D15 interface 100, a D16-D23 interface 102 and a D24~D31 interface 104. A detailed schematic diagram of the IDBPCHG 94 is shown in Figure 11. A detailed schematic diagram of the INPUT EN 96 is shown in Figure 12. As can be seen in Figure 13, the D0-D7 interface 98 is comprised of a D0-D7 Control (D07CTL) 106, and Do through Do interfaces 108 through 122, respectively. A detailed schematic diagram of the D07CTL 106 is shown in Figure 14. As can be teen in Figure 15, the D8-D15 interface 100 is comprised of a D8-D23 Control (D823CTL) 124, and Do through D15 interfaces t26 through 140, respectively. As shown in Figure 16, the D823CTL
124 is comprised of a D8-D15 Control (D815CTL) 142 and a D16-D23 Control (D1623CTL) 144. A detailed schematic diagram of the D8150TL 1~2 is shown in Figure 17. A detailed schematic diagram of the D1623CTL 144 is shown in Figure 18.
A can be teen in Figure 19, the D16-D23 interface 102 it compared of D16 through D23 interfaces 146 through 160, respectively. As can be teen in Figure 20, the D24-D31 interface 104 is compel Ed of a D24-D31 Control (D2~31CTL) 162, and D24 through D31 interface 164 through 178, respectively. A detailed schematic diagram is shown in Figure 21 of the D31 interface ~78, the Do through D30 interfaces 108-122, 126-140, 146-160, and 16~-176, respectively, being identical. A detailed schematic dram of the D2431CTL 162 is shown in Figure 22.
As shown in Figure 23, the bus controller 14 is comprised ox a SIZE circuit (SIZE) 180, a Byte LATCH enable circuit (BLOTCH) 182, a Next Address generator (NXT-ADD) 184, a DATA
Address buffer (DOTTED) 186, and a MICRO Sequencer (MICRO_ SEIKO) 188. A detailed schematic diagram of the SIZE circuit 180 is shown in Figure 24. A detailed schematic diagram of the BLOTCH 182 is shown in Figure 25. A detailed schematic diagram of the NXT-ADD generator 184 is shown in Figure 26. A
detailed schematic diagram of the DATA-ADD buffer 186 it shown in Figure 27. As can be seen in Figure 28, the MICRO-SEQUencer 188 is comprised of a Data Size Input Synchronizer (DSISYNCH) 190, a Termination Control 192, a State Control 194, a Strobe Bus Cycle control tSTBBC) 196, and an Operand-Cycle-Start Buffer (OCS_BUF) 198. A detailed schematic diagram of the DSISYNCH 190 is shown in Figure 29.
Q detailed schematic diagram of the TERMCTL 192 is shown in Figure 30. A detailed schematic diagram of the STATCTL 194 is shown in Figure 31. detailed schematic diagram of the STBBC
196 is shown in Figure 32. A detailed schematic diagram of the OCS-BUF 198 lo shown in Figure 33.
As will be clear to those skilled in the art, the CPU 12 may take any of a number of well known forms. For example, the CPU 12 may be constructed along the lines of that described in US Patent Number 4,325,121. On the other hand, the bus controller 14, address bus interface 16 and data bus interface 18 may be readily adapted to perform operand cycles for any of the other well known forms of bus matter such as direct memory access controllers and the like. Similarly, although the storage device 20 ha been described as being a memory device, the present invention is as readily adaptable to any of the other well known forms of bus slave such as peripheral controllers and the like, In any Or these forms, the assertion of the OHS signal by the buy matter will indicate that that particular bus cycle it the first bus cycle of a new operand cycle. Thus, each operand transfer may be readily distinguished from the bus cycle comprising that operand cycle.

Claims (8)

Claims
1. In a data processor adapted to be connected to a storage device to communicate an operand comprising m units of n bits each using an operand cycle comprising m consecutive bus cycles, each communicating a respective one of said units of said operand, the method comprising the step of:
providing an operand cycle start signal to said storage device only during a portion of the first of said bus cycles to indicate the start of said operand cycle, whereby the operand cycle start signal will distinguish the first of said bus cycles from all subsequent m-1 bus cycles comprising said operand cycle.
2. The data processor of claim 1 wherein said signal is provided substantially at the start of said first bus cycle.
3. The data processor of claim 2 wherein said signal is provided for only a predetermined portion of said first bus cycle.
4. The data processor of claim 1 wherein said signal is provided for only a predetermined portion of said first bus cycle.
5. In a bus master adapted to be connected to a bus slave to communicate an operand comprising m units of n bits each using an operand cycle comprising m consecutive bus cycles, each communicating a respective one of said units of said operand, the method comprising the step of:
providing an operand cycle start signal to said bus slave only during a portion of the first of said bus cycles to indicate the start of said operand cycle, whereby the operand cycle start signal will distinguish the first of said bus cycles from all subsequent m-1 bus cycles comprising said operand cycle.
6. The bus master of claim 5 wherein said signal is provided substantially at the start of said first bus cycle.
7. The bus master of claim 6 wherein said signal is provided for only a predetermined portion of said first bus cycle.
8. The bus master of claim 5 wherein said signal is provided for only a predetermined portion of said first bus cycle.
CA000479228A 1984-06-27 1985-04-16 Data processor having multiple bus cycle operand cycles Expired CA1233265A (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US62506884A 1984-06-27 1984-06-27
US625,068 1984-06-27

Publications (1)

Publication Number Publication Date
CA1233265A true CA1233265A (en) 1988-02-23

Family

ID=24504448

Family Applications (1)

Application Number Title Priority Date Filing Date
CA000479228A Expired CA1233265A (en) 1984-06-27 1985-04-16 Data processor having multiple bus cycle operand cycles

Country Status (3)

Country Link
EP (1) EP0185681A1 (en)
CA (1) CA1233265A (en)
WO (1) WO1986000431A1 (en)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2527458B2 (en) * 1988-03-04 1996-08-21 富士通株式会社 Data transfer control device

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4180862A (en) * 1976-07-01 1979-12-25 Gulf & Western Industries, Inc. Programmable controller using microprocessor
US4200916A (en) * 1976-07-01 1980-04-29 Gulf & Western Industries, Inc. Programmable controller using microprocessor
US4152764A (en) * 1977-03-16 1979-05-01 International Business Machines Corporation Floating-priority storage control for processors in a multi-processor system
JPS5557951A (en) * 1978-10-24 1980-04-30 Toshiba Corp Read control system of control memory unit
US4486830A (en) * 1982-03-30 1984-12-04 Cincinnati Milacron Inc. Programmable control apparatus and method

Also Published As

Publication number Publication date
WO1986000431A1 (en) 1986-01-16
EP0185681A1 (en) 1986-07-02

Similar Documents

Publication Publication Date Title
EP0185676B1 (en) Data processor having dynamic bus sizing
US5001624A (en) Processor controlled DMA controller for transferring instruction and data from memory to coprocessor
US4162520A (en) Intelligent input-output interface control unit for input-output subsystem
US4106092A (en) Interface system providing interfaces to central processing unit and modular processor-controllers for an input-output subsystem
US4100601A (en) Multiplexer for a distributed input/out controller system
EP0120889B1 (en) Direct memory access peripheral unit controller
CA1318037C (en) Data processing system bus architecture
US4074352A (en) Modular block unit for input-output subsystem
US5459839A (en) System and method for managing queue read and write pointers
US4631666A (en) Data transfer network for variable protocol management
US6047120A (en) Dual mode bus bridge for interfacing a host bus and a personal computer interface bus
US5564114A (en) Method and an arrangement for handshaking on a bus to transfer information between devices in a computer system
EP0141742A2 (en) Buffer system for input/output portion of digital data processing system
US5379386A (en) Micro channel interface controller
GB1574468A (en) Input-output subsystem in a digital data processing system
US5845145A (en) System for generating and sending a critical-world-first data response packet by creating response packet having data ordered in the order best matching the desired order
EP0288650B1 (en) Protocol and apparatus for a control link between a control unit and several devices
US6070208A (en) Apparatus and method for implementing a versatile USB endpoint pipe
EP0010187B1 (en) Input/output-system for a data processing system
EP0764907A1 (en) Method and system for error recovery in a data processing system
CA1233265A (en) Data processor having multiple bus cycle operand cycles
US4751632A (en) Data processor having multiple cycle operand cycles
GB1574470A (en) Intelligent input-output interface control unit for input-output system
EP0278263B1 (en) Multiple bus DMA controller
JPS63228856A (en) Communication controller

Legal Events

Date Code Title Description
MKEX Expiry