`
`
`
`0’
`
`Europfiisches Patentamt
`European Patent Office
`Office européen des brevets
`
`
`
`
`
`@ Publication number: 0 685 799 A1
`
`@
`
`EUROPEAN PATENT APPLICATION
`
`@ Application number: 95303697.?
`
`@ Int. CI.6: GOBF 13/40, G06F 13/38
`
`@ Date of filing: 31.05.95
`
`Priority: 03.06.94 us 253530
`
`Date of publication of application :
`06.12.95 Bulletin 95/49
`
`Designated Contracting States:
`DE FR GB
`
`@ Applicant: SYMBIOS LOGIC INC.
`2001 Danfield Court
`Fort Collins, Colorado 80525 (US)
`
`Multi-device connector.
`
`@ Inventor: Avery, James M.
`5231 McMurray Drive
`Fort Collins, Colorado 80525 (US)
`Inventor: lsenberg, William D.
`1937 Sandalwood Lane
`Fort Collins, Colorado 80526 (US)
`
`_
`_
`,
`Representative: Gill, Davrd Alan
`W.H. Beck, Greener & Co.,
`7 Stone Buildings,
`Lincoln’s Inn
`London WC2A 382 (GB)
`
`
`
`
`
`invention provides for a multi-
`@ The present
`device connector (16) which allows a device
`(14) to be connected to a bus (12), such as a
`system bus in a computer. The invention can
`comprise a device adapter which interfaces the
`device (14) to the bus (12), so as to represent a
`customized device adapter (16) and in particu-
`lar,
`the invention provides for a multi-device
`connector (16) comprising a bus interface for a
`computer comprising an adapter means
`for
`adapting a plurality of devices (14) to a com-
`puter bus (12), characterised by buffer means
`(22) for each device (14), for storing data, a data
`manager (20) for each buffer means (22),
`for
`controlling data transfers between said buffer
`means (22) and said bus
`(12), and control
`means (24)
`for each buffer means (22),
`for
`controlling data transfers between said buffer
`means (22) and a respective device (14) com-
`mon design macro, which is programmable. a
`user can easily specify and generate custom
`device adapters for a plurality of dissimilar de-
`vices to be connected to the bus. A resulting
`adapter architecture allows
`for multiple, dis-
`similar devices to interface to a computer bus
`with a single device adapter integrated circuit
`or card.
`
`
`
`BUSINTERFACE EP0685799A1
`
`
`
`'c:
`:3
`I:
`E
`F
`z
`
`CONTROLI
`
`CONTROLI
`
`._
`n.
`I)
`n:
`E
`I—
`a
`
`
`
`Jouve, 18, rue Saint-Denis, 75001 PARIS
`
`  
`
`

 
`
`OLYMPUS EX. 1008 - 1/39
`
`

`

`15
`
`20
`
`25
`
` 10
`
`30
`
`35
`
`EP 0 685 799 A1
`
`The present invention relates to a multi-device connector apparatus and in particular, but not exclusively,
`to a configurable device adapter for connecting dissimilar types of devices to a data processing system bus.
`This discussion will first explain a highly simplified data bus, and then illustrate how the simplified bus
`has evolved into a vast array of different types of data busses.
`It is known that different types of devices can generally be connected to a bus by different types of device
`adapters. However, device adapters do not necessarily result in optimal matching to a particular device, as
`will be explained later with particular reference to Fig. 1 below.
`The particular data-handling requirements of different devices, and the manner in which uncorrupted data
`transfer can occur from a first device which is ready to send data, and which knows that a second device is
`ready to receive that data, place particular requirements on device adapters which are disadvantageously not
`readily met.
`It is apparent that there are numerous design constraints which exist and trade-offs which are made when
`attaching a device to a bus. When designing an adapter to allow such attachment, Le. a device adapter, these
`design constraints and trade-offs result in a time consuming design effort for a particular type or class of de-
`vice(s). When a subsequent type or class of device(s) is to attach to this bus, a similar intensive design effort
`is required to create a device adapter for this new device. There is a need for a system which allows for para-
`meters, such as buffering specifications for a particular type or class of device, to be identified to a general
`purpose design macro, wherein a device adapter design is automatically generated which conforms to such
`user specified requirements. This device adapter design would thus be optimized for a given device which is
`to attach to a bus.
`
`The invention seeks to provide for a multi-device connector having advantages over known such connec-
`tors.
`
`According to one aspect of the present invention there is provided a multi-device connector comprising a
`bus interface for a computer for adapting a plurality of devices to a computer bus, characterised by buffer
`means for each device for storing data, a data manager for each buffer means for controlling data transfers
`between said buffer means and said bus, and control means for each buffer means, for controlling data trans-
`fers between said buffer means and a respective device.
`According to another aspect of the present invention a multi-device connector comprising an adapter card
`for communication with an expansion slot of a computerwhich connects to a bus in the computer, characterised
`by a plurality of buffer means, for storing data for a respective device, and means for multiplexing said plurality
`of buffer means with said bus.
`
`The invention can also provide for a multi-device connector for connecting multiple devices to a bus com-
`prising back end interface means, having different characteristics than those of said bus, and interface logic
`means for connecting the back end interface to the bus, said interface logic means comprising a plurality of
`device sub-adapters which couple the back end interface means to the bus, at least one of said plurality of
`device sub-adapters comprising one or more buffers, a data manager for controlling data transfers between
`the bus and the one or more buffers, and a controller for controlling data transfers between the back end in-
`terface and the one or more buffers.
`
`Further, the invention can provide for a multi-device connector comprising an electronic card for use in a
`computer with a bus characterised by a plurality of device sub-adapters, wherein at least one su b-adaptercom-
`prises a buffer, a data managerfortransferring data from the bus into the buffer, and a controller for transferring
`data from the respective buffer to a back end interface, and by an arbitration circuit which allows only a single
`data manager to communicate with the bus at a given time.
`The invention is advantageous in providing for an improved device adapter.
`Further the invention can also provide a device adapter which can be optimized, or tuned, to a given en-
`vironment.
`
`The invention can advantageously optimally match a bus with a plurality of different devices.
`Also, the present invention can advantageously provide a general purpose device adapter macro which
`can be customized, via user specified parameters, for a particular attaching device.
`Preferably, in one form of the invention, configurable device adapters are provided. The invention provides
`circuitry, for a particular type or class of device, which adapts the device to a bus. The individual circuitry for
`each device can be optimized, or "tuned," within certain parameter limits. Ageneral purpose macro is used in
`conjunction with user specified parameters for a particular device, to generate a customized, or tuned, device
`adapter design based on such user specified parameters. Accordingly, a large degree of specific design in-
`formation that would otherwise have to be manually provided by a user is automatically generated by use of
`the general purpose macro. The macro embodies a high degree of configuration to meeta wide variety of device
`support requirements. The user can thus configure the macro in such a way as to be tuned to meet particular
`system performance requirements.
`
`  
`
`

 
`
`OLYMPUS EX. 1008 - 2/39
`
`

`

`15
`
`20
`
`25
`
` 10
`
`30
`
`35
`
`55
`
`EP 0 685 799 A1
`
`The tunable architecture provides a basic architectural framework with contractual, or design-rules based,
`interfaces. By using contractual interfaces, the internals of a specific block can be configured without changing
`the interface design rules. With this concept, multiple behaviours and sub-block architectures can be imple-
`mented without changing the basic configurable macro concept.
`The invention is described further hereinafter, by way of example only, with reference to the accompanying
`drawings in which :
`Fig. 1 illustrates a simplified bus for data transmission;
`Fig. 2 illustrates a simple way oftransferring data from a 32-bit data bus to a receiver having an 8-bit data
`interface;
`Fig. 3 illustrates how the approach of Fig. 2 can be improved by the use ofa buffer,
`Fig. 4 is an overview of one form of the invention;
`Fig. 5 is a more detailed overview of one form ofthe invention;
`Fig. 6 shows internal interfaces having separated data and control;
`Fig. 7 shows a buffer configured as unidirection read/write;
`Fig. 8 shows buffers configured as separate read and write buffers;
`Fig. 9 shows multiple buffers configured as ping-pong or circular buffers;
`Fig. 10 illustrates a system board, for a computer, which contains the device adapter apparatus of Fig. 5;
`Fig. 11 illustrates an expansion card, for a computer, which contains the device adapter apparatus of Fig.
`5; and
`Fig. 12 is a process flow diagram for the design and manufacture of integrated circuits using the tunable
`macro.
`
`Fig. 1 illustrates a highly simplified example of data transfer over a bus. The transfer sequence is the fol-
`lowing, beginning at the top left part.
`1. The Sender places data onto the Data Lines, as indicated.
`2. The Sender pulls a Ready line HIGH, as indicated, thereby telling the Receiver that the Data is ready.
`3. In response, the Receiver collects the Data.
`4. The Receiver pulls the Acknowledge line HIGH, thereby telling the Sender that the Receiver has taken
`the data, and that another piece of Data can be placed on the Data Lines.
`5. The Sender detects the signal on the Acknowledge line, and pulls the Ready line LOW.
`6. The Receiver responds by removing the signal on the Acknowledge line.
`At this time, all lines are in theiroriginal conditions. The Sender may repeat the process by placing a second
`piece of Data onto the Data Lines.
`The exemplary transaction given above is a highly simplified example. Several examples of ways to im-
`prove and complicate the bus are outlined in the following:
`1. The Receiver may detect an error in the data, and may wish to request that a given piece of data be
`transmitted again. To accommodate this wish, an additional Repeat line can be provided, by which the Re-
`ceiver requests the repeated transmission.
`Thus, when the Sender receives a signal on the Repeat line, the Sender repeats the transmission.
`Conversely, if the Sender receives no such signal, but receives an acknowledge signal instead, the Sender
`sends the next piece of data.
`2. Assume that the Sender places a piece of data on the Data Lines, and pulls the Ready line HIGH. How
`long should it wait for the acknowledge signal? What does the Sender do if it receives no acknowledgment
`signal within the allotted time?
`One common approach to the problem is the following. If the Sender receives no acknowledgment
`signal within a specified time, then the Sender abandons the attempt to send data.
`However, another approach is based on the supposition that, if the Receiver is busy performing an-
`other task when the Sender wants to send data, nevertheless, the Receiver is willing to accept the data
`when the task terminates. Underthis approach, a Wait line can be provided. When the Sender sees a Wait
`signal, it does not abandon the attempt to send data, but waits for the Wait signal to disappear.
`3. Suppose that other devices besides the Receiver are connected to the data bus. However, the Sender
`wishes to send data to a specific device, and wishes others to ignore the data. Selection lines can be added
`which instruct a specific device to listen to the data.
`4. As in case 3, above, multiple devices are connected to the data bus. However, in contrast to the examples
`given above, now the devices wish to initiate communication: The devices now become Senders. Further,
`the devices simultaneously wish to send data. However, to allow them to do so would result in confusion.
`Asolution is to add Interrupt Lines. Each device asks permission, prior to sending data, by using the in-
`terrupt lines.
`There are numerous additional examples of additional types of lines which can be added to a bus, to pro-
`3
`
`  
`
`

 
`
`OLYMPUS EX. 1008 - 3/39
`
`

`

`15
`
`20
`
`25
`
` 10
`
`30
`
`35
`
`55
`
`EP 0 685 799 A1
`
`vide added features. Therefore, it is not surprising that numerous types of device interfaces exist, each with
`its own particular combination of lines and data transfer sequences.
`Further, a device interface to a bus does not operate in isolation: if the device and bus attain the highest
`possible speed between themselves, it is possible that this speed was obtained at a cost to some other com-
`ponents or devices.
`For example, assume that a bus couples together a processor and a printer. It is easy to see that very fast
`data transmission can occur ifthe processor devotes its full attention to the printer, and ignores all other de-
`vices on the bus, such as disc drives. However, under this scenario, the processor becomes unavailable for
`othertasks while tending the printer. Thus, while throughput of printed data is very high, other tasks have been
`brought to a standstill.
`Viewed another way, in this example, the processor is capable of transmitting data at a far higher rate than
`the printer can print it. Thus, in fact, during the full-attention printing, the processor will be spending idle time
`while the printer prints. The processor could be performing other tasks during this idle time.
`One solution to this type of problem is the use of buffering. Asimple example will illustrate.
`Assume that the Sender’s data bus is 32 bits wide, as shown in Fig. 2. Assume that the Receiver’s data
`bus is smaller, at 8 bits. Avery crude device adapter could operate as STEP 1 through STEP 4 indicate. The
`Adapter transfers data in eight-bit chunks. However, a problem with this approach is immediately apparent.
`While the Receiver may be receiving data as fast it can, the Sender is tied to the bus during the Receiver’s
`activity. The Sender can do nothing else. This approach is inefficient from the Sender’s view.
`As shown in Fig. 3, the Adapter can grab the entire 32-bit word from the Sender, and place the data in a
`Buffer. Now, the Buffer holds the data while the Adapter transmits it to the Receiver in eight-bit chunks. Now
`the Sender has been freed from waiting for the Receiver to receive the data.
`For sending data in the opposite direction, wherein the Receiver sends data to the Sender, the Adapter
`would perform the opposite sequence. The Adapter would collect data from the Receiver in eight-bit chunks.
`When 32 bits have accumulated in the Buffer, the Adapter sends the 32 bits to the Sender.
`While the buffering approach represents an improvement over the non-buffering approach, the buffering
`approach itself can be improved, by choosing the proper size of the buffers under the circumstances, as well
`as other parameters.
`The invention includes a method for dynamically configuring a device adapter for interconnecting devices
`to a common bus. Figs. 4 and 5 are views ofthe resulting apparatus for such connection. Several features are
`significant.
`1. A bus 12 is shown. Typically, the bus is a system bus in a micro-computer. Devices 14 do not directly
`communicate with the bus. Instead, the devices 14 communicate with a device adapter 16. The invention
`provides a method and apparatus for generating a device adapter 16 which allows a given device 14 and
`the bus 12 to communicate with each other. Aconfigurable macro can be produced that has the flexibility
`of generating a device adapter that supports multiple devices all ofthe same type or class, orthat supports
`multiple, dissimilar types of devices. Alternatively, and as a further exemplification of the flexibility of the
`present invention, the macro can be configured to provide separate device adapters for each interconnect-
`ing device (whether similar or dissimilar).
`2. These devices 14 can include normal peripheral devices, such as disc drives and printers, which are
`normally connected to or within a computer. In addition, these devices can include other apparatus, such
`as the following:
`-- video adapters,
`-- keyboards and pointing devices,
`-- multimedia adapters,
`-- memory controllers,
`-- memory and IIO cache,
`-- communication interfaces, and
`-- interfaces to other busses.
`
`In principle, there is no fundamental limit to the types of apparatus which can act as a device 14 in Fig. 4.
`3. In one embodiment, the generated device adapter presents a single load to the bus. One ramification
`of the single load concept is that the bus treats the device adapter, in general, as a single device. One
`exception is addressing: to select one of the four devices shown, the processor (not shown, but which is
`also connected to the bus) must supply an address to the device adapter which, in turn, selects the cor-
`responding device. If the device adapter were, in all respects, viewed as a single device by the processor,
`then the device adapter would only possess a single address.
`As a single load, the device adapter simplifies some overhead which the bus would otherwise incur.
`4. The generated device adapter is "tunable". Further, the tuning is done for each type or class of device.
`4
`
`  
`
`

 
`
`OLYMPUS EX. 1008 - 4/39
`
`

`

`15
`
`20
`
`25
`
` 10
`
`30
`
`35
`
`55
`
`EP 0 685 799 A1
`
`In the preferred embodiment, within the device adapter, there are buffers (BUF) devoted to each device,
`as indicated in Fig. 5. Because, in general, each device has different buffering needs, during design the
`device adapter is optimized for the best, or at least a good, buffer design for each device.
`Further, because of particular characteristics of the device adapter, to be discussed later, certain fea-
`tures of the buffers can be changed, without requiring alteration of other circuitry within the device adapter.
`5. Data and control are separated within the macro. Interface control mechanisms are specified indepen-
`dently from the data paths in the macro. By specifying the data paths independently, the control signal
`interfaces between functional blocks can operate on a variety of data interchanges without special control
`structures. As an example, the transfer of data to/from an interface can be controlled in a similar fashion
`regardless of the length of the data transfer. The control interfaces operating in contractual agreement
`provide the mechanisms to initiate, terminate and monitor the data interchange without regard to the data
`contents.
`
`Acomputer listing forthe software (i.e. macro) used in creating and generating a configurable device adap-
`ter can be achieved. The macro requires a VHDL compiler. VHDL compilers are commercially available. VH DL
`is an acronym referring to VHSIC Hardware Description Language. VHSIC is an acronym referring to Very High
`Speed Integrated Circuit.
`A commercially available VHDL compiler known as V-System VHDL Simulator and Compiler Platform Re-
`vision 2.5, available from Model Technology, located Beaverton, Oregon can be used for this purpose.
`To design a customized device adapter, the macro is used in two differentways, namely, (1) in synthesizing
`a gate-level logic diagram, and (2) in simulating the circuit.
`
`Synthesis
`
`To perform synthesis, a user does the following:
`1. The user specifies the following parameters:
`-- The width of the device interface (e.g., 8, 16, or 32 bits).
`-- The address size (i.e. number of bits) of the device interface.
`-- The depth ofthe buffer contained in the device adapter (number of bits). The buffers are explained
`in greater detail later.
`-- Buffer packing.
`These parameters are specified by inserting them into the file of the macro labeled PCIMACRO_USER_PAR—
`AMS.VHD.
`
`2. The user can compile the design, using a commercially available synthesis engine such as Design Ana-
`lyzer 3.00, available from Synopsis Incorporated, Mountain View, California. For compilation, the user
`should load the macro files, described later in Table 2 in the following order:
`configurable_dword_reg.vhd,
`pcimacro_user_params.vhd, macro_pkg.vhd,
`configurable_bit_reg.vhd,
`clktree.vhd,
`signaltree.vhd, burst_size_cntr.vhd, next_addr_cmpr.vhd, new_transfer_counter.vhd,
`con-
`trol_reg.vhd, dm_bk_sm.vhd, dm_fe_sm.vhd, data_manager.vhd, address_counter.vhd, devsel_timer.vhd,
`master_latency_timer.vhd,
`parity36.vhd,
`target_latency_timer.vhd,
`master_state_machine.vhd,
`slave_state_machine.vhd, pci_fsm.vhd, cycler.vhd, cc_bk_sm.vhd, cc_bypass_sm.vhd, cc_fe_sm.vhd, cy-
`cle_controller.vhd, dpr_gen.vhd, pipeline_block.vhd, valid_data_counter.vhd, address_pointer.vhd, buffer_ele-
`ment.vhd, memory_element.vhd, output_latch.vhd, new_fifo.vhd,
`fifo.vhd, byte_steering_logic.vhd,
`bist_reg.vhd, class_code_reg.vhd, command_reg.vhd, device_id_reg.vhd, header_reg.vhd,
`interrupt_li-
`ne_reg.vhd,
`interrupt_pin_reg.vhd, max_lat_reg.vhd, min_gnt_reg.vhd,
`revision_id_reg.vhd,
`sta-
`tus_reg.vhd, vendor_id_reg,vhd, high_bit_reg.vhd, base_address_reg.vhd, rom_base_address_reg.vhd,
`miscelaneous_configuration_regs.vhd, config.vhd, bk_end.vhd, pci_macro.vhd, nan2.vhd, dfqu.vhd,
`dffrpq.vhd, or2.vhd, hbuf.vhd, sbuf.vhd, inbuf.vhd, inpd.vhd, inv.vhd, iobuf.vhd, iobufpci.vhd, iopdl6.vhd,
`iopd12s1.vhd,
`iobuf_iopd1251.vhd, opdl6.vhd, otpdl6.vhd, bus_hbuf.vhd, bus_inbuf.vhd,
`iopdpci.vhd,
`bus_inv.vhd, bus_opd16.vhd, iobuf_iopd16.vhd, configured_pci_macro.vhd
`The product of the synthesis is a gate level diagram or netlist. A netlist is a description of how gate cells
`are connected together. An exemplary netlist is the following:
`AND1 2 4 10
`0R1 101214
`
`This list indicates that AND gate 1 has two inputs. One is connected to node 2, and the other is connected
`to node 4. The output is connected to node 10. The list indicates that OR gate 1 has two inputs. One is con-
`nected to node 10 (which is the output ofthe AND gate) and the other is connected to node 12. The output is
`connected to node 14.
`
`Therefore, the synthesis engine, togetherwith the macro and specified parameters, synthesize a gate level
`5
`
`  
`
`

 
`
`OLYMPUS EX. 1008 - 5/39
`
`

`

`15
`
`20
`
`25
`
` 10
`
`30
`
`35
`
`55
`
`EP 0 685 799 A1
`
`diagram. Synthesis requires a cell library, which provides the building blocks for the gate-level circuit. Ase-
`lected cell library is used for a given technology (e.g. CMOS, bipolar, etc.). Cell libraries are commercially avail-
`able, and are known in the art. The preferred cell library is the NCR VS500 standard cell library, available from
`AT&T Global Information Solutions Company in Dayton Ohio.
`This gate-level diagram will, ultimately, be fabricated into one or more integrated circuits and/or cards
`which implement the device adapter.
`Prior to fabricating the integrated circuits, two types of simulation are performed. Afunctional simulation
`is performed prior to synthesis, and a gate-level simulation is performed after synthesis. To perform functional
`simulation, the user specifies the parameters, as in the synthesis step above, and then compiles and simulates
`the macro using a compiler/simulator such as the V-System VHDL Simulator and Compiler Platform, available
`from Model Technology, Beaverton, Oregon. Gate-level simulation is performed, after synthesis, to generate
`test vectors which will be used in testing the circuit after fabrication. To perform gate-level simulation, a gate-
`level diagram or netlist (as generated from the synthesis step) is input to a physical design simulator such as
`the Verilog Simulator available from Cadence Design Systems Inc., San Jose, California (and whose corporate
`office is located in Lowell, Massachusetts).
`After synthesis and simulation, the netlist generated by the synthesis step is processed by a routing pro-
`gram, such as Tancell version 2.4.0. which is also available from Cadence Design Systems. The routing pro-
`gram produces a machine language representation of each layer of the integrated circuit to be fabricated. In
`effect, the routing step produces multiple layout diagrams, each of which describes a different level of topology
`of the integrated circuit to be fabricated.
`The product/output of the routing step is a database. This database is then used to generate the masks
`used in fabrication of the integrated circuits, using techniques commonly known in the art.
`Once the masks are generated, one or more integrated circuits are fabricated, using techniques commonly
`known in the art. The overall process flow is illustrated in Fig. 12. It should be noted that adapter cards can
`also be built using similar physical layout design tools and techniques commonly known in the art.
`Fig. 5 illustrates an overview of the resulting gate-level schematic, grouping the gates according to task
`or function. That is, for each device sub-adapter:
`-- one group of gates will operate as a data manager (DATA MGR);
`-- one group of gates will operate as a buffer (BUFFER);
`-- one group of gates will operate as cycle control logic (CYCLE CONTROL); and
`-- one group will operate (optionally) as user logic (USER LOGIC).
`As Fig. 5 indicates, each device sub-adapter 18 has its own data manager 20, buffer 22 and cycle controller
`24, all of which were generated in the synthesis step. The optional user logic 26 is defined by the user, inde-
`pendent of the macro, for adapting a given device 14 to the back end interface 28 of the device sub-adapter
`18. The user logic comprises such things as simple gating, device specific logic, or any other special require-
`ments, such as synchronizing all signals presented to, or received from, the back end interface (if necessary
`for a particular device). In addition, the macro generates a single finite state machine (FSM) 30 which deals
`with all data managers for a particular device adapter integrated circuit or card 16.
`The blocks of Fig. 5 operate generally as follows (some exceptions will be noted later).
`The data manager 20 controls data transfers between the bus 12 and the buffer 22. That is, the bus 12
`(through the finite state machine) deals with the data manager. The data manager has three control lines (Re-
`quest, Acknowledge and Interrupt) coupled to the bus via bus interface 13, and an internal bus 15 coupled to
`the finite state machine 30.
`
`The buffer 22 holds the data temporarily. The buffer is preferably of the First-In, First-Out (FIFO) type.
`The cycle control logic 24 controls data transfers between the back end device 14 and the buffer. That is,
`the device (perhaps through the User Logic) deals with the cycle control logic. In a sense, the data manager
`and the cycle control logic cooperate to perform data transfers: the former deals with the bus, and the latter
`deals with the back end device.
`
`Asingle finite state machine 30 controls all data managers 20 for a given IC or card 16. The primary func-
`tion of the finite state machine is to arbitrate contention between devices 14. That is, if two devices 14 attempt
`to communicate with the bus 12 simultaneously, the finite state machine requires one of them to wait.
`The macro is composed of a set of functional blocks (e.g. finite state manager, data manager, buffer, cycle
`controller) which are themselves expandable. The interfaces between these functional blocks are contractual,
`or rule-based, interfaces with variable timing and word width specifications. For example, a buffer block could
`be configured to have either a 1 byte deep FIFO or a 4K byte deep FIFO, without changing the interface con-
`tracts/rules. It is therefore possible to configure a variable data width path for buffers without changing the
`cycle controller interface contract. In this way, the cycle controller would still perform its functions in a data
`independent way.
`
`  
`
`

 
`
`OLYMPUS EX. 1008 - 6/39
`
`

`

`15
`
`20
`
`25
`
` 10
`
`30
`
`35
`
`55
`
`EP 0 685 799 A1
`
`Data and control are separated within the macro. Interface control mechanisms are specified indepen-
`dently from the data paths in the macro. By specifying the data paths independently, the control signal inter-
`faces between functional blocks can operate on a variety of data interchanges without special control struc-
`tures. As an example, the transfer of data to/from an interface can be controlled in a similar fashion regardless
`of the length of the data transfer. The control interfaces operating in contractual agreement provide the mech-
`anisms to initiate, terminate and monitor the data interchange without regard to the data contents. That is to
`say, no control operations are contained in the data stream. All control operations involving cooperating func-
`tional blocks are contained in the control interfaces.
`
`The internal bus having separated data 25 and control 27 paths is shown in Fig. 6. The internal bus 32 is
`coupled to internal interfaces (l/F) for the finite state machine 30, data manager 20, buffer 22, and cycle con-
`troller 24 functional blocks. The external bus interface 13 similarly has separated data and control, as indicated
`by the thin (control) and thick(data) lines between the FSM 30 and the bus 12. The exported HF 29 corresponds
`to the conglomeration of all back end interfaces 28 of Fig. 5. Fig. 6 also shows multiple instantiations for the
`various functional blocks (except forthe FSM, of which only one exists for a given device adapter, as previously
`described). Each instantiation of a functional block also has an interface l/F which couples the particularfunc—
`tional block to the internal device adapter bus.
`A detailed description for each functional block of Fig. 5 follows.
`
`Bus Interface/Finite State Machine
`
`The macro generates a single bus interface for a given device adapter. This bus interface provides the
`electrical interface between the bus 12 and the device adapter IC or card 16. The bus interface couples the
`bus to a finite state machine 30 which manages data flow between the bus and the (one or more) data man-
`ager(s). The key component of the bus interface function is contained in the module named PCI_FSM (or front
`end bus finite state machines). There are two independent state machines within the finite state machine 30
`which are responsible for bus interface operations, one for slave operations and one for master operations.
`Each of the master/slave state machines perform bus interface functions.
`As an example ofthe slave state machine, when the bus 12 is in an address phase, the configuration logic
`(as generated by the config.vhd macro file) will indicate a back end device is being accessed. As soon as ac-
`cess is determined to belong to one of the backend device interfaces to the macro, the address on the bus is
`loaded into an internal address register within the finite state machine. The bus cycles are then translated into
`internal control signals for the internal bus 32 of Fig. 6. For each subsequent data phase, the configuration
`logic must still validate the internal address.
`When a back end device 14 requests and is granted the bus, the master state machine outputs the internal
`address on the bus data pins, and asserts the proper bus signals to start a bus transfer. Once the finite state
`machine detects a valid bus cycle, the finite state machine will start issuing data phases to the bus 12.
`The only macro resource that is shared among multiple data manager and cycle controller interfaces is
`the finite state machine 30. This guarantees that only one back end resource will be granted bus access at
`the appropriate time. Backoffs to back end devices will be issued if the bus resource is busy.
`
`Data Manager/Cycle Controller Pairs
`
`The device sub-adapter 18 is structured so that cycle control and data management facilities work in pairs.
`Therefore, each back end interface 28 that is substantiated for a given device sub-adapter 18 necessitates
`the parameterization and inclusion of a data manager 20 and cycle controller 24 block pair (along with the buffer
`block(s)). Data transfers to/from device su b-adapter configured buffers and the front end and back end buses
`are orchestrated by the data manager and cycle controller, through contractual interfaces.
`Each buffer configured into the macro requires a separate data manager. If a configuration is desired where
`the READ/WRITE buffers are to be separated and independent, then two data managers are necessary, one
`for the READ direction, and another for the WRITE direction. The cycle controllerfacility orchestrates all data
`transfers to/from internal buffers and the back end interface through its contractual interfaces with other co-
`operating functional blocks or exported interfac