Background Of The Invention 1. Field of the Invention The field of the present invention relates to electronic hardware, including virtual, component design. In particular, the field of the present invention relates to the interfaces between components.

2. Background The methodologies for designing, testing and manufacturing integrated circuits (ICs) continue to evolve. Today, with the continually increasing complexity and density of ICs, designing for reusability is becoming an overriding priority. One consequence of this priority is the increasing distinction of between the developers of potentially reusable functional component blocks, that when used with each other provide the foundation for an IC or the design of an IC, and the integrators of such blocks. A number of companies focus on the development of such functional block components. Some of the same companies as well as many others perform the integration and/or manufacturing of the ultimate ICs.

One of the new developments in circuit designs is the advent of so-called virtual component blocks, which, from a general standpoint, are pre-designed and pre-hardened (or semi-hardened) circuit designs in software form (for example, in GDSII format), which can be readily re-used or recycled in different, larger circuit designs. An advantage of virtual component (or VC) blocks is that they reduce the time to design an overall circuit, and thereby, increase the speed to market.

The breakdown of IC development into the design of discrete functional components, and the fact that there are many providers of such components, has in part been responsible for the creation of a need to have a standard interface for communicating between components. This is one of the goals of the Virtual Socket Interface Alliance (VSIA) Virtual Component Interface (VCI) Standard. A draft of this

standard, Standard 2 Version 1.0 (Working Revision (2/2/2000) is attached as an appendix. To meet this stated goal, which includes objectives of connectability, flexibility, and portability of component blocks, the VCI protocol, as outlined in the specification, has been developed with an eye towards simplicity.

A preference for simplicity in the VCI protocol, in turn, has necessarily led to certain requirements to which component blocks that adopt the protocol must adhere. A first requirement is that one side of the interface is required to act as a master or initiator of a communication and the other side is required to act as a slave or target for the communication. As such, the design of the target interface has inherent differences from that of the initiator interface. Specifically, each side of the interface, by definition, comprises different logic to enable each side to perform its predefined role in the communication. Because of these complementary functions, the inputs and outputs on each side of the interface are also different from each other. The pins on each side of the interface to which connections are made represent a type of signal input or output that is generally specific to that side of the interface.

Another requirement is that the VC Interface of a functional block be a unidirectional interface. Output pins on one side of the interface are connected to input pins on the other side of the interface, such that signals travel in only one direction for a given connection.

Thus, functional components (including virtual components (VCs)) that include a VC interface can act only as targets or initiators in a point-to-point communication. As such, in any communication between two components, if one component is defined as a master, the other must be a slave, and vice versa.

In any methodology for designing ICs based on predefined component blocks, one of the first steps is to specify, as a starting point, the component blocks that will be used as the foundation of the design. One such component block that is identified at this stage is the foundation block, a block that typically comprises a processor, some memory and a communication block. The communication block has the primary purpose of transferring data from one place to another, an in the context of IC design includes a bus connected to multiple I/O ports. The foundation block often manages the communication between most if not all of the other component blocks to be used in the IC. Because it includes a communication block, the foundation block typically includes on its edges a large number of ports, of which some are initiators and others are targets. Because of the requirements of standard protocols such as the VCI protocol, the type of interface at a particular location on the edge of a foundation block must be predefined. Thus, characterizing the

foundation block that is to be used for a given IC typically requires specifying a bus and the number, locations and types of ports on the edges of the block. For example, one common layout of ports for a foundation block is to position them evenly around the foundation block to provide for floor-planning flexibility.

One of the next steps is specifying the placement of the component blocks, including the foundation block, to form the layout of the IC. In this process, chip designers try to minimize wire lengths between pins of different components and minimize the overall area or footprint of the IC. Increasingly, these connection distances are the greatest speed-limiting factor in efforts to increase the speed and performance of an IC.

To assist in optimizing the layout of the IC, chip designers often use electronic design automation (EDA) software tools. The component blocks are automatically "placed" (i. e., given specific coordinate locations in the circuit layout) and"routed" (i. e., wired or connected together according to the designer's circuit definitions). The placement and routing software routines generally accept as their input a flattened netlist that has been generated by a prior logic synthesis process. This flattened netlist identifies the specific components from a component library, and describes the specific component-to-component connectivity. After this specific connectivity has been established, the physical design and layout software creates a physical layout file of the integrated circuit, including the physical position of each metal line (i. e., wire) and each via (i. e., metal transition between chip layers).

Further explanation of a particular chip design process is set forth, for example, in U. S. Patent 5,838,583, hereby incorporated by reference as if set forth fully herein.

Because the ports for the foundation block are specified before the layout process can be performed, the flexibility in component block placement is potentially limited by the locations and types of ports that have been specified.

Essentially, the capability of optimizing a design footprint or achieving minimum connection lengths, and thereby, the IC's overall speed and performance, is compromised.

A need exists therefore, for a way of optimizing for speed and performance in an electronic design without incurring the limitations inherent in a predefined foundation block or other functional block.

Summary Of The invention The present invention, in one aspect, provides a systems and methods for designing an integrated circuit and for creating and using an androgynous interface between electronic components of an integrated circuit.

In one embodiment, an androgynous interface for communicating between electronic components having multiple connection points includes a circuit for a state machine and a plurality of pins connected to the circuit. The implementation of the state machine is preferably configured to perform as a target and an initiator of a communication. The plurality of pins preferably corresponds to a set of target signals for handling communication involving the component as a target and a set of initiator signals handling communication involving the component as an initiator.

In one preferred embodiment, the pins are each unidirectional and include at least one input pin and at least one output pin. Preferably, the number of input pins is preferably equal to the number of output pins and the set of target signals is symmetric with the set of initiator signals.

In another aspect, an electronic component includes the above-described androgynous interface. In yet another aspect, an electronic component that includes the above-described androgynous interface is modeled with the assistance of a computer.

In another aspect of the present invention, an integrated circuit includes a bus, a plurality of functional blocks and a plurality of ports, where each port connects the bus to one of the plurality of functional blocks. Each of the plurality of ports preferably is designed to perform as both a target and an initiator of a communication.

In yet another aspect, a computer-assisted model of an integrated circuit includes a bus model, a number of functional block models, and a corresponding number of port models, where each port model connects the bus model to one of the functional block models. Each of the plurality of port models preferably is designed to perform as both a target and an initiator of a communication.

In yet another aspect, a method of designing an integrated circuit includes several steps. In one step, a foundation block for the integrated circuit is specified, including specifying the locations of multiple androgynous interfaces in the integrated circuit. In another step, one or more component blocks to comprise the integrated circuit are identified. In another step, the component blocks to form a layout of the integrated circuit are positioned in a manner that minimizes connection distances between functional blocks and between functional blocks and the

androgynous interfaces of the foundation block. In another step, the androgynous interfaces are set to perform as targets or initiators based on the layout.

Further embodiments, variations and enhancements are also disclosed herein.

Brief Description Of The Drawings FIG. 1 is a diagram of a computer system that may be used in connection with various embodiments of the invention as described herein.

FIG. 2A is a diagram of a simplified integrated circuit as may be generated using a computer system such as shown in FIG. 1, before the component blocks have been placed on the integrated circuit chip.

FIG. 2B is a diagram of a simplified integrated circuit as may be generated using a computer system such as shown in FIG. 1, after the component blocks have been placed on the integrated circuit chip.

FIG. 3 is a diagram of a general process flow for a block-based integrated circuit design.

FIG. 4 is a flow diagram detailing a preferred method of designing an integrated circuit.

FIG. 5 is a table depicting an example of a set of signal designations implementing a symmetric androgynous communication interface.

FIG. 6 is a diagram depicting communications system between two components that employs an androgynous interface between the components and a generic communication bus.

FIG. 7 is a table depicting a mapping of signal designations to translate between a blocks using an androgynous virtual component interface protocol and a bus employing a System-on-Chip (SOC) protocol.

FIG. 8 is a timing diagram depicting the operation of a system employing an androgynous communication interface that allows one side of the interface operating as an initiator to transition to a target interface type, and vice versa.

Detailed Description Of The Preferred Embodiments Preferred embodiments will now be described, with reference as necessary to the accompanying drawings. First, however, additional information is provided concerning electronic design methodology and the use of automation (EDA) in such a methodology.

Chip designers generally use a top-down design methodology, starting with hardware description languages (HDLs), such as Verilog3 or VHDL, for example, to create an integrated circuit by hierarchically defining functional components of the

circuit, and then decomposing each component into smaller and smaller components. The components used in integrated circuits can be characterized as either functional or communication components or blocks.

From the HDL or other high level description, the actual logic cell implementation is typically determined by logic synthesis, which converts the functional description of the block into a specific circuit implementation of the block.

The circuit implementation typically exists as a netlist, comprising logic cells or component blocks and including one or more communication blocks. The component blocks are then placed and routed, resulting in a physical layout file.

The physical layout file is generally used as a design"blueprint"for fabrication of the integrated circuit. At each stage of the design process, as well as at the fabrication stage, various tests may be run to ensure correct operability of the circuit design.

FIG. 1 is a diagram of a computer system that may be used in connection with various embodiments of the invention as described herein. As shown in FIG. 1, a computer system 100 includes a computer 110 connected to a display 191 and various input-output devices 192. The computer 110 may comprise one or more processors (not shown), as well as working memory (e. g., RAM) in an amount sufficient to satisfy the speed and processing requirements of the system. The computer 110 may comprise, for example, a SPARC workståtion commercially available from Sun Computers, Inc. of Santa Clara, California, or any other suitable computer.

The computer 110 contains stored program code including, in one embodiment, a block floorplanner 120, a block placer 130, a logic synthesizer 135 and a routing space estimator 140. The block floorplanner 120 provides for the definition of block functions, block regions, and constraints on these for the purpose of interactive floorplanning operations by the circuit designer, and the control of placement operations of the block placer 130. The block placer 130 determines the placement of cells within blocks according to the constraints defined by the circuit designer. The routing space estimator 140 estimates routing space required for routing the blocks, given the placement of such blocks by the block placer 130.

In support of the above-mentioned system components, a chip floorplanner 150, global/detail router 160, standard cell placer 170, logic synthesizer 180, and HDL editor 190 may be usefully employed. Operation of the chip floorplanner 150, global/detail router 160, standard cell placer 170, logic synthesizer 180, and HDL editor 190 is conventional, as the design of these components is well known in the art of electronic design automation. Commercially available examples of these

system components are Preview, Cell3 QPlace Synergy and Verilogo, respectively.

The computer 110 is preferably coupled to a mass storage device (e. g., magnetic disk or cartridge storage) providing a layout database 195 with which the foregoing system components interface. The layout database 195 may be implemented using the EDIF database standard. The computer 110 may also comprise or be connected to mass storage containing one or more component libraries (not shown) specifying features of electrical components available for use in circuit designs.

Referring now to FIG. 2A, there is shown a block illustration of a simplified IC 200 before the design of the IC has been completed, wherein a foundation block 202 and a number of peripheral component blocks B1,..., B12 have been specified, but where the actual connections between blocks remain undetermined. In actual, more realistic integrated circuit designs, the integrated circuit 200 would be far more complicated. However, FIG. 2A is useful for purposes of illustration. The foundation block preferably includes a processor 204, a memory 206, several other component blocks, A1,... A5, and a communication block comprising a bus 208 and twelve androgynous ports 210. The ports 210 are androgynous because they may be configured as targets or initiators in the communications interface after the layout of the IC 200 has been finalized. Finalizing the layout preferably requires placing the other IC components B1,..., B12 on the chip. The foundation block 202, including its components (the processor 204, the memory 206, and components, A1 through A5), and the other peripheral component blocks are preferably fully characterized in the layout database 195.

FIG. 2B is a diagram depicting the results of placing the component blocks, B1 through B12 on the chip. Preferably, the blocks have been placed in a manner that is optimal with respect to location and the lengths of the connections to the ports on the foundation block. The placement, however, does not account for an interface type for a particular port on the edge of the foundation block because each port is androgynous and the same as every other port on the block. That is, no port is "hardened"to perform as a target or an initiator. Thus, the placement of the blocks, B1 though B12 is preferably optimized towards other considerations.

FIG. 3 is a diagram of a general process flow 300 for a block-based circuit design, illustrating some of the various levels of integrated circuit design abstraction as described above. As illustrated in FIG. 3, a register transfer logic (RTL) file 301 in the form of an HDL file or other high level functional description undergoes a specification (floor planning and part assignment) process 302. In this process 302,

component blocks are identified from a component library 306 to perform specific functions set out in the RTL file 301. The component blocks are preferably predefined, and although one or more may be based on a customized design not stored or only recently stored within the library 306.

In the next step 303, a form of logic synthesis performed, where in one preferred embodiment, the functional description of the connections between the components is converted into a specific connection implementation which may be stored in the form of a netlist file 304. As part of this compile process 303, the component library 306 is generally referenced, which stores information concerning the androgynous interface, and the characteristics of the components which are needed in order to determine their functional connectivity. The netlist file 304, as previously noted, generally identifies the component blocks from the library 306, and describes the specific component-to-component connectivity.

By application of a physical design process 309 shown in FIG. 3, the component blocks of the netlist file 304 are then placed and routed, resulting in a layout file 310. The component library 306 is utilized in this process stage in order to obtain information concerning the sizes of the components that may be present in the netlist file 304. Previously, this information includes interface specifications, such as the whether the numbers and locations of the interfaces, whether each interface is a target or initiator, the number of pins and their signal assignments. As described in the background section above, the placement and routing operation is then performed and may be automated in a manner to optimize the ICs ultimate performance by minimizing connection lengths and the IC's overall footprint. This placement and routing process however, adheres to the interface specifications obtained from the component library 306.

From the layout file 310, a verification process 312 may be run, as further illustrated in FIG. 3, resulting in a mask file 315 in, for example, a GDSII or CIF format. The mask file 315 may be provided to a foundry, and contains enough information to allow the foundry to manufacture an actual integrated circuit therefrom.

In one aspect, systems and methods are provided in connection with certain embodiments disclosed herein for designing integrated circuits and for creating and using an androgynous interface between electronic components of an integrated circuit.

FIG. 4 details a preferred method 400 for designing an IC such that the layout is optimized without having to adhere to specifications regarding the whether a port is a target or an initiator. In a particular embodiment, the ports that are unspecified,

as to being targets or initiators, are on the IC's foundation block, which includes a processor, memory, and a communication block that specifies a bus and a plurality of ports that will in operation perform as either targets or initiators. In a first step 402, the communication block (or the complete foundation block) is specified. This communication block may be extracted from the component library as part of a logic synthesis operation or may be originally designed. The communication block preferably is specified with a particular bus configuration and footprint on the IC chip. The communication block is further described by a fixed number of ports and particular locations around the block. Each port is defined to be androgynous such that at this stage of design, it can be later adapted or bound to perform as a target or an initiator.

In a next step 404, other component blocks are specified. Like the communication block, these other component blocks are preferably identified as part of a process or program to synthesize logic and produce a netlist file. Because steps 402 and 404 relate to the specification of different components, in an alternative embodiment, the steps 402,404 may be switched in order or performed at the same time.

In a next step 406, the blocks are laid out on the IC. In this step 406, which may be performed automatically, the layout of the blocks on the IC is optimized to keep connection lengths between input and output pins on different block to a minimum. Furthermore, the blocks are preferably organized such that the overall area of the IC is also minimized.

In a next step 408, each of the androgynous interfaces on the communication block are adapted to perform as a target or an initiator based on the required type of interface for the block connected to the interface by the layout provided by step 406.

In an alternative embodiment, the androgynous interface is designed such that ports on the IC perform, in an operational environment, as targets and initiators of communications.

A number of methods exist to adapt the androgynous interfaces to perform as either targets or initiators. In one preferred embodiment, the interface logic includes configuration registers to enable the setting of one side of the interface as a target or an initiator. When configured as a target, the sets of pins are configured to receive or transmit signals according to the protocol for the target. When configured as an initiator, preferably the same set of pins is used to transmit and receive signals according to the protocol for an initiator.

In another embodiment, an interface type parameter is input to a logic synthesis operation that synthesizes away the state machine configuration that is not

used for actual operation of the IC. Preferably, what remains is the state machine for the interface that is selected using the logic synthesis parameter. Alternatively, the parameter is used to generate the logic for the selected interface type. The androgynous interface, however, is configured such that the same pin connectivity is maintained regardless of which interface type is selected.

In another embodiment, a pin on the androgynous interface is tied to a logical 1 or 0 based on whether the interface is to operate as a target or initiator. The logic to control the interface is therefore preferably configured to operate as a target or initiator depending on the value of the input received using the additional pin.

The androgynous interface preferably exhibits certain general characteristics.

On a basic level, the androgynous interface includes logic and)/0 structure to perform both as a target or an initiator. That is, the interface includes a set of pins, where each pin has a signal designation, a signal direction, and a specification for a corresponding pin to which it connects. Thus, the set of pins includes a sufficient number of pins to include all of the signals that are received or transmitted by a target and all of the signals that are received or transmitted by an initiator. In one embodiment, each pin in the set of pins is dedicated to perform a target function or an initiator function. In an alternative embodiment, some or all of the pins have target or initiator signal specifications that depend on a setting of the interface to perform as one or the other. Optionally, this setting is dynamic, such that the interface switches roles from one communication to the next. As another option, the setting is part of an initialization of the device on start-up. Alternatively, the setting is hardwired or is otherwise fixed in the interface logic. Advantageously, in the configuration in which the pins are configurable with respect to interface type, fewer pins are employed to implement the interface.

As a specific preferred characteristic, the androgynous interface includes the same number of input lines as output lines. That is, the set of pins includes equal numbers of input pins as output pins. Applying this criterion, when an androgynous interface is set for use as a target or initiator, fewer, if any, pins need go unused or be tied off.

As a more specific preferred feature, the androgynous interface is a symmetric interface. With this feature, the interface includes the same number of input pins as output pins. Furthermore, each pin includes a signal designation in a role as a target pin and a signal designation in a role as an initiator pin. In addition, the corresponding pin to which a given pin connects preferably has the same dual functionality, but in particular instances always employs the signal designation that is complementary to that of the given pin.

In each of the above embodiments, the logic used to implement the androgynous interface may be fully hardware implemented, may include software- coded elements or may be fully implemented in software using a general or special purpose processor.

In a preferred embodiment of the symmetric androgynous interface, the interface is an extension of the unidirectional interface described in the VSIA VCI Standard. In one embodiment, the androgynous interface is the virtual component (VC) interface that includes hardware that performs the logic set out in the VSIA. In another embodiment, the androgynous interface comprises generalized computing hardware that is loaded with the protocol to execute as a VC interface.

Therefore, the androgynous interface includes a set of signals that follow the VC interface protocol, but can be used either as an initiator, a target or both. This permits the number of VC interfaces to be defined later during the foundation block integration, and then even later define the size and type of each interface.

FIG. 5 depicts a preferred embodiment of a signal map for a symmetric androgynous interface adapted from the Basic VC interface (BVCI) disclosed in the VSIA VCI Standard. To adapt the BVCI to be a symmetric androgynous interface, the names of the signals are reversed, to consider"R"as received instead of response.

In the BVCI, the Error signal does not exist, but is specified for the androgynous VC interface. Furthermore, the Wrap, Const, Contig signals in BVCI are assumed to be part of the Cmd signal in the androgynous VC interface depicted in FIG. 5. Additional return signals are defined for androgynous interface, such as Cmd, Clen, Cfix, which do not have return signals in the BVCI. However, the specification of these signals enables both sides of the androgynous VC interface look the same, and therefore creates an androgynous interface that is symmetric. The target and initiator sides of the interface have the same number of pins, the same connections, and pin designations.

In a preferred embodiment, the interface that first issues a data valid signal preferably becomes the initiator. The other side then automatically becomes the target and acknowledges the data valid signal. The target then may issue a data valid signal in response to each acknowledged data valid signal it receives. The initiator then issues an ACK signal. The end of the packet on the data valid side preferably is sent with an EOP signal, and the end of the response packet is preferably sent with an EOP signal. The response EOP signal preferably indicates that the interface is waiting to determine who next is the initiator.

A key advantage offered by this symmetry is that the state machine logic is essentially the same regardless whether the interface acts as a target or initiator. Little

additional logic is needed to enable the interface to operatively perform as a target or initiator.

In another alternative embodiment of a symmetric androgynous interface, the interface is integrated into bus wrappers, including a target wrapper and an initiator wrapper. The bus wrapper defines a package that translates the protocol for a particular bus type into an androgynous VCI protocol. Thus, functional components that adhere to the androgynous protocol can communicate using any bus that includes an androgynous VCI bus wrapper. FIG. 6 depicts a configuration 600 for communicating between two components 602,604 that employ a VC interface. A component block 602 performs as an initiator and includes an initiator interface 606.

Another component block 604 correspondingly performs as a target and includes a target interface 608. The two components 602,604 communicate via a bus 610, that may be of any convenient type, by virtue of an initiator wrapper 612 and a target wrapper 614 that translate the signals in the VCI protocol to the bus protocol and vice versa. The initiator wrapper 612 preferably includes a VCI target interface 616, a bus master interface 618, and interface-to-interface translation logic.

Correspondingly, the target wrapper 614 includes a VC initiator interface 620, a bus slave interface 622, and interface-to-interface translation logic.

In one preferred embodiment, the mapping, performed by the target and initiator wrappers 614,612 implements a translation of the System-on-Chip (SOC) standard to an androgynous symmetric adaptation of the VC interface, and vice versa. In this embodiment, in relation to FIG. 6, the bus 610 complies with the SOC standard. FIG. 7 is a table depicting an example of the signal mapping for these two interfaces.

The androgynous VC interface is similar to the SOC standard in that first, both preferably use a four-wire protocol. In the androgynous interface, a req->gnt signal is used for writes from initiator to target and a rreq-> rgnt signal is used for the return reads from the target to the initiator. Second, the interface standards have the same EOP and Cmd (command) structure. Third, the interface standards preferably have the same data and address structure.

With respect to the differences, preferably no byte enables, non-sequential addressing, or chaining modes are used. Also, an r cmd signal, an r error signal and an r d size signal are added to make the VC interface symmetric. Further, the androgynous interface preferably uses an additional parameter MASTER that may be set. If MASTER is set, then the interface to the functional block is a master. The wrapper for the interface then employs the mapping on the left side of FIG. 7. If

MASTER is not set, then the interface for the functional block is a slave, and the wrapper for the interface employs the mapping on the right side of FIG. 7.

Optionally, to dynamically change between initiator and target protocols on one interface, two signals may be passed between the VCI wrappers: <BR> <BR> I/T T/I<BR> R_IT <-IT IT R IT The IT signal is preferably set by the side that is the initiator, and the target preferably responds by clearing its IT signal. Subsequent requests are then considered errors if the responding IT signal is set or the wrapper's IT signal is cleared. This additional handshake protocol is optionally used in other embodiments.

FIG. 8 depicts an example of transactions between two blocks A and B. FIG.

8 depicts a window in time when the androgynous interfaces are in an idle state, preferably enabling the interfaces to switch interface types, from initiator to target and vice versa. Initially, Block A is the initiator and transmits a request to Block B.

Block B then responds to the request to complete the transaction. Before the issuance of the request and after the response is received, the interfaces for the blocks are in an idle state. It is during this time that the interfaces may switch interface types. After the response by Block B, the types are switched, as evidenced by the issuance of a request by Block B, demonstrating that it is now an initiator.

Only after Block A completes the transaction by issuing a response to Block B's request do the interfaces return to an idle state, enabling an interface type switch by the two interfaces.

As discussed above, the androgynous interface alternatively is designed to allow both interface types to be available in one physical interface for any given communication operation. A single physical interface potentially avoids issues that arise due to the fact that two interfaces take up actual loading on the bus and typically require additional pins. Two separate interfaces, however, are optionally employed if both target and initiator operations are needed at the same time.

In other embodiments, the androgynous interface may be implemented as a bi-directional interface, where signals for a given pin are both input and output signals. The androgynous interface may be adapted to other implementation of the VSIA VCI Standard including the Peripheral and Advanced VC interfaces.

In another embodiment, the use of an androgynous interface may be employed with pin unscrambling systems and methods as described in our

copending application entitled'Adaptable Circuit Blocks for Use in Multi-Block Chip Design,"having attorney docket number 260/089, and filed January 18,2001.

The above-described embodiments describe the implementation and use of androgynous interfaces in the context of component blocks that communicate with or between integrated circuits. However, the generalized embodiments of the androgynous interface are preferably used in other contexts that involve communication blocks that transfer information from one point to another. In the IC context, the communication block includes a bus (either bi-directional or unidirectional and employing multiplexers) and multiple androgynous ports off of the bus. In other contexts, the communication block may be a crossbar-switch, a hub, a router, a network, or a memory such as a FIFO that is employed to transfer data. In these other contexts, the communication block includes a set of appropriate androgynous interfaces. Thus, the androgynous interfaces disclosed herein may be generally applied to other areas of electronic communication.

While preferred embodiments of the invention have been described herein, and are further explained in the accompanying materials, many variations are possible which remain within the concept and scope of the invention. Such variations would become clear to one of ordinary skill in the art after inspection of the specification and the drawings. The invention therefore is not to be restricted except within the spirit and scope of any appended claims.

VSI AllianceTM Virtual Component Interface Standard (OCB 2 1.0) On-Chip Bus Development Working Group Standard 2 Version 1.0 Working Revision (2/2/2000) This draft Specification is provided for review purposes only. VSI Alliance has no obligation to issue the draft Specification in its current form or in any other form. The draft Specification may describe technology, which is patented or subject to other intellectual property claims of third parties.

Release of the draft Specification for review purposes does not mean that the owner of the patents or other intellectual property rights has authorized the use thereof in the Specification or will do so in any version of the Specification which VSI Alliance may hereafter release.

Members of the Development Working Group ARM Cadence Co-design Basics ECSI Fujitsu GDA Tech Hitachi HP LSI Logic Lucent Nokia OKI Palmchip Philips Phoenix Siemens Sonics ST Microelectronics Synopsys Toshiba Xilinx Active Contributors Bruce Mathewson......................................... ARM Larry Cooke* (Ex Chair).................................. Cadence Mani Gopalakrishnan*................................... Fujitsu J. Sukarno Mertoguno* (co Chair)...................... Fujitsu Prakash Bare*.............................................. GDA Tech Janet Wedgwood............................................ Lockheed Martin Rick Born*.................................................. LSI Anssi Haverinen* (Chair)................................ Nokia Frits Zandveld*............................................ Philips Amjad Qureshi............................................ Phoenix David Jennings............................................ Siemens John Carey*.............................................. ST Microelectronics Graham Matthew* (Ex Chair)............................ ST Microelectronics Mike Meyer.................................................. Sonics Drew Wingard*....................................... Sonics Greg Tanaka............................................. Synopsys Frank Vahid.............................................. Univ Calif Prof. Ganesh Gopalakrishnan........................... Univ Utah Glen Baxter................................................ Xilinx Other Contributors John Cornish..................................................... . ARM Larry Rosenberg................................................... Cadence Peter Flake....................................................... . Co-design Tony Gore........................................................ . ECSI Gerry Caracciolo.................................................. . Eigen Tek Glen Vinogradov.................................................. independent Yuji Hatano...................................................... ... Hitachi Osamu Yamashiro Hitachi Won Rhee........................................................ ... HP Alex Kurosawa.................................................... Sonics Charles Minter..................................................... Toshiba Joseph Hassoun..................................................... Xilinx *-Major contributors TABLE OF CONTENTS 1. VIRTUAL COMPONENT INTERFACE (VCI) BACKGROUND 1 1. 1 GOALS.....................,................................. ...,.,...................................................... ........................................... 1 1. 2 KEYASSUMP7'IONS............................................. ....................................................,....... .................,................ 2 1. 3 DOCUMENT CONVENTIONS 2 1.4 DOCUMENT ORGANIZATION................................................ ............................................................ .................. 3.

2. VCI CHARACTERISTICS _ 4 2.1 VCI DEFMTION, 4 2.2 POINT TO POINT USAGE 4 2.3 SPLIT PROTOCOL 5 2. 4 VCI USAGE WITH A BUS 5 2.5 NOTES 6 3. PERIPHERAL VCI......................................................... ............................................................ ............................ 7 3.1 OVERVIEW ............................................................ ............................................................ ....................... 7 3.1.1 Scope 7 3.7.2 Organization : : 7 3.2 TECHNICAL INTRODUCTION TO PERIPHERAL VCI ............................................................ ..................................... 8 3.2.1 Initiator-Target Connection 8 3.2.2 The Handshake 8 3. 2.3 Request and Response Contents @ 9 3.2. 4 Main Peripherla VCI Features:................................................... ............................................................ .... 10 3.3 SIGNAL DEFINITIONS ............................................................ ............................................................ .................. 11 3.3.1 System Level Signals ............................................................ ............................................................ ........ 12 3.3.2 Control Signals 13 3.3.3 Address and Data Signals ............................................................ ............................................................ 14 3.3.4 Error Signals ............................................................ ............................................................ .................... 16 3.4 PVCI PROTOCOL.................................................... ............................................................ ............................ 17 3.4.1 Operation Types 17 3.4.2 Handshake Protocol.................................................... ............................................................ ............. 18 3.4.3 Data Formatting and Alignment 20 4. BASIC VCI i 22 4.1 OVERVIEW 22 4. 1.1 Scope ............................................................ ............................................................ ................................... 22 4. 7. 2 Organization................................................ ............................................................ .............................. 22 4.2 TECHNICAL INTRODUCTION TO THE BASIC VCI......................................................... ......................................... 22 4.2.1 Initiator-Target Connection.................................................. ............................................................ 22 4.2.2 The Handshake 22 4.2.3 The Default Acknowledge................................................. .,.......................................................... ........ 23 4.2.4 Cells, Packets, and Packet Chains 24 4.2.4.1 Cell :........................................................... ............................................................ ...................... 24 4.2.4.2 Packet 24 4.2.4.3 Packet Chain 24 4.2.5 Request Contents.................................................... ............................................................ .................. 24 4.2.5. 1 Operation Code (opcode).................................................... ............................................................ . 25 4.2.5.2 Packet Length and Chaining 25 4. 2.5.3 Address And Data 25 4.2.6 Response Contents.................................................... ............................................................ ....................... 26 4.3 BASIC VCI SIGNAL DESCRIPTIONS ............................................................ ......................................................... 26 4.3.1 Signal Type Definition.................................................. ............................................................ ................. 26 4.3.2 Signal Parameters 27 4.3.3 Signal Directions 27 4.3.4 Signal List 27 4.3.5 System Level Signals 29 4.3.6 Request Signals..................................................... ............................................................ ................... 30 4.3.7 Response Signals..................................................... ............................................................ .......,......... 34 4.4 BASICVCIPROTOCOLG 37 44. 1 Protocol Fundamentals, 37 4.4.1.1 Transaction Layer ............................................................ ............................................................ ........ 37 4. 4. 1. 2 Packet Layer 37 4. 4. 1. 3 Cell Layer 38 4. 4. 2 Basic VCI Operations.................................................. ............................................................ ................. 42 4. 4. 2.1 Read Operation,,"42 4. 4. 2.2 Write Operation 43 4. 4. 2.3 Other Operations 45 4. 4. 2. 4 Address Modes....................................................... ............................................................ .............. 46 4. 4. 3 Basic VCl Signaling Rules : 49 4. 4. 4 Additional Timing Diagrams.................................................... ............................................................ ... 50 5. DESIGN GUIDELINES 51 5.1 USER' GUIDE....................................................... ............................................................ ..................................... 51 5.1.1 VC Initiator Responsibilities ............................................................ ....................................................... 52 5. 7. 2 OCB Initiator Wrapper Responsibilities 53 5. 1. 3 OCB Target Wrapper Responsibilities ............................................................ ........................................ 53 5.1.4 VC Target REsponsibilities ............................................................ ............................................................ 54 5. 1. 5 VCI to VCI Conversions................................................. ............................................................ .......... 54 5.2 VCI PARAMETERS ............................................................ ............................................................ ...................... 55 5. 2.1 Parameters Specific to PVCI 55 5. 2.2 Parameters Specific to BVCI........................................................ ........................................................... 55 5.3] IMPLEMENTATION GUIDELINES.................................................. ............................................................ ......... 56 6. VCI GLOSSARY OF TERMS....................................................... ............................................................ ........... 57 1. Virtual Component Interface (VCI) Background This standard is the result of the work of the On-Chip Bus (OCB) Development Working Group (DWG) of the Virtual Socket Interface Alliance (VSIA). The charter defined for the OCB DWG was to define on-chip bus-related specifications for the design, integration, and test of multiple functional blocks on a single piece of silicon.

Two generic audiences are targeted: Providers of functional blocks and Users or Integrators of these blocks : For the Providers of functional blocks, the standard defines the protocols and interfaces their Users require for effective reuse of the blocks in an integrated product design. For the Users of functional blocks in compliance with this standard, it depicts the information these Users will need to properly evaluate, integrate, and verify one or more functional blocks in a design.

The overall objective is to obtain a general interface, such that Intellectual Property (IP), in the shape of Virtual Components (VC) of any origin, can be connected to Systems-on-Chips (SoC) of any chip Integrator. In this manner, VCs are not limited to one-time usage by their designers. They can be re-used over and over. Such re-use of VCs would also apply to VC Providers or to (external) System Integrators.

Early in the existence of this DWG it became clear that picking an existing bus or defining a new one would not be the right way to go. First of all, System Integrators will stick to their own bus for a relatively long time, if only to allow for connection of their existing VCs without modification. Connecting new VCs via a bus-to-bus bridge is expensive in timing and in silicon footprint. Furthermore, all existing buses are rather good for their particular usage. Inventing yet another one does not make much sense. Thus there would be little chance of such a bus being accepted.

For these reasons, the working group decided to define an interface rather than a bus. This interface can then be used as a point to point connection if one is needed and additionally as an interface to a bus connector if that is what is desired.

1. 1 Goals The following were considered primary goals in defining the VCI.

1. Must enable maximum portability of a VC -VCI-compliant VCs should inter-operate with OCBs of varying protocols and performance levels.

-VCI should not dictate the integration methodology, i. e. VCI can be used as a point-to- <BR> <BR> point interface without an OCB, and can be connected to different OCBs with automated<BR> <BR> <BR> <BR> methods, or with hand-crafted wrappers.

2. Should not require modification of VCI-compliant VCs in order to connect to a different VCI-compliant VC or OCB.

-Some combinations of VCI-compliant VCs and OCBs may result in reducedfeatures or performance, but must stillfunction correctly and reliably.

3. Simple and efficient to implement with clear and easy to understand protocol -Necessary for wide acceptance.

4. Design a compatible family of VC Interfaces (i. e. Advanced VCI, Basic VCI, and Peripheral VCI) -This enhances inter-operability choices for the System Chip designer, and design opportunities for the VC designer.

5. Protocol must be fully defined -This includes full enumeration ofpossible interactions together with statements on allowed l disallowed behavior. However, it is essential for wide adoption that there be some mechanism for extending the protocol 6. Few optional signals -Minimize the number of truly optional signals to minimize the complexity of VCI compliance checking. However, signals such as data and address lines and supported transfer widths may be parameterizable andlor scalable.

1.2 Key Assumptions This section describes the assumptions that were made in defining the VCI.

1. Initiator/Target connections are point-to-point and unidirectional.

-Both multiplexed and tri-state OCBs can be supported by allowing the OCB wrappers to implement the OCB transceivers. Separate unidirectional nets are simpler to handle, and this circumvents the requirementfor arbitration in the VClprotocol.

2. Initiator can only present requests; Target can only respond <BR> <BR> -If a VC needs both capabilities, implement parallel Initiator and Target interfaces.<BR> <BR> <BR> <BR> <BR> <P> A combined (peer-to-peer) protocol is much more complex to define and implement<BR> <BR> _ (due to interface arbitration requirements).

Some OCB architectures can take advantage of the separate initiator and target interfaces by connecting the VC Initiator interface to a System OCB whereas the (separate) VC Target interface might connect to a Peripheral or Configuration OCB (a bus for loading device configurations).

Finally, the parallel interface is simpler to model and offers possible performance advantages using simultaneous transfers.

-Limitedfundamental Readl Write requests.

Peripheral VCI is limited to read and write Basic VCI includes Nop and read lock.

3. Address/Data widths are determined by VC requirements -OCB Target's Initiator should scale its address/data widths to match Target 4. The standard should ensure that any required data and address storage in the wrappers is minimal.

-Anything more than minimal timing overhead is deemed unacceptable and would negatively impact acceptance.

5. Clock domain crossing will not be visible at the interface -Interface is fully synchronous. Clock domain crossing is considered a design guideline for wrapper or YC implementation.

1.3 Document Conventions b == number of bytes in a cell n == most significant bit of address field m == least significant bit of cell-address k Number of bits in the packet length field q == Number of bits in the packet chain length field E == Number of bits in the error extension field Timing constraints: Early : Signal is Valid within 20% of the clock cycle from the rise of the Clock signal Middle: Signal is Valid within 50% of the clock cycle from the rise of the Clock signal Late: Signal is Valid within 80% of the clock cycle from the rise of the Clock signal 1. 4 Document Organization The Standard begins with defining the basic characteristics of the VCI. The different-complexity interfaces are described in detail next, starting with the simplest one, the Peripheral VCI. The PVCI and BVCI sections are designed so that they can be read independently, i. e. if a reader wants to know about to use the PVCI, he does not need to be familiar with the BVCI. After the interface descriptions, some design guidelines are given. VCI Transaction Language section will be included in the standard version 2 2.0.

2. VCI Characteristics 2.1 VCI Definition The Virtual Component Interface or VCI is an interface rather than a bus. Thus the VCI specifies: 1. A requests-response protocol.

2. A protocol for the transfer of requests and responses.

3. The contents and coding of these requests and responses.

The VCI does not touch areas as bus allocation schemes, competing for a bus, etc.

There are three complexity levels for the VCI : Advanced VCI, Basic VCI, and Peripheral VCI (AVCI, BVCI, and PVCI respectively). The current version of the VCI standard defines the Basic VCI and the Peripheral VCI. The Advanced VCI will be added later. The Basic VCI defines an interface, which is suitable for most applications. It has a powerful, but not overly complex protocol. The Advanced VCI will add more sophisticated features, such as treads, to support high performance applications. The Peripheral VCI provides a simple, easily implementable interface for applications, which do not need all the features of the Basic VCI. The Peripheral VCI is a subset, and the Advanced VCI is a superset of the Basic VCI, and all those interfaces are designed to be compatible with each other.

2.2 Point to Point Usage As an interface, the VCI can be used as a point to point connection between two units called the Initiator and the Target, in which the Initiator issues a request and the Target responds. The VCI can also be used as the interface to a"wrapper", a connection to a bus. This is how the VCI allows the Virtual Component to be connected to any bus (See section 2.4). Basic point to point usage is depicted below in Figure 1. request Initiato Targe L F°Ue~--_ Figure l. VCI Is a Point to Point Connection This interface is very simple indeed while protocol and coding are concerned. Nevertheless, the interface contains many sophisticated features, as will be explained in further chapters of this standard. Its simplicity is the reason for the small footprint, and the high bandwidth.

2.3 Split Protocol Basic VCI and Advanced VCI make use of a"split protocol". That is, the timing of the request and the response are fully separate. The Initiator can issue as many requests as it sees fit, without waiting for the response. The protocol does not prescribe any connection between issuing of requests and arrival of the corresponding responses. The only thing specified is that the order of responses corresponds to the order of requests.

In the Advanced VCI, requests may be tagged with identifiers, which allow such requests and request threads to be interleaved and even allows responses to arrive in a different order. Responses shall bear the same tags issued with the corresponding requests, such that the relation can be restored upon the reception of a response. Additional details will be provided as the Advanced VCI is standardized.

In the Peripheral VCI, no split protocol is used, and each request must be followed by a response, before the Initiator can issue a new request. 'is simpliWion is for supporting simple peripheral buses.

2.4 VCI Usage with a Bus The VCI can well be used as the interface to a"wrapper", which means a connection to a bus. This is how the VCI allows the VC to be connected to any bus. An Initiator is connected to that bus via a a bus initiator wrapper. A Target is connected to that bus via a bus target wrapper. Once the wrappers for the bus have been designed, any VC can be connected to that bus, as depicted below in Figure 2. The wrapper and the VCI-boxes (the non-shaded area) in the picture together correspond to the traditional bus interface within both the initiator and the target. The whole interface will, again, function as a point-to-point connection. Of course, the use of VCI does not prevent using native bus components at the same time. In fact, the presented use of VCI is completely transparent to the bus system.

It is intended that OCB suppliers will provide VCI wrappers to their proprietary bus, or EDA vendors will provide tools to create such wrappers automatically. This will free the IP Provider from having to understand the details of many buses. i. = w w target w VCI VCI Point to point Point to point VCI target initiator wrapper Bus master Bus slave target wrapper Any Bus Figure 2. Two VCI Connections Used to Realize a Bus Connection 2.5 Notes 1. The"Initiator"and"Target"are simpler than their equivalents directly connected to a bus. The VCI initiator and the VCI target are much simpler than the bus initiator and target interfaces. The bus interface, though, is not removed. It is in the wrappers.

2. The wrapper contains not much more than the bus interface, which is needed anyway when connecting (no matter what) to the bus and to the VC interface block.

3. The two blocks marked"vci initiator"and the two blocks marked"vci target"in Figure 2 are very simple. They do not add much to the total footprint or timing. This is especially so, as some logic is needed quite often anyway to connect the actual functionality of Initiator and Target to their bus interfaces. It is merely the vci initiator-vci target interface that is standardized in the VCI.

3. Peripheral VCI 3.1 Overview 3.1.1 Scope This section defines the first member of the VCI family, the Peripheral Virtual Component Interface (PVCI), which can be used in conjunction with peripheral on-chip buses as defined in the VSIA OCB Specification I 1. 0, and for point-to-point connections between Virtual Components. The PVCI is a subset of Basic VC] as the Basic VCI is a subset of the Advanced VCI.

3.1.2 Organization This section contains the following chapters: Chapter 3.1 provides an overview for the section Chapter 3.2 gives a technical introduction to Peripheral VCI Chapter 3.3 provides a detailed description of PVCI signals 'Chapter 3.4 defines the PVCI protocol 3.2 Technical Introduction to Peripheral VCI 3.2.1 Initiator-Target Connection As shown in Figure 3 below, the request contents and the response contents are transferred under control of the protocol, a simple 2-wire handshake. Initiator contents __. Target handshake -_-_-_., _ contents . r-- response Figure 3. PVCI: The Request and Response Contents are controlled by a Simple Handshake 3.2.2 The Handshake Note that in Figure 3, the handshake arrow is a double pointed showing that signals in both directions are involved. ('Signal'here is synonymous to'net','wire'or'port'.) The handshake protocol is aimed at synchronizing two blocks by transferring control information in both directions. The contents-arrow points one way only. The PVCI handshake signals are called VAL and ACK, as for Valid and Acknowledge.

Request-contents flow from Initiator to Target, response-contents flow from Target to Initiator. The handshake protocol is introduced below. (See Figures 4 and 5.) Note that the delays are exaggerated in the figures. The triggering events for each transition are expressed with arcing arrows. Sample Sample Sample contents contents contents VAL --7 zizi contents - contents ACK _ _ _ ; i i i i i i i i , i i i, Figure 4. The Control Handshake (Asynchronous ACK) In Figure 4 : Vertical dashed lines show rising clock edges.

VAL shows"at the next rising edge, contents can be read". No actual timing is specified here! ACK, while VAL is active at the rising edge of the clock, shows that the contents were read by target, or contents are available to be read from the target. This means the end of the transaction.

VAL and contents must be maintained until ACK has become asserted and there is a rising edge of the clock. As indicated in Figure 4 (right hand side), maintaining the VAL signal in asserted mode for another clock cycle after ACK = 1 means that another request is waiting.

The ACK can be either generated asynchronously of the VAL as in the Figure 4, or set synchronously at the rising edge of the clock as in the Figure 5. The synchronous ACK can be set at the next clock cycle after Valid, or later. (A slow reaction, or late ACK.) If asynchronous ACK is used, special design considerations are needed to make sure that the ACK is stable at the rising clock edge. This means that if the ACK is not driven directly by a flip-flop, it must be generated from the VAL signal in the target with a minimum amount of logic and wire delay. VAL i m contents ACK 0/1 1 ACK ' i i i i i O-J i i i- i i i i Figure 5. Fully Synchronous Control Handshake: ACK Late by 2 Cycles The Default Acknowledge A"default acknowledge"is permitted on top of this protocol. Since the acknowledge-signal is only sampled when VAL = 1, it can be asserted (long) before it is needed. Such an early ACK has no influence on the protocol behavior. The early ACK is merely"don't care" (the signal is not being considered, if VAL is not active). The acknowledge-signal can even be tied permanently active, if the target is always able to serve the request in one clock cycle.

3.2.3 Request and Response Contents Each handshake is used to transfer a cell across the interface. Cell size is the width of the data passing across a VCI. It will typically be 1,2 or 4 bytes. The cell is synonymous to data word, and the cell size to word length. The cell size is always the same as the size of the particular VC Interface. The Figure 6 shows the signal groups of the PVCI belonging to the request and response. The request contents are the Valid, cell-address, byte-enables within the cell, data to be written, command signal indicating whether we are reading or writing data, and end-of-packet, indicating the end of a burst of several cells (see the description later). The response contents are the acknowledge, response error, and the data read from target. The initiator interface is similar, except that the signal directions are opposite. request r, a ",, S i.. Rr ; *= t response ' i Figure 6. Peripheral VC Interface-Target 3.2.4 Main Peripheral VCI Features: *Up to 32-bit Address *Up to 32-bit Read Data *Up to 32-bit Write Data *Synchronous Allows for 8-bit, 16-bit, and 32-bit devices *8-bit, 16-bit, and 32-bit Transfers # Simple packet, or'burst'transfer # Optimal Free-BE mode allows transfer of any combination of bytes of a word # Least Significant Bit is bit"0" # PVCI has no explicit Endianness # Natural byte alignment 3.3 Signal Definitions This chapter defines the PVCI signals. First, the signals are summarized in table format. A textual definition of each signal follows. All signals included in Table 1 below are assumed to be active-high signals unless explicitly indicated otherwise. It is recommended that all signal outputs are stable before Early. It can be assumed that all inputs are stable before Late.

System Signals mm m » r ni ; y Drer y Re: erve. :',.: yt'clth.. . Y..., o eii '; aN3fi a ms':., r: CLOCK System Initiator/Target 1 Supplied by the system. Interface is synchronous to the rising edge only. RESETN System Initiator/Target 1 Supplied by the system. Active low reset. De- asserts VAL and ACK.

Handshake, Flow Control, and Shaping : a' .: ixVer: x .. , geceiver: '' Wadth- a .. a Gine :. ,, VAL Initiator Target I This pair of signals provides flow control for a ACK Target Initiator 1 cell transferring across the VC Interface, and validates all signals associated with that cell. VAL==1 : indicates that the initiator has a cell available. ACK==I : indicates that the target can complete the operation on the cell. The cell is therefore transferred when VAL=ACK=1 EOP Initiator Target EOP--I indicates that the current cell is the last one in a series of cells accessed at contiguous addresses. Can be interpreted as an inverted burst signal.

Operation Information wmmm y y, . g: , wn: < rDr : a-e e » yx7t u " _ = korii"-eri' . _ ADDRESS Initiator Target N N is a parameter based upon the capabilities [N-1 : 0] of the target and is defined and fixed at the time of component instantiation. The most significant bit of the address is carried by bit W-1, and the least significant bit is carried by bit 0. See 3.3.3 for use of low-order address bits. RD Initiator Target 1 This is a single bit code giving the operation type: READ==1 : Read data from the target peripheral READ==0 : Write data to the target peripheral BE Initiator Target b This is a field with b-bits, one for each byte, [b-1: 0 10 : b- which indicates which bytes of the word 1] being transferred are enabled. The usage restrictions of BE are listed in 3.4.3. WDATA Initiator Target 8b This is the data, which is transferred with [8b-1: 0] write operations to the target. For the Peripheral Interface, the allowed values of b are 4,2,1. Bit 8b-1 is the most significant bit, and bit 0 is the least significant bit. Byte [8b- 1: 8b-8] represents the most significant byte. For VCs supporting a data size which is not a power of two, the next larger supported b will be used with the unused bits tied to logic zero. For example, a 12-bit device must use a 16-bit wide PVCI with the 4 Most Significant bits tied to logic zero. RDATA Target Initiator 8b This is the data, which is returned from the [8b-1: 0] target with read operations. Since the peripheral interface has no pipelining, RDATA is validated by the target when it asserts ACK. It is defined in the same way as WDATA above. RERROR Target Initiator E+] Indicates error in transfer. Optional error [E: 0] extension bits indicate nature of the error. E is defined by parameter ERRLEN. It is zero or more Table 1: Peripheral VCI Signals 3.3.1 System Level Signals Clock Signal Name: Clock Signal Abbreviation: CLOCK Polarity: Active at Positive edge Driven By: System Received By: VCI Initiator, VCI Target This signal provides the timing for the Virtual Component Interface and is an input to both the initiator and target that are connected via the PVCI. All initiator and target output signals, unless otherwise specified, are asserted/de-asserted relative to the rising edge of CLOCK and all initiator and target inputs are sampled relative to this edge.

Reset Signal Name: Reset Signal Abbreviation: RESETN Polarity : Asserted Negative Driven By: System Received By: VCI Initiator. VCI Target Timing: Asserted > 8 clock cycles This signal is used during power-on reset and is used to bring the PVCI to an idle or quiescent state. This idle state is defined as the PVCI state in which: 1. The VAL signal is de-asserted 2. The ACK signal is de-asserted The system must guarantee that RESETN is asserted for at least eight cycles of CLOCK (More if RESETLEN parameter is set.).

3.3.2 Control Signals Valid Signal Name: Valid Signal Abbreviation: VAL Polarity: Asserted Positive Driven By : VCI Initiator Received By : VCI Target Timing: Asserted at rising edge of CLOCK until ACK = 1 and next rising edge of CLOCK.

The VAL signal is driven by a VCI initiator to indicate that there is a valid address, data, and command on the PVCI. All of the initiator control. signals are qualified by VAL. The initiator keeps VAL asserted, and all of its control signals valid and stable, until it receives the ACK signal from the target. The initiator should not assert VAL unless the current transaction is intended for the target. Thus, the initiator may need to perform address decoding on its on-chip bus side to generate VAL for the target, thereby accomplishing device selection.

Acknowledge Signal Name: Acknowledge Signal Abbreviation: ACK Polarity: Asserted Positive Driven By: VCI Target Received By: VCI Initiator Timing : Asserted and negated at rising edge of CLOCK. The signal must change before Late.

The ACK signal is asserted by the target to indicate the completion of a transfer between the initiator and target. In the case of write operations, this means that the target has accepted the data which is on the write data bus or will do so at he end of the current clock cycle. In the case of read operations, the assertion of the ACK by the target indicates that the target has placed data to be transferred to the initiator on the read data bus. The transaction completes as soon as the rising edge of CLOCK samples ACK. The target may de- assert the ACK by the next rising edge of CLOCK unless a new command has been initiated by the initiator, or default acknowledge is used. Similarly, the initiator de-asserts VAL by the next rising edge of CLOCK unless it is presenting a new command.

Read/Not Write Signal Name : Read/Not Write Signal Abbreviation: RD Polarity: Read at positive, write at zero Driven By: VCI Initiator Received By: VCI Target Timing: Asserted at rising edge of CLOCK until ACK zizi at rising edge of CLOCK.

This signal is a one-bit command asserted by the initiator and indicates the direction of the requested transfer. RD indicates that the requested transfer is a read if it is asserted high and a write if it is asserted low. This signal must be valid any time that the VAL signal is assertea. A reaa transfer is a request tor the target to supply data on RDATA to be read into the initiator. A write transfer is a request for the target to accept data on WDATA from the initiator.

End-of-Packet Signal Name: End-of-Packet Signal Abbreviation: EOP Polarity: Asserted Positive Driven By: VCI Initiator Received By: VCI Target Timing: Asserted at rising edge of CLOCK until ACK = 1 at rising edge of CLOCK The EOP signal is de-asserted by the nitiator to indicate that the transfer being performed will be followed with a transfer by the initiator to the next higher cell address. This signal is used by the target device to preset address in order to improve the data transfer performance. Thus this signal can be interpreted as an inverted burst signal. The burst is similar to a packet in the Basic VCI, except that rather than prescribing a strict atomicity, it merely indicates a contiguous address behavior. The burst transfer is completed once a cell is transferred with the EOP signal asserted, or when the Target signals an Abort error. See the definition of ADDRESS signal for the legal address behavior during a burst.

Basic VCI packet with CONTIG signal asserted high and WRAP signal asserted low can be mapped to a PVCI burst.

3.3.3 Address and Data Signals Address Signal Name : Address Signal Abbreviation: ADDRESS [n-1 : 0] Polarity : N/A Driven By: VCI Initiator Received By: VCI Target Timing : Asserted at rising edge of CLOCK until ACK == I at rising edge of CLOCK The PVCI initiator uses ADDRESS to identify which target-resource the current transaction acts upon. The N-lines of address bus form a binary number that represents an address. N is a parameter based upon the capabilities of the target and is defined and fixed at the time of component instantiation. The most significant bit of the address bus will be carried by bit N-1 and the least significant bit of the address will be carried by bit 0. ADDRESS [n-I : m] provides a cell address where the cell size is specified by the PVCI's total data width. M equals to 0 for cell size 1,1 for cell size 2, and 2 for cell size 4. Sub-cell addressing is handled by the byte enable signals.

It is permissible to supply the low-order address bits to allow the original full intention of the transfer to be maintained. This will rely on knowledge of the endianness of the initiator. This additional information is NOT required to complete the operation, which is completely defined by a cell-aligned address and byte enables (i. e. the low-order address bits may be tied to logical zero). However, in some systems, some efficiency gains may be possible by taking advantage of this information.

When the EOP signal is low, the ADDRESS of the next cell must be cell size + ADDRESS of the current cell, and the ADDRESS of the current cell must be aligned with the cell boundary.

Byte Enable Signal Name: Byte Enable Signal Abbreviation: BE [b-1 : 010 : b-1] Polarity : Asserted Positive Driven By: VCI Initiator Received By: VCI Target Timing: Asserted at rising edge of CLOCK until ACK = 1 at rising edge of CLOCK BE is a b-bit field that indicates which bytes of the cell being transferred are enabled. The b equals to total data width of the PVCI/8. These signals must be valid any time that the VAL signal is asserted. The usage of byte enables is described in the Peripheral VCI as described in Section 3.4.3 Data Formatting and Alignment.

BE [3: 0] is used for little endian VCs where the LSB (Least Significant Byte) is labeled Address 0.

BE [0 : 3] is used for big endian VCs where the MSB (Most Significant Byte) is labeled Address 0.

Write Data Signal Name: Write Data Signal Abbreviation: WDATA [8b-1 : 0] Polarity: N/A Driven By: VCI Initiator Received By: VCI Target Timing: Asserted at rising edge of CLOCK until ACK == 1 at rising edge of CLOCK The write data lines are driven by the VCI initiator and are used to transfer write data from an initiator to a target device. Write data consists of b logical byte lanes, based upon the capabilities of the target and is defined and fixed at the time of component instantiation. Allowed vales of b are 8,16, and 32, allowing 1, 2 or 4 byte lanes. Bit 8*b-1 is the most significant bit of the most significant byte and bit 0 is the least significant bit of the least significant byte. The write data lines must contain valid write data while the VAL signal is asserted and the READ is indicating a write transfer.

For VCs supporting a data size that is not an eight bit increment, the next larger supported bus size will be used with the unused bits tied to logic zero. For example, a 12-bit device must use a 16-bit wide PVCI with the 4 Most Significant bits tied to logic zero.

Read Data Signal Name: Read Data Signal Abbreviation: RDATA [8b-l : 0] Polarity: N/A Driven By: VCI Target Received By: VCI Initiator Timing : Asserted at rising edge of CLOCK until ACK = 1 at rising edge of CLOCK n < The read data lines are driven by the VCI initiator and are used to transfer read data from a target to an initiator device. Read data consists of logical byte lanes, based upon the capabilities of the target and is defined and fixed at the time of component instantiation. Allowed vales of b are 8,16, and 32, allowing 1, 2 or 4 byte lanes. Bit 8*b-1 is the most significant bit of the most significant byte and bit 0 is the least significant bit of the least significant byte. The read data lines must contain valid read data while the ACK signal is asserted and the RD is indicating a read transfer.

For VCs supporting a data size that is not an eight bit increment, the next larger supported bus size will be used with the unused bits tied to logic zero. For example, a 12-bit device must use a 16-bit wide PVCI with the 4 Most Significant bits tied to logic zero.

3.3.4 Error Signals Response Error Signal Name: Response Error Signal Abbreviation: RERROR [E: 0] Polarity: Positive Driven By: VCI Target Received By: VCI Initiator Timing: Asserted at rising edge of CLOCK when ACK = 1 at rising edge of CLOCK.

Error signal is valid only when ACK=1, with the following meaning: For ERRLEN = 0 (E=0) RERROR=0 : Normal (no error) RERROR==1 : General data error. The entire packet is considered bad.

For ERRLEN = 1 (E=1) RERROR = 00: Normal (no error) RERROR = 0] : General data error. The entire packet is considered bad RERROR = 10 : Reserved RERROR = 11 : Abort Disconnect For ERRLEN = 2 (E=2) RERROR =000: Normal (no error) RERROR = xx0 : Reserved RERROR = 001 : General data error. The entire packet is considered bad RERROR = 011 : Reserved RERROR = 101 : Bad data (retry) RERROR = 111 : Abort Disconnect After receiving an error, the Initiator may or may not continue with the current packet. If it chooses to end the packet prematurely, it can do so by asserting EOP. After this, it can choose not to try a transfer anymore (Abort) or Retry part or all of the transfer. For any error, the Target must process the subsequent pending cells and packets with the normal protocol, i. e. it must continue sending responses until it has processed the EOP with or without further errors signaled. In general, the RERROR is more informative than prescriptive, and the Target may not assume any special behavior from the Initiator. The Initiator is anyhow encouraged to act responsibly, when it meets an error.

While sending a non-Abort error, the target should continue with the burst, with or without further errors until it receives a cell with EOP. The Initiator can choose to continue with the burst or set the EOP on the next cell. In the case of Bad data, just the data of error may be considered bad. If ERRLEN=2 is supported, the Target must be capable of accepting a retried request to the same address where it sets Retry-error, but the Initiator can choose to retry a cell, burst or nothing at all. It is strongly recommended that all PVCI components would support at least one bit error. The PVCI target is strongly recommended to signal an error when it receives a request it does not support.

3. 4 PVCI Protocol 3.4.1 Operation Types Transfer Request The following is a list of default transaction types that may be initiated by an initiator across the Peripheral Virtual Component Interface (PVCI). An initiator should not initiate an operation of a width that the target does not support.

-Read8 : Read one byte. The byte may be on any byte lane expressed with the BE field. Supported by all PVCI components -Read 16 : Read two bytes. The bytes must be on contiguous byte lanes, and are expressed with the BE field. The operations must be aligned to 16-bit sub-word boundaries, i. e. transfer with BE==0110 is not allowed. Supported by 2-and 4-byte PVCI components.

-Read32: Read four bytes. Supported by 4-byte PVCI components.

-Read N Cells : Read a packet of N cells. The addresses of consecutive cells must be ascending, cell aligned, and consecutive. The byte enables of individual cells may have any legal values.

The last cell is indicated with the EOP signal. Each cell of a packet is individually requested and handshaken. Only one pending request for a cell is allowed at a time.

-Write8: Write-operations are similar to read-operations, except for the data direction -Write6 -Write32 -Write N Cells All transfers are packet transfers of 1 cell or more. A packet transfer of length 1 is indistinguishable from a single transfer. Neither the initiator nor the target need support packets that cross address selection boundaries.

The optional Free-BE mode operations are as follows : -Read: Read any combination of the bytes in the cell as expressed by BE field.

-Write: Write any combination of the bytes in the cell as expressed by BE field.

Transfer Response The following is a list of responses that are allowable by a target across the Peripheral Virtual Component Interface (PVCI).

-Not Ready -Transfer Acknowledged -Error 3.4.2 Handshake Protocol The two-wire handshake was introduced in the chapter 3.2.2. The Peripheral VCI handshake protocol is a subset of the Basic VCI handshake protocol (See 4.2.2). Connecting a Basic VCI target to a Peripheral VCI initiator is trivial ; the extra signals are tied into constants. The performance achieved is similar to native Peripheral connection. It is also possible to connect Basic VCI initiator to a Peripheral VCI target, if the initiator knows the limitations of the target.

The VAL-ACK pair of signals provides a flow control for a cell transferring across the VC Interface, and validates all signals associated with that cell. See waveform pictures below for examples.

VAL=1 : Indicates that the initiator is presenting a request.

ACK==1 : Indicates that the target is ready to present the response.

Rules : RI not changeable : Once an initiator has asserted VAL, it is not permissible to de-assert it or to change any request field, until acknowledged.

R2 : default ack : ACK is permitted to be asserted when VAL is low.

R3 : valid response: The target must be presenting stable response fields at the rising edge of the clock while both ACK and VAL are asserted.

The initiator must keep VAL asserted, and all of its control signals valid and stable, until it receives the ACK signal from the target. The initiator should not assert VAL unless the current transaction is intended for the target.

Packet Transfer The packet (burst) transfer is meant for making transfer of block of cells with consecutive addresses more efficient. While the EOP signal is de-asserted during a request, the address of next request will be ADDRESS+cell size. The ADDRESS must be aligned to the cell boundary. The packet transfer is completed once a cell is transferred with the EOP signal asserted, or when the Target asserts RERROR = Abort. In terms of the Basic VCI operations, the Peripheral VCI burst equals to a packet transfer with CONTIG signal asserted and WRAP signal de-asserted (See 4.3). The byte enable signals may have any legal combination in each cell of the packet.

Examples: The following picture shows waveforms of read and write operations to a target, which needs two clock cycles to complete the read, and one cycle to complete the write. If the RERROR signal is not drawn, it is 0 ('Normal') for all the examples. Sample Sample Sample ziwnpie bampie control read write read write signals data data data data i i i i i i i CLOCK WDATA Data data i , s' I G WDATA. Data ; Data" u: h i RDATA'i. i atal 1 Da 1 Ip BE F Hytena yten Bytena $yten RD VAL gD i i i VAL i ACK EOP i EOP i i i i i read mhte read tvrite cycle ycle cycle ycle ; Figure 7. PVCI Read and Write The following picture shows waveforms of read and write operations to a target, which has default acknowledge, i. e. requires single cycle to complete read and write operation. Sample Sample SampleSample read write read write data data data data click i i CLOCK < I LJ RDATA RDATA Uata oata VAL riz ACK EOP ACK | t i,, SE Byt yten ytena'Byten n n n n i i i i i i n n i i i i i i i ACK i i i i EOP i i'i i i i i i read vrite ead write cycle , bycle, tycle, eyde, n n I 1 Figure 8. PVCI Read and Write with Default Acknowledge The following picture shows how the EOP signal can be used to indicate address predictability to a similar target, which has an internal address counter to support pre-fetching read data. Notice that the cell size is 4 in the example, so the ADDRESS is incremented by 4 at each read. In this example, the target can respond to the read in two clock cycles in single transfer, and in one cycle in burst transfer. The ACK signal can be generated of the VAL, RD, and EOP signals. CLOCK u u u u u- ADDRESS 0 | 4 | 8 | 12 | 16 | 20 | 24 | 28 ADDRESS 4 S t2 t6 20 24 28 i ; G | i fi i RDATA III 1 2 3 4 5 6 7 8 BE BYTENA EOP | | EOP EOP VAL ACK Figure 9. PVCI Burst Read The following picture illustrates how'Abort'error response will terminate a burst transfer. CLOCK ADDRESS » 0 | 4 | 8 | 12 | 16 | 20 | 24 ADDRESS 4 8 12 16 ? ---- RDATA 1 2 3 4 5 6 7 P___. i i i i BE BYTENA Room RD EOP VAL ACK RERROR Normal Abo Normal Figure 10. Aborting a Burst 3.4.3 Data Formatting and Alignment This section describes the PVCI conventions used for bit/byte ordering and alignment. The Peripheral VCI defines bit"0"as the least significant bit of a vectored field such as WDATA, RDATA, or ADDRESS, bit "8bras the most significant data bit of each data bus, and bit"N-l"as the most significant address bit. N is defined to be the number of physical ports or wires associated with a particular instantiation of a PVCI.

The PVCI is endian independent at the interface. Even though the naming convention may imply a little endian interface, the DATA [7: 0] means address == 0 for little endian, and address = 3 for big endian (in case of a 32-bit interface). PVCI component on the other hand must choose an endianness it wants, and declare this to the system (unless the component is a memory, where it does not matter). When any component interprets a byte address it makes a decision on which byte lane to use.

The Peripheral VCI will use natural alignment to support peripherals and VC's that handle multiple size transfers (e. g. byte as well as word transfers). This means that transfer sizes that are smaller than the physical width of the data lines (WDATA or RDATA) will occur in their natural byte lanes and not be right or left justified. The byte enable lines (BE) indicate, which byte lane (s) contain the desired data. Table 2 shows the various data alignments defined for the peripheral VCI data transfers. The entries labeled"xx" are don't cares, which provide flexibility and support for byte replication if desired.

The PVCI standard has two operational modes related to byte enables : Byte Enables in Default Mode Every PVCI component must support usage of the byte enable lines that are restricted to the contiguous cases. Referring to the following table and the 32-bit example, the allowable patterns for the byte enables are 0000,0001,0010,0100,1000,0011,1100, and 1111. Patterns such as 1011 or 1101 are NOT allowed. VCData Xfer BE Data [31 : 24] bus size size 13 : 010 : 3] 32 32 Others Undefined 0000 XXXXXXXX Byte Byte Byte Byte 16 0011 XX XX Byte Byte 1100 Byte Byte xx xx 8 0001 XX XX XX Byte 0010 XX Byte XX 0100 XX Byte XX XX 1000 Byte XX XX VC Data Xfer BE Data 31 : 24] Datal23 : 16] Data [15: 8] Datal7 : 0] bus size size [1: 00: 1] bus size size 11 : 0l0 : 1l w w 16 16 00XX Byte Byte 8 O l" '.' . a 1'XX Byte JJ ! Byte 8 0] Byte ] QXX VC Data Xfer BEl0] Datal31 : 24] Datal23 : 16] Data (15 : 8] Data [7 : 0] bus size size 8 8 0 = XX Table 2: Peripheral VCI Data Alignment Both in big or little endian mode, the BE [0] always corresponds to the byte address 0 in the cell.

Byte Enables in Free-BE Mode The Free-BE mode is an optional operation mode for PVCI components. It is legal in this case to support any BE pattern. This mode can be used to make connections to some buses more efficient (e. g. a bus that support 3-byte wide transfers). A Target, which supports the Free-BE mode, automatically supports the Default mode. A PVCI Initiator must not require that the Target supports Free-BE mode, but it can take an advantage of it, if it does. The operation mode is selected in component instantiation; it is not a run-time parameter.

See VCI Parameters in the Design Guidelines section of the VCI Standard.

4. Basic VCI 4.1 Overview 4.1.1 Scope This section defines a Basic Virtual Component Interface (BVCI) to be used in conjunction with on-chip system buses, and for point-to-point connections between Virtual Components. The BVCI is a subset of Advanced VCI. The BVCI is designed to fulfill most on-chip interfacing needs protocol wise.

4. 1.2 Organization This section contains the following chapters: Chapter 4.1 provides an overview for the section 'Chapter 4. 2 gives a technical introduction to Basic VCI Chapter 4.3 provides a detailed description of BVCI signals Chapter 4.4 defines the BVCI protocol in great detail.

4.2 Technical Introduction to the Basic VCI 4.2.1 Initiator-Target Connection As shown in Figure 11 below, the request contents and the response contents are separately transferred under control of the protocol, a simple handshake, as introduced in Section 4.2.2. handshake ---10 I nitiator contents T tntttator.-. -.- Target request' handshake contents contents response Figure 11. VCI: The Request and Response Each Consist of a Handshake and Contents 4.2.2 The Handshake The BVCI handshake is different from the PVCI one: The request and response handshakes are completely independent of each other. The handshake protocol is aimed at synchronizing two blocks by transferring control information in both directions. In the request, the handshake signals are called CMDVAL and CMDACK (RSPVAL and RSPACK in the response). Those are acronyms for Command Valid, Command Acknowledge, Response Valid, and Response Acknowledge, respectively.

Request-contents flow from Initiator to Target; response-contents flow from Target to Initiator. The handshake protocol is introduced below. (See Figure 12.) More precise details are provided later in the text. This introductory section only serves to provide a basic understanding of the overall process. Sample Sample Sample contents contents contents valied contents acknowledge acknowledge >-jk i---T i i i i i acknowledge i-i i i i I I I I , I 1 1, Figure 12. The Control Handshake for Both Request and Response (Asynchronous ACK) In Figure 12 : Vertical dashed lines show rising clock edges.

VAL shows"at the next rising edge, contents can be read". No actual timing is specified here! ACK, where there is a coinciding VAL, shows"contents have been read". No actual timing is specified here! As indicated in the figure (right hand side), maintaining the VAL signal in asserted state for another clock cycle after ACK = 1 means that another request or response is ready for reading. VAL and contents must be maintained until the next rising clock edge after the ACK has become asserted.

The ACK can be either generated asynchronously of the VAL as in the Figure 12, or set synchronously at the rising edge of the clock as in the Figure 13. (A slow reaction, or late ACK.) If asynchronous ACK is used, special design considerations are needed to make sure that the ACK is stable at the rising clock edge.

For this reason, it is not recommended to use an acknowledge, which is not generated synchronously except with"default acknowledge"behavior (See below). valid contents contents _t contents I 1 I 1 I I acknowledge 1 i _-L_- ))') ) i i i I Figure 13. Fully Synchronous Control Handshake : ACK Late by 2 Cycles 4.2.3 The Default Acknowledge A"default acknowledge"is permitted on top of the protocol. Since the Acknowledge signal is only sampled when VAL = 1, the Acknowledge signal can be asserted (long) before it is needed. Such an early ACK has no influence on the protocol behavior. The early ACK is merely"don't care" (the signal is not being considered unless VAL is active at a clock edge). This makes it possible to tie ACK permanently active.

4.2.4 Cells, Packets, and Packet Chains 4.2.4.1 Cell Each handshake is used to transfer a cell across the interface. The cell size is the width of the data passing across a VCI. It will typically be 1,2,4,8 or 16 bytes.

4.2.4.2 Packet Cell transfers can be combined into packets, which may map onto a burst on a bus. A VCI operation consists of a request packet and a response packet. As noted in Section 2, although the responses in a packet arrive in the same order as their requests, there is no further relation between the timing of the series of requests and the series of responses. The protocol is a split protocol. Packets have been introduced for three reasons: 1. When connecting the BVCI to a bus : If the underlying bus system is aware that more operations are to follow, then no bus arbitration is required between operations of one packet. This may well gain valuable bus capacity and speed.

2. Packets are atomic. That is, the point-to-point connection is maintained over the packet, no matter what is in between Initiator and Target-a complex interconnection set-up consisting of one or more buses or"nothing at all". This set-up, for example, allows for the monopolizing of a buffer.

Note, though, that long packets block any other use of the connection system. It is strongly advised to keep packets as short as possible to prevent degradation of system performance.

3. The"Advanced VCI", not yet defined, needs a multi-operation building block for more sophisticated packet chains. The packet thus is needed for upward compatibility.

Packets are similar in concept to"frames"in PCI, where a connection is established to enable data to be transferred until the Initiator indicates the termination by closing the frame.

4.2.4.3 Packet Chain Packets can be combined into chains, to allow longer chains of operations to go uninterrupted, as long as no higher priority operation claims part of the connection, such as a bus. Packet chains thus produce the same bus efficiency that packets provide, without actually excluding any other usage of the connection system.

The VCI Initiator may merely"notice"that the CMDACK to the first operation of a new packet is withheld for a long time. After this pause, the accepting of requests proceeds as if no other usage of the connection system had been served. To obtain this behavior, CMDVAL should be held asserted between the packets of a chain. There is no upper limit to the length of a packet chain.

4.2.5 Request Contents Request contents are partitioned into three signal groups: . 1. Opcode to specify the nature of the request (roughly: read or write), 2. Packet Length and Chaining to control packets, and 3. Address and Data to further detail a read or write action.

Request contents are validated by the CMDVAL signal. An introductory description of request contents is provided below. A more detailed description follows.

4.2.5.1 Operation Code (opcode) This subset of the request contents is constant for all the operations in a packet.

Command : The two bit field"CMD"can specify no-operation, read operation, write operation, or read locked.

Flags (address algorithm indicators): When none of the flags is asserted, there is no predefined relationship among the addresses of subsequent operations in a packet or in a packet chain. Three flags, though, can indicate a predefined algorithm among subsequent addresses. This allows Targets to compute addresses before they actually arrive via the bus and thus, in some cases, to gain valuable clock tics. The address, even when obeying a predefined algorithm, is sent with each operation, allowing cost effective targets to function without address prediction. The three flags are: 1. Contiguous: Indicates that the addresses within a packet increasing in a contiguous manner.

2. Wrap (only valid with contiguous addressing): The increase is done modulo the packet length, and only when packet length is power of two. This allows for a cache line refill starting with the missing word rather than with the word at the lowest address.

3. Constant (no change in address): This mode is useful for the case when a series of FIFOs have contiguous addresses and a packet or a chain is used to empty or fill just one of these FIFOs.

(In the Advanced VCI, more such flags may be defined.) 4.2.5.2 Packet Length and Chaining This subset of the request contents is constant for all the operations in a packet, apart from the indicator "End of Packet", which is only asserted in the last cell of a packet. Contents include: Packet Length: The length of the packet expressed in bytes.

End of Packet : This bit is asserted in the last operation of a packet.

The bit could be considered redundant in presence of a defined packet length, but it allows a Target to be designed without its own explicit remaining length counter. Furthermore, end-of- packet is a necessity with an undefined packet length.

Chain Length: Presents the amount of packets yet to come in a packet chain.

* Chain length = 0 thus represents a one-packet chain. There is no need for an"eoc" (end of chain).

Chain Fixed: Indicates that the opcode fields (see Section 4.2.5.) and packet length are equal for all packets of the chain. Otherwise each packet of a chain has its own such fields and flags.

4.2.5.3 Address And Data This subset of the request contents is issued anew for each cell within a packet. Contents include: Address : The address field designates the Target if several Targets can be reached through the VCI, and the detailed location within the target to which the request is made.

'This standard does not prescribe how Target addresses are allocated to address-space. For example, four FIFOs may be assigned consecutive word addresses while memories may occupy Megabytes.

'The address is updated for every operation in a packet even if the address algorithm is specified by means of the flags.

The address is specified as the lowest byte address of the concerned data.

Byte enable: The main role of byte enable is in write operations. Each asserted bit in this field designates a byte in the cell to be actually written into the target. Each non-asserted bit marks a byte are not to be overwritten.

In read operations, byte enable is needed in those wrappers or bridges where cell length or data alignment changes.

There are two separate naming conventions for byte enable, corresponding to a natural endianness.

BE [3: 0] is used for little endian VCs where the LSB (Least Significant Byte) is labeled Address 0.

BE [0 : 3] is used for big endian VCs where the MSB (Most Significant Byte) is labeled Address 0.

Write data: The write data field is only used in write operations. The data lines carry the bytes to be copied to the target.

Data are"naturally aligned" : the byte corresponding with byte address modulo cell size = 0 is at byte line 0 on the bus.

4.2.6 Response Contents Each request has its response. The response contents are validated with the RSPVAL signal. Contents include : Response Error: The Response Error field indicates whether the request could be handled correctly.

Read Data: The data returned as a result of a read request. This field has no meaning in write operations.

Data are"naturally aligned". The byte corresponding with byte address modulo cell size = 0 is at byte line 0 on the bus.

4.3 Basic VCI Signal Descriptions This is the first section of detailed BVCI technical description. Descriptions of the signals used between the Initiator and Target over the VCI are provided in the following.

4.3.1 Signal Type Definition Table 3 specifies the signal types that are used in Section 4.3. They are defined from the point of view of the devices rather than the wrapper or arbiter. Type Description IA Input to all devices IT Generated by the Initiator and sampled by the Target Generated by the Target and sampled by the Initiator MA Mandatory signal for both Initiator and Target MI Mandatory signal for the Initiator but an optional signal for the Target MC Mandatory signal for supporting chaining function for both Initiator and Target Table 3: Signal Type Definition Signals that do not have one of the mandatory descriptors listed above are optional and do not support the indicated function.

4.3.2 Signal Parameters.

Table 4 specifies parameters that are used in Section 4.3. Parameter Description B Number of bytes in a cell (must be a power of 2) Number of bits in the PLEN field (maximum value is 9) N Number of bits in the ADDR field E Number of bits in the RERROR field Q Number of bits in the CLEN field Table 4: Signal Parameters 4.3.3 Signal Directions The Figure 14 diagrams the signal directions between the Initiator and the Target. CLOCK CLOCK RESETN RESETN CMDACK « CMDACK CMDVAL CMDVAL ADDRESS ADDRESS BE # BE CFIXED # CFIXED CLEN CLEN CMD # CMD CONTIG CONTIG WDATA WDATA EOP EOP CONST CONST PLEN PLEN WRAP WRAP RSPACK RSPACK RSPVAL # RSPVAL RDATA RDATA REOP ; REOP RERROR l RERROR Initiator Target Figure 14. Diagram of VCI Signal Directions 4.3.4 Signal List All signals included in Table 5 below are assumed to be active-high signals unless explicitly indicated otherwise. It is recommended that all signal outputs are stable before Early. It can be assumed that all inputs are stable before Late. A detailed signal description follows the summary table.

Table 5 : Signal List Name Type Description , 1 :- ; 3,., 7 . ; tS. J-, : Gllial Sa a1s.,,, E CLOCK IA CLOCK provides the timing for all transactions. All signals are sampled on the Clock rising CLOCK edge. All timing parameters are initiated with respect to this edge. RESETN IA Reset is used to bring all devices up on a common signal. RESETN is an active Reset MA low signal and must be asserted for a minimum of 8 CLOCK cycles. The rising edge of RESETN is synchronous to the rising edge of CLOCK. . : CMDACK TI Acknowledge is used by the Target to indicate to the Initiator that a given cell Command MI can be transferred. Hence, a cell is transferred from the Initiator when both Acknowledge CMDVAL and CMDACK are asserted. CMDVAL IT Valid indicates that the Initiator wishes to perform a cell transfer to the Target. Command MI The cell is transferred when both the CMDVAL and CMDACK signals are Valid asserted. Re ust Coriten = 3 : ADDRESS [n- IT ADDRESS is the address of the request generated by the Initiator and received 1: 0] MA by the Target. The address updates for every cell transferred within a packet Address and must remain within the address space of a single Target. The pattern of addresses that are permissible are defined by the flags (CONTIG, WRAP, and CONST signals). ADDRESS contains the lowest byte address for the first transfer in the packet. For all cells after the first transfer, ADDRESS is aligned to a cell boundary. The combination of a cell-aligned address and byte enables is sufficient to perform the transfer correctly. However, the addition of extra information in the first address may allow performance advantage in some systems. Note that a non cell-aligned address is endian dependent. BE IT Byte Enable indicates which bytes of the cell being transferred or requested by [b-1 : 010 : b-l] MA the initiator are enabled. Byte Enable CFIXED IT Chain Fixed indicates that the opcode (CMD, CONTIG, WRAP, and CONST) Chain Fixed MC and PLEN fields will be constant across the chain and the address field behavior will be the same among packets within a chain. CLEN [q-l : 0] IT Chain Length indicates the number of packets remaining in a chain. The last Chain Length MC packet transferred in a chain will have a zero CLEN value. The CLEN value can also be tied off to zero if packet chaining is not required. CMD [1 : 0] IT Command is a 2-bit code defining the operation type being attempted by the Command MA Initiator to the Target and is encoded as follows: 00b = NOP, no data is actually transferred (optional) * Olb = READ, data is requested by the Initiator from the Target 1 Ob = WRITE, data is transferred from the Initiator to the Target 1 lob = LOCKED READ, data is requested by the Initiator from the Target with the added function of locking out access to at least the particular cell until a WRITE packet is transferred to the same cell (optional) CONTIG IT CONTIG indicates that the sequence of addresses that will be performed within Contiguous the packet is contiguous. When CONTIG is asserted, the address is normally increased by the cell size in bytes. If a packet does not start or end at a cell boundary, the first or last transfers contain less bytes than a cell. In such cases, the address is increased not by the length of a cell but by the amount of bytes actually transferred in such a first or last cell. Name Type Description WDATA [8b- IT WDATA is the data transferred by the Initiator to the Target during a WRITE 1: 0] MA command. The actual data bits that are enabled during a given cell's transfer are Data defined by the byte enables. The most significant bit is always on the LHS-bit 8b-1. The least significant bit is always on the RHS-bit 0. EOP IT End Of Packet is asserted on the last cell of a packet indicating that all cells End Of Packet MI associated with the given packet have been transferred. CONST IT CONST indicates that the address will remain constant throughout the entire Constant packet. When CONST is asserted, CONTIG and WRAP are ignored. PLEN [k-1 : 0] IT Packet Length indicates the length of the packet in bytes. The valid range for Packet Length PLEN is 1 to Zk-1 (1 to 511 given that k is limited to 9). A value of 0 for PLEN can be used to indicate that the packet length is undefined (no implied packet length). WRAP IT WRAP is used in conjunction with CONTIG to indicate how addresses that Wrap increment past the boundary indicated by PLEN are handled. If WRAP is asserted and PLEN has only a single bit set (indicating a power of 2 packet size), the address will wrap around. ' ; Resporise Haioclshake. :, ; RSPACK IT Response Acknowledge is used by the Initiator to indicate to the Target that a Response MA given cell will be transferred. Hence, a response cell is transferred from the Acknowledge target when both RSPVAL and RSPACK are asserted. RSPVAL TI Response valid indicates that the Target wishes to perform a response cell Response MA transfer to the Initiator. The response cell is transferred when both the Valid RSPVAL and RSPACK signals are asserted. ;,.",, Response Content, RDATA [8b-TI Response data is the data that is returned by the Target to the Initiator with 1: 0] MA Read-operations. Response Data REOP TI Response End of Packet is asserted on the last cell of the response packet Response End MA indicating that all cells associated with the given response packet have been Of Packet transferred. RERROR Response Error is asserted by the Target during a response packet to indicate Response Error that an error has occurred during the current packet.

Table 5: Signal List (continued) 4.3.5 System Level Signals Clock Signal Name: Clock Signal Abbreviation: CLOCK Polarity : Active at Positive edge Driven By: System Received By: VCI Initiator, VCI Target This signal provides the timing for the Virtual Component Interface and is an input to both the initiator and target that are connected via the BVCI. All initiator and target output signals are asserted/de-asserted relative to the rising edge of CLOCK and all initiator and target inputs are sampled relative to this edge.

Reset Signal Name: Reset Signal Abbreviation: RESETN Polarity: Asserted Negative Driven By : System Received By: VCI Initiator. VCI Target Timing: Asserted > 8 clock cycles This signal is used during power-on reset and is used to bring the BVCI to an idle or quiescent state. This idle state is defined as the BVCI state in which: 1. The [CMDIRSP] VAL signals are de-asserted 2. The [CMDlRSP] ACK signals are de-asserted The system must guarantee that RESETN is asserted for at least eight cycles of CLOCK.

(Larger if parameter RESETLEN is set.) 4.3.6 Request Signals Command Valid Signal Name: CommandValid Signal Abbreviation: CMDVAL Polarity : Asserted Positive Driven By: VCI Initiator Received By: VCI Target Timing: Asserted at rising edge of CLOCK until CMDACK = 1 and next rising edge of CLOCK.

The CMDVAL signal is driven by a VCI initiator to indicate that there is a valid request cell on the BVCI.

All of the initiator request signals are qualified by CMDVAL. The initiator keeps CMDVAL asserted, and all of its control signals valid and stable, until it receives the CMDACK signal from the target. The initiator should not assert CMDVAL unless the current transaction is intended for the target. Thus, the initiator may need to perform address decoding on its on-chip bus side to generate CMDVAL for the target, thereby accomplishing device selection.

Command Acknowledge Signal Name: CommandAcknowledge Signal Abbreviation: CMDACK Polarity: Asserted Positive Driven By: VCI Target Received By: VCI Initiator Timing: Asserted and negated at rising edge of CLOCK The CMDACK signal is asserted by the target to indicate the completion of a request between the initiator and target. In the case of write operations, this means that the target has accepted the data which is on the write data bus or will do so at he end of the current clock cycle. In the case of read operations, the assertion of the CMDACK by the target indicates that the target has accepted the request and started processing it.

The request completes as soon as the rising edge of CLOCK samples CMDACK. The target may de-assert the CMDACK by the next rising edge of CLOCK unless a new command has been initiated by the initiator, or default acknowledge is used. Similarly, the initiator de-asserts CMDVAL by the next rising edge of CLOCK unless it is presenting a new request.

Command Signal Name: Command Signal. Abbreviation: CMD Polarity: N/A Driven By: VCI Initiator Received By: VCI Target Timing: Asserted at rising edge of CLOCK until CMDACK == I at rising edge of CLOCK.

This signal is a two-bit command-field asserted by the initiator and indicates the nature of the requested transfer. It is encoded as follows : 00b = NOP, no data is actually transferred (optional) 0 1 b = READ, data is requested by the Initiator from the Target I Ob = WRITE, data is transferred from the Initiator to the Target 11 b = LOCKED READ, data is requested by the Initiator from the Target with the added function of locking out access to at least the particular cell until a write-operation is performed to the same cell- address This signal must be valid any time that the CMDVAL signal is asserted.

End-of-Packet Signal Name: End-of-Packet Signal Abbreviation: EOP Polarity: Asserted Positive Driven By: VCI Initiator Received By: VCI Target Timing: Asserted at rising edge of CLOCK until CMDACK = I at rising edge of CLOCK.

The EOP signal is de-asserted by the initiator to indicate that the transfer being performed will be followed with a transfer by the initiator to the next higher cell address. This signal is used by the target device to pre- calculate address in order to improve the data transfer performance. The packet transfer is completed once a cell is transferred with the EOP signal asserted.

Chain Fixed Signal Name: ChainFixed Signal Abbreviation: CFIXED Polarity: Asserted Positive Driven By: VCI Initiator Received By: VCI Target Timing: Asserted at rising edge of CLOCK until CMDACK = 1 at rising edge of CLOCK.

Chain Fixed indicates that the opcode (CMD, CONTIG, WRAP, and CONST) and PLEN fields will be constant across the chain and the address field behavior will be identical among packets within a chain.

Chain Length Signal Name: ChainLength Signal Abbreviation: CLEN Polarity: Asserted Positive Driven By: VCI Initiator Received By: VCI Target Timing: Asserted at rising edge of CLOCK until CMDACK = 1 at rising edge of CLOCK.

Chain Length indicates the number of packets remaining in a chain. The last packet transferred in a chain will have a zero CLEN value. The CLEN value can also be tied off to zero if packet chaining is not required.

Contiguous Signal Name: Contiguous Signal Abbreviation: CONTIG Polarity: Asserted Positive Driven By: VCI Initiator Received By: VCI Target Timing: Asserted at rising edge of CLOCK until CMDACK = I at rising edge of CLOCK.

Contiguous-signal indicates that the sequence of addresses that will be accessed within the packet is contiguous. When CONTIG is asserted, the address is normally increased by the cell size in bytes. If a packet does not start or end at a cell boundary, the first or last transfer contains less bytes than a cell. In such cases, the address is increased not by the length of a cell but by the amount of bytes actually transferred in the first or the last cell. In middle-part of the packet, the address always increases by cell size, when CONTIG is active.

Packet Length Signal Name: PacketLength Signal Abbreviation: PLEN Polarity: Asserted Positive Driven By: VCI Initiator Received By: VCI Target Timing: Asserted at rising edge of CLOCK until CMDACK = 1 at rising edge of CLOCK.

Packet Length indicates the length of the packet in bytes. The valid range for PLEN is 1 to 2k-1 (I to 511 given that k is limited to 9). A value of 0 for PLEN can be used to indicate that the packet length is undefined (no implied packet length). In this case, the packet ends as a cell is transferred with EOP active.

PLEN is held constant over the packet. Thus, PLEN does not indicate"remaining length".

Constant Signal Name: Constant Signal Abbreviation: CONST Polarity : Asserted Positive Driven By: VCI Initiator Received By: VCI Target Timing : Asserted at rising edge of CLOCK until CMDACK = I at rising edge of CLOCK.

Constant indicates that the address will remain constant throughout the entire packet. When CONST is asserted, CONTIG and WRAP are ignored.

Wrap Signal Name: Wrap Signal Abbreviation: WRAP Polarity : Asserted Positive Driven By: VCI Initiator Received By: VCI Target Timing: Asserted at rising edge of CLOCK until CMDACK = l at rising edge of CLOCK.

Wrap is used in conjunction with CONTIG to indicate how addresses that increment past the boundary indicated by PLEN are handled. If WRAP is asserted and PLEN has only a single bit set (indicating a power of 2 packet size!), the address will wrap around. If the packet length is not power of two or if CONTIG is not active, the WRAP signal is don't-care. The wrap address equals to (ADDR and not (PLEN-1)) + PLEN. The next address after wrapping equals to (ADDRESS and not (PLEN-1)).

Address Signal Name: Address Signal Abbreviation: ADDRESS [n-l : 0] Polarity: N/A Driven By: VCI Initiator Received By: VCI TargetTiming: Asserted at rising edge of CLOCK until CMDACK = 1 at rising edge of CLOCK.

ADDRESS is the address of the request generated by the Initiator and received by the Target. The address updates for every cell transferred within a packet and must remain within the address space of a single Target. The pattern of addresses that are permissible are defined by the operation type (CONTIG, WRAP, and CONST signals). ADDRESS contains the lowest byte address for the first transfer in the packet. For all cells after the first transfer, ADDRESS is aligned to a cell boundary. The combination of a cell-aligned address and byte enables is sufficient to perform the transfer correctly. However, the addition of extra information in the first address may allow performance advantage in some systems. Note that a non cell- aligned address is endian dependent.

Byte Enable Signal Name: Byte Enable Signal Abbreviation: BE [b-1 : 010 : b-1] Polarity: Asserted Positive Driven By: VCI Initiator Received By: VCI Target Timing: Asserted at rising edge of CLOCK until CMDACK = 1 at rising edge of CLOCK.

BE is a b-bit field that indicates which bytes of the cell being transferred are enabled. The b equals to total data width of the BVCI/8. These signals must be valid any time that the CMDVAL signal is asserted. In write transfers, the disabled bytes are not overwritten. In read transfers, the target may or may not present the disabled bytes in the RDATA bus. They are ignored by the initiator. The direction of the BE-signal range numbering depends of the endiannes.

Write Data Signal Name: Write Data Signal Abbreviation : WDATA [8b-1 : 0] Polarity: N/A Driven By: VCI Initiator Received By: VCI Target Timing: Asserted at rising edge of CLOCK until CMDACK = 1 at rising edge of CLOCK.

The write data lines are driven by the VCI initiator and are used to transfer write data from an initiator to a target device. Write data consists of b logical byte lanes, based upon the capabilities of the target and is defined and fixed at the time of component instantiation. Allowed values of b are power of two. Bit 8*b-1 is the most significant bit of the most significant byte and bit 0 is the least significant bit of the least significant byte. The write data lines must contain valid write data while the CMDVAL signal is asserted and the CMD is indicating a write transfer.

For VCs supporting a data size that is not an eight bit increment, the next larger supported bus size will be used with the unused bits tied to logic zero. For example, a 12-bit device must use a 16-bit wide VCI with the 4 Most Significant bits tied to logic zero.

4.3.7 Response Signals Response Valid Signal Name: ResponseValid Signal Abbreviation: RSPVAL Polarity : Asserted Positive Driven By: VCI Target Received By: VCI Initiator Timing: Asserted at rising edge of CLOCK until RSPACK = 1 at rising edge of CLOCK.

The RSPVAL signal is driven by a VCI target to indicate that there is a valid response on the BVCI. All of the target response signals are qualified by RSPVAL. The target keeps RSPVAL asserted, and all of its control signals valid and stable, until it receives the RSPACK signal from the target.

Response Acknowledge Signal Name: ResponseAcknowledge Signal Abbreviation: RSPACK Polarity: Asserted Positive Driven By: VCI Initiator Received By: VCI Target Timing: Asserted and negated at rising edge of CLOCK The RSPACK signal is asserted by the target to indicate the completion of a response transfer between the initiator and target. This means that the initiator has accepted the response data, which is on the target's response signals, or will do so at he end of the current clock cycle. The response completes as soon as the rising edge of CLOCK samples RSPACK. The initiator may de-assert the RSPACK by the next rising edge of CLOCK unless a new response has been initiated by the target, or default acknowledge is used.

Read Data Signal Name: Read Data Signal Abbreviation: RDATA [8b-1 : 0] Polarity: N/A Driven By: VCI Target Received By: VCI Initiator Timing: Asserted at rising edge of CLOCK until RSPACK = 1 at rising edge of CLOCK.

The read data lines are driven by the VCI initiator and are used to transfer read data from a target to an initiator device. Read data consists of b logical byte lanes, based upon the capabilities of the target and is defined and fixed at the time of component instantiation. Allowed values of b are power of 2 bytes. Bit 8*b-I is the most significant bit of the most significant byte and bit 0 is the least significant bit of the least significant byte. The read data lines must contain valid read data while the RSPVAL signal is asserted and the response is to a read request.

For VCs supporting a data size that is not an eight bit increment, the next larger supported bus size will be used with the unused bits tied to logic zero. For example, a 12-bit device must use a 16-bit wide BVCI with the 4 Most Significant bits tied to logic zero.

Response End-of-Packet Signal Name : ResponseEndofPacket Signal Abbreviation: REOP Polarity: Asserted Positive Driven By: VCI Target Received By: VCI Initiator Timing: Asserted at rising edge of CLOCK until RSPACK = I at rising edge of CLOCK.

Response End of Packet is asserted on the last cell of the response packet indicating that all cells associated with the given response packet have been transferred.

Response Error Signal Name: Response Error Signal Abbreviation: RERROR [E: 0] Polarity : Positive Driven By: VCI Target Received By: VCI Initiator Timing: Asserted at rising edge of CLOCK when RSPVAL 1, until RSPACK = 1 at rising edge of CLOCK.

Error signal is valid only when RSPVAL=1, with the following meaning : For ERRLEN = 0 (E=0) RERROR=0 : Normal (no error) RERROR=I : General data error. The entire packet is considered bad.

For ERRLEN = 1 (E=1) RERROR = 00: Normal (no error) RERROR =01 : General data error. The entire packet is considered bad RERROR = 10 : Reserved RERROR = 11 : Abort Disconnect For ERRLEN =. 2 (E=2) RERROR =000: Normal (no error) RERROR = xx0 : Reserved RERROR = 001 : General data error. The entire packet is considered bad RERROR = OH Reserved RERROR = 101 : Bad data (retry) RERROR= 111 : Abort Disconnect After receiving an error, the Initiator may or may not continue with the current packet. If it chooses to end the packet prematurely, it can do so by asserting EOP regardless of the PLEN value. After this, it can choose not to try a transfer anymore (Abort) or Retry part or all of the transfer. For any error, the Target must process the subsequent pending cells and packets with the normal protocol, i. e. it must continue sending responses until it has processed the EOP with or without further errors signaled. In general, the RERROR is more informative than prescriptive, and the Target may not assume any special behavior from the Initiator. The Initiator is anyhow encouraged to act responsibly, when it meets an error.

It is strongly recommended that all BVCI components would support at least one bit error. The BVCI target is strongly recommended to signal an error when it receives a request it does not support. Obviously, VCI provides also with a possibility to get error records through normal Read-requests from the Target, but this belongs to domain of a particular Virtual Component's implementation.

4.4 Basic VCI Protocol 4.4.1 Protocol Fundamental The Virtual Component Interface (VCI) protocol is described as a set of three stacked layers: transaction layer, packet layer and cell layer.

4.4.1.1 Transaction Layer The transaction layer is above the concerns of hardware implementation. It defines the system as a series of communicating objects which can be either hardware or software modules. The information exchanged between Initiator and Target nodes is in the form of a request-response pair as illustrated in Figure 15 below. Initiator Target Request Response P Figure 15. System Transaction Layer View of Information Transfer over the VCI Transaction A pair of request and response transfers is called a transaction. Typically, the basic unit of information exchanged is some form of data structure. As the communication is decomposed to lower layers of abstractions, the basic transfer unit becomes smaller.

4.4.1.2 Packet Layer The packet layer adds generic hardware constraints to the system model. In this layer, VCI is a bus- independent interface that supports point to point physically address-mapped split transactions between Initiators and Targets in unit time. There will not yet be a commitment to a particular interface width. In this layer, the request and response information to be transferred across the interface is split into more manageable chunks, on the basis of generic hardware constraints. This is illustrated in Figure 16 below. Initiator Target Request Packets v VCI packet Response Packets,,. g, § ;-g ; LVCI packet '. 1VCI'packet..,.,.'.... VCI packet J LVCI packet. VCI packet VCI packet J Figure 16. Packet Layer View of Information Transfer over the VCI Operation A transaction is called a VCI operation if the information is exchanged using atomic request and response transfers across the interface. The information exchanged during an operation is in the form of a VCI packet, a packet layer transfer unit defined in the following section. In a packet layer, a VCI transaction decomposes into one or more operations.

Packet Packet is the basic unit of information that can be exchanged over the VCI in an atomic manner. The point to point connection between Initiator and Target is maintained throughout the transfer of a packet.

The request and response transfer units of a VCI transaction are decomposed into one or more request- response packet pairs. Multiple packets can be combined to form larger ; non-atomic transfer units called packet chains, as explained in the next chapter. A VCI operation is a single request-response packet pair.

For each request packet transferred from Initiator to Target, there will be one corresponding response packet transferred from Target to Initiator. The Targets shall return response packets in the same order as request packets are issued.

The content of a packet depends on whether it is a request or response packet and the type of operation being carried out-such as read, write etc. The data field of request packets is relevant only for write operations. The field, RDATA, in response packets contains valid values only for read and locked read operations. The request packet header contains information on packet chaining. More details on other packet fields will be introduced in subsequent sections.

Packet length is the number of bytes transferred during a read, write, or locked read operation. This field is irrelevant for NOP operations. A zero value specified for PLEN in read, write, or locked read operations indicates that the length of the packet is undefined. Long packets can result in reduced arbitration overhead and some optimization in certain areas like read pre-fetching and SDRAM access. This can improve the data transfer rate for that particular thread. However, very long packets transferred over a shared interconnect system lock out all other agents, causing degradation of the system performance. Hence, it is highly recommended to use short packets to optimize the overall system performance and to use the packet chaining mechanism, described in the next section, to create long, but non-atomic, transfers.

Packet Chain The packet chain mechanism allows a VCI Initiator to describe linkage between related packets to the system. The system can combine chained packets into larger, more efficient, higher performance transfers that satisfy the constraints of the system application. Packet chains produce the same transfer efficiency that long packets provide without requiring the entire transfer to be atomic.

Two fields in the request packet header, CLEN and CFIXED, specify the packet chaining information.

CLEN describes the number of packets remaining in the chain (not including the current packet). This field is normally decremented with every transmitted packet.

The flag, CFIXED, provides information about the linkage between the header fields among the packets in a packet chain. If set, CFIXED guarantees that the opcode and packet length fields will be constant across the chain.

The packet chain mechanism allows the VCI Initiators to minimize their packet length to that which is required for proper operation (i. e. functionality). This mechanism concurrently provides the interconnect logic and the Target with enough information for optimizing the chained transfers to meet application performance and efficiency requirements.

4.4.1.3 Cell Layer The cell layer adds more hardware details such as interface width, handshake scheme, wiring constraints, and a clock to the system model. This layer is not concerned about shared interconnects and arbitration for such services. In the cell layer, VCI is viewed as a bus-independent, point to point interface that supports physically address-mapped split transactions between Initiators and Targets, using a cycle-based handshake protocol. Introduction of interface width information enables decomposing of packets (the basic transfer unit defined in the packet layer) into cells that are handshaken under a cycle-based protocol across the definitive sized interface.

Cell A cell is the basic unit of information, transferred on rising CLOCK edges under the VAL-ACK handshake protocol, defined by the cell layer. Multiple cells constitute a packet. Both request and response packets are transferred as series of cells on the VCI. The number of cells in a packet depends on the packet length and the interface width.

The structure of a cell is very similar to that of a packet, except for the decomposing of WDATA and byte enable fields and the introduction of end-of-packet fields. The opcode fields, chaining information, and PLEN in a request cell are the same as the corresponding request packet fields.

The request cell structure and response cell structure is detailed in Tables 6 and 7 below. ..,, t .,. _v :.. :,. .. Information oin °"''n h. 'el ,... x"E s t. . Descr tio _ Packet chain. CLEN Number of rerriaining packets in the chain Packet chain CLEN Number of remaining packets in the chain Information ADDR f Address of each cellbeing transferred ADDR Address of each cell being transferred CMD Command : read, write, nop or locked read to Opcode WRAP WRAP address mode W w w ' . °, Qa3dress mod _.-- BE Byte Enable: indicates which bytes are involved in the operation > m g EOP Indicates if the cell is the last one in the request packet Table 6: Request Cell Structure ~, Ht, e-, n « w » hm 2 _ Æ RERROR Error status for the cell REOP Indicates if the cell is the last one in The response packet REOP Indicates if the cell is the last one in the response packet Table 7: Response Cell Structure VAL-ACK Handshake The VAL-ACK handshake provides unambiguous synchronization of Initiator and Target modules for transferring cells over the interface. It is a simple handshake protocol based on two control signals. Two separate sets of handshake signals are used in the VCI interface: one for transferring request cells from Initiator to Target, and the other for transferring response cells from Target to Initiator. The transfer of request and response cells over the interface are completely de-coupled, concurrent events. The handshake fundamentals explained below apply to both request and response channels. Generic names, VAL and ACK, are used in the discussion for the control signals. These names represent CMDVAL and CMDACK signals of the request channel and RSPVAL and RSPACK signals of the response channel.

Cell transfer on the channel is solely controlled by the following two signals (Table 8): VAL Driven by the initiator module to indicate that a cell was placed on the interface and is ready for transfer ACK Driven by the target module to indicate that it has received the cell, if any was present as | announced by VAL.

Table 8: Handshake Signals Table 9 summarizes different encoding for the VAL-ACK signals and the corresponding channel states. 0 0 IDLE The channel is in idle state. 0 0 IDLE The channel is in idle state. 0 0 y IDLE The channel is in idle state. 0 1 DEFAULT ACK Ready to Grant E -a _ a _,. .. a n.. L _ : s _A .

Table 9: VAL-ACK Encoding and Channel States The channel is in IDLE state when both VAL and ACK are de-asserted. The initiator module unconditionally asserts VAL when the cell information is placed on the interface. The target module may delay the assertion of ACK if it is not ready to accept the cell. The channel is said to be in REQUEST state if ACK is not asserted for a VAL on the rising edge of the CLOCK. The channel state transitions to SYNC when both VAL and ACK are asserted. The handshake synchronization and cell transfer occur on each CLOCK edge when the VCI is in SYNC state. (See Figure 17.) cell e c ack celle c u .,..

Figure 17. VAL-ACK Handshake for Single-Cell Transfer While transferring a multi-cell packet, either module can insert wait cycles by de-asserting VAL or ACK.

The receiving module can assert ACK, even when VAL is not present, to indicate that it is ready to ACK the next VAL. The corresponding channel state is DEFAULT ACK. In this case, cell transfer will occur on the first CLOCK edge on which VAL is asserted.

Once the initiator module asserts VAL, it cannot change that signal until the requested cell is transferred, regardless of the state of ACK. Similarly, once the receiving module asserts ACK, it should not de-assert that signal until a cell is transferred. Generally, neither module shall change its mind once it has committed to the cell transfer.

However, de-committing of the ACK signal may be necessary in certain scenarios, such as a default ACK from a bus wrapper module to an Initiator, where this bus is"parked". Such deviations from the recommended interface behavior should be clearly documented when VCs are implemented. Table 10 below summarizes all the permitted state transitions. 1, ix ao, : ; _ -_ . vfath w . t, zr 4 IDLE IDLE Valid Continues in idle IDLE IDLE Valid Default Acknowledge asserted Kw _ IDLE DEFAUJ>T_ACK Yalid Default Acknowledge asserted % w w ~ ZD , , , . :, a g >, wUall, _.; e SHalW: ac o; ed¢sl; o $. a '' VAL IDLE Invalid Valid de-committing not allowed aswS VAL DEFAULT ACK Invalid Valid de-committing not allowed '°". , y" fr' i x ;. s _. alda llalad ; Acknoleg_ DEFAULT ACK IDLE Invalid Acknowledge de-committing not allowed m. Dnr e niSmw S vs _ DEFAULT ACK DEFAULT GRANT Valid Acknowledge maintained "A:', -, riC ' alrl, ' d 1c wd SYNC IDLE Valid Back to idle SYNCDEFAULTACK VaMDefault Acknowledge asserted k. '1'i t.'.... i hl. li'', in.. . cir, i7w lbln.... x t, '. nnk i aw= w _ Table 10: Permitted State Transitions VAL Time and ACK Time VAL time and ACK_tiem are introduced as a way of classifying the handshakes. Definitions follow : # VAL_time = number of cycles where VAL is de-asserted between cell transfers.

ACK_time = number of cycles where VAL is asserted before ACK is asserted.

Figures 17-19 illustrate different VAL-ACK handshakes. ! !'= val _r _ _ clock Val cell Figure 18. VAL-ACK Handshake with VAL Time = 0, ACK Time = 0 clock val cell ack Figure 19. VAL-ACK Handshake with VAL Time = 0, ACK Time = 1 clock clock cell cell cell c Figure 20. VAL-ACK Handshake with VAL Time = 1, ACK Time =1 4A. 2 Basic VCl Operations The basic transfer mechanism in VCI is packet transfer. Every operation on the VCI consists of a request packet transfer from the Initiator to the Target and a response packet in return. Both Initiator and Target modules are responsible for transferring the VCI request and response packets across the interface in an atomic manner. A packet is sent as a series of cells with the EOP (end of packet) field in the last cell set to value 1. Each cell is individually handshaken across the interface under the VAL-ACK handshake. Either the Initiator or the Target can insert wait cycles between cell transfers by de-asserting VAL or ACK. The order of packets and the number and order of cells within packets should be maintained the same between request and response transfers.

The transfer of request and response cells over the interface are completely de-coupled concurrent events.

The signals used for encoding cell information, handshake signals, and the timing of the request and response transfers are totally separate.

All VCI signals are sampled on the rising edge of the CLOCK. The handshake signals CMDVAL, CMDACK, RSPVAL, and RSPACK are sampled on every rising CLOCK edge. The rest of those signals that encode the request and response cells are sampled on rising CLOCK edges, qualified by the corresponding VAL signal. The timing diagrams in this section show the relationship of relevant signals involved in illustrated operations.

4.4.2.1 Read Operation Figure 21 below illustrates a 32-byte read operation on a 32-bit wide VCI. The operation starts with the Initiator placing the first cell of a request packet on the interface and asserting CMDVAL on CLOCK 2.

The cell information is encoded in the signals: CMD, CONTIG, WRAP, CONST, PLEN, EOP, ADDRESS, and BE. The fields on chaining information, CLEN and CFIXED, are both set to value 0 for this operation and are not shown in the diagram.

As shown in Figure 21 : The CMD and addressing mode flags, CONTIG, WRAP, and CONST, specify that the packet is part of a read operation with contiguous cell addresses.

'The field PLEN indicates that the packet length is 32 bytes.

The address field contains the address of the Target and the byte address of the location from where the data is requested.

BE indicates which byte lanes are involved in the first cell transfer.

EOP is set to 0 to indicate that the current cell is not the last one in the packet. The earliest the cell transfer can complete is in CLOCK period 2 itself, if the signal CMDACK is asserted combinatorially or if the channel is in default acknowledge state. In this example, the target module asserts CMDACK in the CLOCK period 3 (ACK time = 1) and the cell transfer completes in that CLOCK cycle.

The Initiator module updates the ADDR and BE signals to reflect the address and byte enable information for the second cell of the packet being transferred. Note that the address (n-l : m) field does not change. (It is illegal to address more than one Target within same packet.) The signals: CMD, CONTIG, WRAP, CONST, and PLEN (also CLEN and CFIXED, which are not shown) are common to all the cells in the request packet. clock L L L L LJ cmdeck cmd I I I r, aq 1-1- cmd drap crap constant plen (k : 0) eop address (n-1 : m) r address (m-1 : O) F < ; t I% ; iffl S be ffi taI W l | | > m mT a i rspval l _. _ _. | < reop < L _.. _ _ r w address (m- : 0) r r r «' T r be rspval space reop rarror valid valid valid valid valid valid valid valid rdata a a Figure 21.32-byte Read Operation on a 32-bit VCI All the eight cells in the request packet are transferred in 8 CLOCK cycles with CMDVAL and CMDACK asserted corresponding to VAL time = 0 and ACK time = 0. The CMDVAL for the last cell is asserted at CLOCK period 9 and the cell transfer completes on the same cycle. Note that the Initiator asserted the signal EOP at CLOCK 9 to indicate that the cell being transferred is the last one in the packet.

In the response channel, the Initiator continuously asserts the signal, RSPACK, indicating its readiness to accept the response cell with ACK time = 0. This is a default acknowledge condition, as the CMDACK is asserted when CMDVAL is not present. All the eight response cells are transferred in 8 CLOCKs as both VAL time and ACK time are 0. The first cell is transferred in CLOCK 3 when the Target module asserts RSPVAL. The Target continues to assert RSPVAL until CLOCK 10, transferring one cell on every CLOCK edge. At CLOCK 10, the Target also indicates to the Initiator through REOP that the current cell is the last one in the response packet. Each response cell contains the read data (on RDATA) and the error flag (on RERROR).

4.4.2.2 Write Operation Figure 22 illustrates a 32-byte write operation on a 32-bit VCI. A write operation is similar to a read operation except that: 1. The Initiator provides the write data on signal WDATA as part of each request cell, and 2. The field RDATA is not significant.

The operation starts with the Initiator placing the first cell of a request packet on the interface and asserting CMDVAL on CLOCK 2. The cell information is encoded in the signals: CMD, CONTIG, WRAP, CONST, PLEN, EOP, ADDRESS, BE, and WDATA.

As shown in Figure 22 below : The signal, CMD, indicates that the packet is part of a write operation.

The addressing mode flags, CONTIG, WRAP, and CONST, specify that the cell addresses are contiguous.

BE indicates which byte lanes are valid in the write data.

The Initiator module updates the ADDRESS, BE, and WDATA signals upon every cell transfer to reflect the byte address, enable information, and the data, until all the four cells in the packet are transferred. Note that the address is updated for every cell, even though the opcode field indicates that the cell addresses are contiguous. clock cmdval----- cmdacle cmd constant wrap constant plen (k: O) top address (n-1 : m) rye address (m-1 : 0) r I I I data a a a a be rspval rspval reap rerror alid alid aild plen (h : O) tE = = tTr X X eop w i r r S address (n-1 : m) @ t X l address (m-1 : 0) w $> Xt ; <<ie w data : g e tet% X X be S KDI llLL 11 1 1 t,) S rspval __ _J-. _ _. t m rerror E _/alid/alid 5 aiid {alid oalid salid l/alid slid j j Figure 22.32-byte Write Operation on a 32-bit VCI All the eight cells in the request packet are transferred in 8 CLOCK cycles with CMDVAL and CMDACK asserted corresponding to VAL time = 0 and ACK time = 0. The response cells are also transferred in 8 CLOCKs. The only information contained in write response cells is the error flag (on RERROR).

4.4.2.3 Other Operations Two other operation types supported on VCI are NOP and Locked Read. The NOP operation is similar to a read or write operation, except that the CMD field of the request packet contains value'00' (NOP) and there is no data transferred along with request and response cells.

The locked read operation is similar to a read operation. The only difference is in the CMD signal encoding. The Target module/system locks out at least the memory locations addressed by the locked read request until another operation is issued to the same locations by the same Initiator.

Packet Chain Transfer Figure 23 below illustrates a read transaction on the VCI composed of two operations grouped through the packet chaining mechanism. The operations are similar to the normal read operations except that the packet chaining information is provided along with the request packets. This information is encoded on signals CLEN and CFIXED.

CLEN specifies the number of packets remaining in the chain excluding the current one. In this example it is 2-1 = 1. Note that this information is CONST within the packet and dynamic across packets. CLEN is specified as 0 for the second request packet, indicating that it is the last packet in the chain.

The flag, CFIXED, is asserted for the first packet to indicate that same opcode will be used for all the packets in the chain. CFIXED also guarantees that the address relationship between the last cell of a packet in the chain and the first cell of the following packet will be the same as the one defined by the ADDRESS mode flags for cells within packets. In this example, CFIXED = 1, guarantees that the cell addresses will be contiguous across the packet chain. clock cmdval cmdack r cmdack cmd rea r a wrap constant constant plen cfixed eop eop address (m. 1 : 0) t _t t t t t 31gi be tC J ; LC w m n g rspval044--LLL wLL rt--ttlt-t t address (n-1 : m) rg address (m-1 : 0) be rspval rspack-'- reop rerror rdata Figure 23. Packet Chain Transfer on the VCI The chaining information on the first packet along with the packet header information conveys to the Target module that the Initiator module intends to read (CLEN + 1) x PLEN = (1 + 1) x 16 = 32 bytes of data from contiguous address locations starting from ADDRI. This information provides an option to the Target module to combine the two request packets to improve the transfer efficiency, if possible. In this example, it is assumed that the Target treats the packet chain as a single packet containing 8 cells to perform a high efficiency data fetch. Note that the first response packet has a latency of 9 CLOCKs whereas the second response packet arrives 4 CLOCKs after the arrival of the corresponding request packet.

4.4.2.4 Address Modes The VCI requires the Initiator to provide cell addresses along with every request cell transferred to the Target module. In addition, the Initiator may also specify a predefined algorithm to calculate subsequent cell addresses from the previous cell address using the three addressing mode flags, CONTIG, WRAP, and CONST. When none of the flags are asserted by the Initiator, it indicates that there is no predefined relationship among cell addresses.

Random Address Mode When none of the opcode flags are asserted, the initiator specifies random cell addressing mode. In this case, there are no predetermined relationships among cell addresses. Figure 24 below illustrates a] 6-byte read operation with random address mode. cloche cmdval cmdack cmd contain drap konstant top eop address (n-1 : m) r eop w h~ I ; t 4 t w = S m address(m-1 : 0) r r r r be rspval rspack------- reap rerror valid valid valid valid be M bCE zar : MT PCZ ! : : !-is w X reop M m m g = u m w i__ __ __/ ! renror w X X S B S i valid valid waliri valid rdata a Figure 24.16-byte Read Operation with Random Address Mode Contiguous Address Mode When CONTIG is asserted and WRAP is not asserted, the cell addresses advance in a contiguous manner.

In this case, cell addresses can be calculated by adding the number of bytes transferred in the previous cell to the previous cell address. Figure 25 below illustrates a 12-byte read operation with contiguous address mode. clock cmdval cmdack cmd ru contig drap constant plen (k: C) eop address(n- : m) ar e address (m-1 : 0) p a p r p a a bu rspval rspack repp rerror valid valfd valid valld - rdala «'a a a a a cmd ffi C lTl'rG | | | r I X plen (k : 0) S yCG z DE LLL l 17'') g1 eop itA 4 4 _ > _ r. __ W1 w w address (n-1. m) w < =) w w address (m-t : 0) w i P_, Pt | ¢ iz = < be = JLg | (m t i im §lT reop w w m= 11 8t_ ___. __ 5 w rerror @ w =3 m i, vaDd valid valir : valid 2 rdala 2 2 m m i<i v 3 g Figure 25. 12-byte Read Operation with Contiguous Address Mode Wrap Address Mode This addressing mode is specified by assertion of the flags, CONTIG, and WRAP. If the WRAP mode is specified and the field PLEN is specified as 2AA, then the following action take place. The cell address advances in a contiguous manner and wraps around when the sum of the number of bytes transferred and the lower A+] bits of the cell address is more than the value of PLEN. (The carry bit does not propagate beyond bit location A.) A 16-byte read operation in WRAP address mode is illustrated below in Figure 26. clock cmdval crndack J cmd contfg wrap constant p_len (k : 0) eop address(n-l : m) °p ./-'-' address (m-1 : 0) r h a r a r r BYE bye space 1 repp- rerror valid valid valid valid rdata a a a a a e ... reop E = m mw@ m... r m renror E E E im = = L valid vaDd valid vDd ffi rdaRa m m = l@ m m 8E flãlãT e3 B Figure 26.16-byte Read Operation with Wrap Address Mode Constant Address Mode The constant address mode is specified using the flag CONST. When this mode is specified for a request packet, the cell address remains the same as the starting cell address across all the cells in the packet/packet chain. Figure 27 below illustrates a 16-byte read operation in constant mode. Note that all the bits in the ADDRESS (n-l. 0) remain constant for all the cells in the packet. clock - cmdval cm cod constant sou top- - address (n-1 : m) address (m-1 : 0) r bu rspval---- repp reop- rerror valid valid valid valid rdata ' omd m ; = EI mr = Cl=l w g constant m zt _ _ _. _ w plen (h 0) mli kCI w HI | w 3 address (n-1 : m) = LCI l | tFl eSi | 7 l m m address (m-1 : 0) X z x | if apr | l l CC | l l) E El be 1 a rT E1 : ZICI) X X reop t m X | = =l = 1 ! 1 L___ ___ ___ r 8 renror g ! | b valid valir1 valid valid rdata = w = w w E (m J ! XE X9 Figure 27.16-byte Read Operation with Constant Address Mode 4.4.3 Basic VCI Signaling Rules The following rules apply: For each packet transferred on the request channel, there should be exactly one response packet transferred back on the response channel.

'The order in which packets are transferred on the response channel should be same as the order in which the corresponding packets appear on the request channel.

The number of cells in response packets should be same as in the corresponding request packets irrespective of the opcode.

The order of cells within a response packet should be same as the order in the corresponding request packet.

Once CMDVAL is asserted, the initiator module cannot change that signal until the requested cell is transferred regardless of the state of CMDACK.

Once a cell is placed on the interface and CMDVAL is asserted, the initiator module cannot modify the cell content until the requested cell transfer is complete.

ADDRESS (n-1 : m), the top n-m bits of the ADDRESS signal which indicates the target being addressed, should remain constant across all the cells in a packet.

Opcode signals, CMD (1 : 0) and the ADDRESS mode flags should remain constant throughout the packet transfer.

PLEN signal, which indicates the length of the request packet, should remain constant throughout the packet transfer.

'CLEN and CFIXED signals should remain constant across all the cells within a packet. It is recommended that the field, CLEN, should either stay constant or decrement (by one) with every packet transfer. It is legal for the initiator to change CLEN in unexpected ways between packets. This behavior is discouraged, as it adds complexity to the Target. Initiators that exhibit this discouraged behavior must document it, and Targets must document what CLEN behavior they can accept.

Changing the CMD field between packets in a packet chain is strongly discouraged. Initiators that exhibit this discouraged behavior must document it.

Asserting the flag WRAP without asserting CONTIG is invalid. Asserting WRAP when PLEN is not a power of 2 value is also invalid.

The Initiator shall not assert byte enable bits for those bytes that are outside the address range indicated by the address and PLEN fields.

It is recommended that once the receiving module asserts CMDACK, the module cannot change that signal until the next clock cycle. This insures the transferred cell is not corrupted.. 4.4.4 Additional Timing Diagrams Additional timing diagrams follow. clock cmdval cmdack- cud clock (k : 0) cmd m 11 X w I plen (k : O) m UII B11 7m3 =E I eop address (n-1 : m) address (m-1: 0) be data rspval rspac : reop- rerror vali Figure 28. l-byte Write Operation on a 32-bit VCI clock cmdval cmdack cmd I=% cmd plen (k : 0) eop address (n-1 : m) tafqqt address (m-1 : 0) r be data rspval data w (llJL lqtv I I X g rspval __. ___ f L _ rspac reop rerror i-valied Figure 29.4-byte Write Operation on a 32-bit VCI 5. Design Guidelines 5.1 User'Guide This section describes the high-level responsibilities of the VC Initiator and VC Target, together with the associated implementation considerations, discussing also about the differences between Basic VCI and Peripheral VCI. The focus is especially in describing use of the VCI with an on-chip bus.

While the VC Initiator to OCB Initiator Wrapper interface is identical in protocol to the OCB Target Wrapper to VC Target interface, the differences between the VC and the OCB show up in the implementation considerations. There are at least two good reasons to keep the VC->OCB interface identical to the OCB->VC interface: < Fe eq 3,. Wrapped Bus Example VCI VCT CI VCl O : B. y Your Favorite OCB Figure 30. VCI Block Diagram 1. This facilitates direct VC=>VC connections (i. e. without an intervening OCB) 2. VC Initiators have communication features similar to OCBs (pretty obvious, given the heritage of most OCBs). Thus, we can use existing VC Initiators as reasonable test cases to ensure that the OCB Initiator responsibilities are reasonable. A similar argument may be made for the OCB Target responsibilities.

The intended use for the Peripheral VCI is in VC-VC communication, and wrapping a VCI Target to an On-Chip Bus. Although it is possible to use the Peripheral VCI as a bus initiator, this is an unlikely case, since usually the peripheral bus initiator is a bus bridge from a system bus. So, the Peripheral VCI properties are tuned more towards the use as a peripheral bus target. The Basic VCI is more versatile and its features are tuned towards use as either an initiator or a target for an OCB.

Another possible topology is presented in Figure 31. In this case, there is no bus, but all the VCI Targets are connected point-to-point to a central OCB-VCI bridge. In this case, the bridge looks like a single target to the OCB in question, and contains a number of VCI Initiators. The bridge is more complicated than a bus wrapper, but the electrical design of point-to-point VCI connections may be easier than design of a shared bus. System OCB vci | sl > vcl ici VCI VC1 v Figure 31. VCI with Star Topology The following discussion covers the responsibilities of four different entities, as depicted in Figure 30: VC Initiator, OCB Initiator Wrapper, OCB Target Wrapper, and VC Target. Main differences with the BVCI and the PVCI are discussed.

5.1.1 VC Initiator Responsibilities The VC Initiator is in complete control over the presentation of requests on its VC Interface; there is no arbitration. It asserts the CMDVAL (VAL for PVCI) signal to indicate that a valid request information are present. The size of ADDRESS and [W\R] DATA are dictated by the VC's capabilities, as is the set of supported transfer widths. It must hold the request information stable until it samples CMDACK (ACK for PVCI) asserted at the rising edge of CLOCK. On a read transfer, PVCI Initiator must acquire RDATA once it samples ACK asserted at the rising edge of CLOCK in PVCI. In BVCI, the VC Initiator can delay acquiring RDATA by holding RSPACK de-asserted, while RSPVAL is asserted. Once the BVCI Initiator asserts the RSPACK, it must complete the response transfer once it samples RSPVAL asserted at the rising edge of CLOCK.

The provider of the VC Initiator must provide a list of VCI contiguration parameters for the VC, including such aspects as address/data bus widths, supported transfer widths, and timing data. These parameters allow the system integrator to configure the OCB Initiator Wrapper to meet the constraints of both the system and the VC Initiator.

5. 1.2 OCB Initiator Wrapper Responsibilities The OCB Initiator Wrapper is responsible for accepting the request from the VC Initiator, and controlling the OCB (as an OCB Initiator) to accomplish the transfer. In particular, the OCB Initiator Wrapper is responsible of making request to and accepting responses from the bus arbiter, initiating the transfer on the OCB (inserting any required OCB turn-around cycles), handling any OCB-level handshaking and getting Read data from the OCB. In most instances, the OCB Initiator Wrapper should not need to store any request information (particularly address or write data) on behalf of the VC Initiator, since the OCB Initiator Wrapper CMDACK (ACK) signal can be used to force the VC Initiator to hold the request information. It may need to store response information (such as RDATA) in the BVCI, if the VC Initiator expresses that it cannot accept the read data by not asserting the RSPACK.

However, electrical concerns will typically force the OCB Initiator Wrapper to buffer the request signals to drive long OCB wires, as well as dealing with OCB topology issues (tri-state vs. multiplexed buses, for instance). The OCB Initiator Wrapper is responsible for ensuring that the OCB timing is correct, and that VCI RDATA and handshaking signals make the required setup time to the VC Initiator.

The OCB Initiator Wrapper should be configurable enough to adapt to a range of possible VC Initiator capabilities. In particular, the OCB Initiator Wrapper should have variable address and data bus widths, and support for multiple transfer widths. This configurability allows the system integrator to match the OCB Initiator Wrapper to the VC Initiator.

Several issues arise with respect to the configuration of the OCB Initiator Wrapper. A VC Initiator with a 16-bit ADDRESS may need to connect to an OCB with a 32-bit address. In such a case, the system integrator should be free to synthesize the most significant 16 bits of the OCB address by whatever means are appropriate for the system. One way might be to statically configure the upper bits into the OCB Initiator Wrapper. Another method might involve placing a writable register somewhere on the OCB to hold the upper bits. The OCB Initiator Wrapper is also responsible for any required data shifting. Data shifting which can arise from endianness differences between the VC Initiator and the OCB, or width mismatches should not be required, in general. This requirement can generally be lifted by the appropriate connection of the VC byte lanes to the VCI byte lanes, if the endianness is of static nature.

5. 1.3 OCB Target Wrapper Responsibilities The OCB Target Wrapper is in complete control over the presentation of requests on its VCI; there is no arbitration. The OCB Target Wrapper acts as an OCB Target; it must convert the OCB transfer into a VCI- compliant transfer. In particular, it must translate OCB request information into the VCI CMDVAL (VAL) signal, which indicates the presence of a valid VCI request that is intendedfor the YC Target. Device selection mechanics are very specific to different OCBs. Traditional approaches to device selection include distributed address decoding and centralized address decoding. For a distributed-decoding OCB, the address decoder to determine VCI CMDVAL (VAL) will likely live inside the OCB Target Wrapper. For a centralized-decoding OCB, the VCI CMDVAL (VAL) signal is likely just a buffered version of the select signal from the centralized decoder.

The OCB Target Wrapper presents the request information across the VCI to the VC Target. It must hold the request information stable until it samples the VCI CMDACK (ACK) asserted. Since the OCB Target Wrapper is responsible for ensuring compliance with the OCB transfer protocol, most OCB Target Wrappers will use OCB Target handshaking to force the OCB Target Wrapper to hold the request information stable (i. e. insert wait states). Thus, data and address storage is rarely required in the OCB Target Wrapper. The OCB Target Wrapper may need to delay the assertion of CMDVAL so that it and the other request fields satisfy the VC Target setup time. It should wait until the VC Target returns CMDACK before releasing the OCB resources associated with the transfer. It is the OCB Target Wrapper's responsibility to ensure that VCI RDATA makes the timing path back across the OCB to the OCB Target Wrapper. Since the two-wire Peripheral VCI handshake does not allow the OCB Target Wrapper to force the VC Target to hold RDATA, the OCB must run slow enough to allow RDATA to make it back across the OCB or else data storage is required inside the OCB Initiator to acquire RDATA. The Basic VCI handshake allows for the OCB Target Wrapper to stall the VC Target. In any case, it is typically the OCB Target Wrapper's responsibility to buffer RDATA to drive the OCB data wires, thereby isolating the VC Target from the loading and topology (tri-state, multiplexed, etc.) of the OCB.

The OCB Target Wrapper should be configurable enough to match its VCI address and data bus widths, and transfer widths to the VC Target's implementation of the VCI. This configurability is key to allow the system integrator to design working systems using the VCI. When the OCB has a different data bus width than the VC Target, it is the OCB Target Wrapper's responsibility to accomplish any required data multiplexing. The VC Target ADDRESS is typically much narrower than the OCB ADDRESS; the VC Target should be configurable so that only the required ADDRESS bits are presented to the VC Target.

5.1.4 VC Target Responsibilities The VC Target is responsible for accepting the request from the OCB Target Wrapper and accomplishing the transfer. Since every request presented to the VC Target is intended for it, the VC Target should be designed to acknowledge every transfer. In simpler terms, the ACK response will often be a delayed version of the VAL. The VC Target should typically delay assertion of ACK until it has completed the transfer of the request; this forces the OCB Target Wrapper to hold the request information steady, thus eliminating the need for the VC Target to store the request.

The provider of the VC Target must provide a list of VCI configuration parameters for the VC, including such aspects as address/data bus widths, supported transfer widths, and timing data. These parameters allow the system integrator to configure the OCB Target Wrapper to meet the constraints of both the system and the VC Target.

5.1.5 VCI to VCI Conversions VCI components with different parameters, as size, are not supposed to be connected together directly. A special wrapper has to be used in this case (See Figure 32). The wrapper is a VC, which takes care of buffering, and other logic needed to map different VCIs together. This situation happens, when using VCI for point-to-point communication. When connecting different VCIs through an OCB, the OCB wrappers take care of size conversions. si us u ! p | g | r : : :. R : -g _I Figure 32. Interconnecting Different-Size VCI Components 5.2 VCI Parameters These parameters control: Generation ofthe VC itself for a soft VC.

Configuration signal/field tie-offs.

These parameters can also be used by EDA vendors to create tools for automating mixing & matching of VCs and Buses, and by IP providers to document the setup of the VC.

The default value of these parameters is 0 for all of the size/width type of parameters, and True for the binary type.

Independent of the implementation model abstraction level, language or format, these parameters must be documented. The implementation of the parameters in the models can be done with generics (e. g. in an HDL), setup or header files, etc. In case of a configurable hard VC, some of these parameters may be implemented with external pins that can be tied-off.'True'means high signal value, and'False'low signal value in the lists below.

5.2.1 Parameters Specific to PVCI INITIATOR-True if VCI Initiator ADDRSIZE-Address size, width of address bus in bits, range 0 to 31 CELLSIZE-Cell size, number of bytes in the data bus, value 1,2 or 4 FreeBE-True, if the VCI supports unrestricted combinations of byte enables. The restricted BE combinations, as defined in 3.4. 3 must be supported by all VCI implementations.

BIGENDIAN-True, if component is big endian, False if little endian.

NOENDIAN-True, if component does not care of endianness (e. g. a memory). Overrides the BIGENDIAN parameter.

DefACK-ACK is allowed to be asserted even when VAL is low (deasserted) RESETLEN-Number of clocks required of reset if NA or 0 use default (8 clocks) ERRLEN-Number of error extension bits (defined as E), default is 0 5.2.2 Parameters Specific to BVCI INITIATOR-True if VCI Initiator Initiator contains all signals and fields type MA and MI of table 5.

Target contains all signals and fields of type MA of table 5.

CHAINING-True if VCI is capable of packet chaining Chaining VCI contains all signals and fields of type MC of table 5.

CELLSIZE-Cell size, number of bytes in the data bus ADDRSIZE-Address size, width of address bus in bits CLENSIZE-CLEN size, width of CLEN field in bits BIGENDIAN-True for big endian, False for Little endian NOENDIAN-True for VC which doesn't care of endianness DefCMDACK-CMDACK is allowed to be asserted even when CMDVAL is low (deasserted) DefRSPACK-Initiator is always ready to acknowledge RSPVAL (initiator is not allowed to insert wait state).

RESETLEN-Number of clocks required of reset if NA or 0 use default (8 clocks) ERRLEN-Number of error extension bits (defined as E), default is 0 Default values for command extensions; for initiator the following parameters state that it will always send request of a certain behavior, as for target it only expects request of a certain behavior. The signal itself may or may not exist, but the behavior is known through these parameters, and the signals can be connected (tied off accordingly.

Dcfixed-signal cfixed is tied to High/Low Dconst-signal const is tied to High/Low Dcontig signal contig is tied to High/Low Dwrap-signal wrap is tied to High/Low 5.3 Implementation Guidelines Since the VCI is fully synchronous, and the wiring between the wrapper and a VCI component is supposedly very short, the VCI implementation should be very easy to design. A legal VCI component must sample all the signals at rising edge of the CLOCK. To create a legal VCI bus wrapper for an OCB that samples at the falling edge of the clock, buffering registers must be added.

The VCI standard should not pose any restrictions to making EDA tools that synthesize the bus wrapper automatically. This approach is preferred over manual wrapper design, since it reduces need for implementation verification, at least in theory.

In register transfer level implementation of the VCI, there are few restrictions: The flip-flops inferred must be rising-edge clocked and have active-low reset. The VCI standard does not pose any other electrical constraints to the physical implementation than those timing constraints given in signal definitions. The VCI component provider must document the physical implementation parameters and constraints, such as voltage swings. The guidelines given in VSIA Implementation/Verification DWG specifications and in On- Chip Bus DWG Attributes specification are to be followed. The manufacturing test constraints, or debug structures are not defined in the VCI standard. The guidelines given in VSIA Manufacturing Test DWG specifications are to be followed.

In a case of partly or fully combinatorial wrapper, the delay paths starting and ending at VCI component traverse all the way through the on-chip bus. It is the system integrator's responsibility to ensure the proper system timing in this case.

6. VCI Glossary of Terms VC Interface An OCB standard virtual component interface to communicate between a bus and/or virtual component, which is independent of any specific bus or VC protocol.

VCI Operation A VC operation is a transport object consisting of a pair of packets, which are transferred in different directions e. g. a single request-response packet pair.

Cell A cell is a grouping of one or more bytes. It contains a number of bytes that is characteristic to the natural width of the VCI implementation. It is the basic unit of information transferred across the VCI in one cycle.

Packet A packet is transport object consisting of an atomic ordered set of cells transferred across the VCI.

Packet Chain A packet chain is a non-atomic specialized transport object consisting of a set of logically connected packets transferred in the same direction across a VC Interface. The chain of packets is connected because no intervening packets are allowed on the same channel.

Signal Synonymous to electrical wire or net.

Transaction Generic term used for any pair of request and response transfer.

Transaction Layer This deals with point to point transfers between blocks or virtual components. It does not define signal names, or clock-cycle protocols.

Initiator A VC that sends request packets and receives response packets. It is the agent that initiates transactions e. g. DMA Target A VC that receives request packets and sends response packets. It is the agent that responds (with a positive acknowledgment by asserting) to a bus transaction initiated by a initiator-e. g. memory.

Bus Wrapper Logic between the VCI and a bus.

VC Wrapper Logic between an existing VC and the VCI.