Europaisches Patentamt
`European Patent Office
`Office europeen des brevets
`
`© Publication number : 0 6 8 5 799 A 1
`
`EUROPEAN PATENT A P P L I C A T I O N
`
`19
`
`12
`
`© Application number : 95303697.7
`
`© int. ci.6 : G06F 13/40, G06F 13/38
`
`(22) Date of filing : 31.05.95
`
`(§) Priority : 03.06.94 US 253530
`
`(43) Date of publication of application :
`06.12.95 Bulletin 95/49
`
`@ Designated Contracting States :
`DE FR GB
`
`(ft) Applicant : SYMBIOS LOGIC INC.
`2001 Danfield Court
`Fort Collins, Colorado 80525 (US)
`
`(54) Multi-device connector.
`
`(57) The present invention provides for a multi-
`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.
`
`o>
`ro-
`t a
`oo
`CO
`
`LU
`
`(72) Inventor : Avery, James M.
`5231 McMurray Drive
`Fort Collins, Colorado 80525 (US)
`Inventor : Isenberg, William D.
`1937 Sandalwood Lane
`Fort Collins, Colorado 80526 (US)
`
`(74) Representative : Gill, David Alan
`W.H. Beck, Greener & Co.,
`7 Stone Buildings,
`Lincoln's Inn
`London WC2A 3SZ (GB)
`
`.
`
`L
`no
`O
`S3
`
`
`J
`\^ mo
`33
`
`\
`
`rr 0
`LLI frj
`S3
`
`\
`ceo
`^ LU Trj
`3s
`
`6 a£
`
`V 1
`
`I Sir
`TTT
`
`TTT
`
`TTT O^l—
`lUOi
`cc<2
`
`TTT O^l— LUOQ-
`rr<^
`
`LU LLI LUZ
`LI- CO <
`
`CO
`CO
`
`LU 1 O
`1—
`
`Jouve, 18, rue Saint-Denis, 75001 PARIS
`
`HUAWEI EX. 1008 - 1/39
`
`

`

`EP 0 685 799 A1
`
`2
`
`40
`
`45
`
`50
`
`55
`
`5
`
`10
`
`ls
`
`30
`
`35
`
`20
`
`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, i.e. 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
`25 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 computer which 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
`computerwith a bus characterised by a plurality of device sub-adapters, wherein at least one sub-adapter com-
`prises a buffer, a data manager for transferring 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. A general 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 hig h degree of configuration to meet a 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.
`
`HUAWEI EX. 1008 - 2/39
`
`

`

`EP 0 685 799 A1
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`so
`
`55
`
`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 of transferring 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 of a buffer;
`Fig. 4 is an overview of one form of the invention;
`Fig. 5 is a more detailed overview of one form of the 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. Under this 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.
`A solution 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
`
`HUAWEI EX. 1008 - 3/39
`
`

`

`EP 0 685 799 A1
`
`5
`
`10
`
`15
`
`30
`
`35
`
`20
`
`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 if the 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
`other tasks 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. A simple 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.
`25 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 of the 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. A configurable macro can be produced that has the flexibility
`of generating a device adapter that supports multiple devices all of the same type or class, or that 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 I/O 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
`
`40
`
`45
`
`so
`
`55
`
`HUAWEI EX. 1008 - 4/39
`
`

`

`EP 0 685 799 A1
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`so
`
`55
`
`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-
`turesof 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.
`A computer listing for the 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. VHDL
`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 different ways, 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 of the 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.0c, 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:
`pcimacro_user_params.vhd, macro_pkg.vhd,
`configurable_dword_reg.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_state_machine.vhd,
`master_latency_timer.vhd,
`parity36.vhd,
`target_latency_timer.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-
`mentvhd, memory_element.vhd, outputjatch.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, interruptji-
`sta-
`ne_reg.vhd,
`interrupt_pin_reg.vhd, max_lat_reg.vhd, min_gnt_reg.vhd,
`revision_id_reg.vhd,
`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, dffpq.vhd,
`dffrpq.vhd, or2.vhd, hbuf.vhd, sbuf.vhd, inbuf.vhd, inpd.vhd, inv.vhd, iobuf.vhd, iobufpci.vhd, iopdl6.vhd,
`iopd12s1.vhd, iobuf_iopd12s1.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
`OR1 10 12 14
`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 of the 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
`
`HUAWEI EX. 1008 - 5/39
`
`

`

`EP 0 685 799 A1
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`diagram. Synthesis requires a cell library, which provides the building blocks for the gate-level circuit. A se-
`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 specif ies 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
`1 8. 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-ln, 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.
`A single 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.
`
`6
`
`HUAWEI EX. 1008 - 6/39
`
`

`

`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