MULTI-CHANNEL UNIVERSAL SERIAL BUS (USB) TO SUBRATE CHANNEL SYSTEMS AND METHODS
Multi-channel universal serial bus (USB) to subrate channel methods are disclosed. According to an aspect, a method includes providing a system comprising a USB interface and a multi-channel interface configured to communicatively connect to a plurality of subrate channels. The method also includes communicatively connecting the subrate channels with a computing device via the USB interface. Further, the method includes communicating, to the computing device, connection specifications for the subrate channels.
Latest IBM Patents:
This is a continuation application of copending U.S. patent application Ser. No. 14/021,550, filed Sep. 9, 2013 and titled MULTI-CHANNEL UNIVERSAL SERIAL BUS (USB) TO SUBRATE CHANNEL SYSTEMS AND METHODS, the content of which is hereby incorporated by reference in its entirety.
BACKGROUND1. Field of the Invention
The present invention relates to computing adapters, and more specifically, to multi-channel USB to subrate channel systems.
2. Description of Related Art
Several protocols have been developed to allow low-speed peripheral devices to connect to computing devices or systems. For example, the inter-integrated circuit (I2C) bus, the serial peripheral interface (SPI) bus, the 1-wire bus, the UNI/O bus, and similar protocols might be used for such purposes. Any such bus may be referred to herein as a serial peripheral bus. Also, the terms “bus” and “protocol” refer to a component for connecting low-speed peripheral device to a computing device or system. Such low-speed peripheral devices may include electrically erasable programmable read-only memory (EEPROM) devices, memory chips, digital-to-analog or analog-to-digital converters, monitors, speakers, display screens, clocks, and other devices. A system management bus (SMBus) is an enhanced implementation of I2C and uses a two-wire bus used for low-bandwidth communications among components of a system, especially power related chips such as a laptop's rechargeable battery subsystem, as well as other components such as temperature sensors and lid switches.
A universal serial bus (USB) cable can provide an interface between a host computing device and one or more peripheral devices, such as mobile phones, personal digital assistants, and removable media drives. Such peripheral devices may also be referred to as slave devices or downstream devices. The host computing device, which may also be referred to as a master device or an upstream device, is typically a computer system such as a personal computer.
It is desired to provide improved USB to I2C adapters.
BRIEF SUMMARYIn accordance with one or more embodiments of the present invention, multi-channel USB to subrate channel methods are provided.
In an aspect, a method includes providing a system comprising a USB interface and a multi-channel interface configured to communicatively connect to a plurality of subrate channels. The method also includes communicatively connecting the subrate channels with a computing device via the USB interface. Further, the method includes communicating, to the computing device, connection specifications for the subrate channels.
As described herein, there are various embodiments and aspects of the present invention. According to embodiments, the present invention is directed to multi-channel USB to subrate channel systems and associated methods.
Referring now to
The subsystem 100 may include a data interface generally designated 102 and functioning as part of a USB interface for communicatively connecting to a host computing device (not shown); a control interface generally designated 104 and functioning as part of a controller for connecting multiple subrate channels with the host computing device; and a status interface, generally designated 106. The data interface 102 may include an IN endpoint 108, an OUT endpoint 110, transmit buffers 112, and receive buffers 114. Each transmit buffer and each receive buffer may be associated with one subrate channel for buffering data to or data from the channel. The control interface 104 may include an IN endpoint 116, an OUT endpoint 118, and individual register files 120 for each subrate channel. The status interface 106 may include an interrupt IN endpoint 122 for reporting service requests from all channels during each interrupt. Further, the system 100 may include a USB transport layer interface 103 as part of the USB interface, and a control endpoint 105 as part of the controller. The USB transport layer interface 103 may be communicatively connected to a USB data link layer of the host computing device. The control endpoint 105 may be communicatively connected to the data interface 102, the control interface 104, and the status interface 106.
When the system 100 is connected to a host computing device, the computing device may request configuration information and device enumeration may begin. During device enumeration, a device connecting to the system 100 may return a descriptor as part of a descriptor configuration request. Enumeration, as referred to herein, may be a process of sending one or more commands and receiving data from the enumerated device to gather information about the device (e.g., device name, vendor identifier (VID), product identifier (PID), number of endpoints, required power, name of the company that manufactured the device, etc.). The descriptor configuration request is referred to herein as “GET_DESCRIPTOR_CONFIGURATION”. An example returned descriptor, which may be referred to herein as “MULTI_CHANNEL_SUBRATE_CONTROLLER” descriptor, is shown in Table 1 below.
The controller of the system 100 may provide this descriptor to the host computing device for providing connection specifications for the subrate channels. The connection specifications may indicate the number of subrate channels, a subrate type, transmit buffer information, receive buffer information, register information, subrate protocol information, and other information. The bProtocol field may indicate subrate protocol information.
The system 100 must use an INTERFACE_ASSOCIATION descriptor in accordance with USB specification 2.0 and associate interfaces 102, 104, and 106 such that the interfaces may be managed by the same device driver.
The control and data interfaces 104 are controlled by the control endpoint 105 to select one of the subrate channels for connection with the host computing device via the USB interface. Channel selection is implemented by use of a SET_DESCRIPTOR_CHANNEL_SELECT descriptor request to write the descriptor, an example of which is shown in Table 2 below. The descriptor must be written to endpoint 0 prior to any read or write of data or the control interface.
If a new CHANNEL_SELECT descriptor is not written prior to an attempted access to the data or the control interface, the device can return a protocol STALL. The control endpoint 105 may generate and communicate the CHANNEL_SELECT descriptor. bmDirection can indicate a direction of communication for the channel.
The system 100 may include multiple subrate engines 124 that are each associated with one of the subrate channels. The subrate engines 124 may be communicatively connected to register files 120 and buffers 112 and 114. To prevent buffer or control writes from affecting a subrate engine 124 while conducting a transaction, any attempt to write the CHANNEL_SELECT descriptor with a bmDirection set to OUT to a busy channel can produce a protocol STALL. This is illustrated in
Following the setup, the control transfer then proceeds to the data phase if required. The data phase includes an IN or OUT packet followed by one or more DATAx packets. In the SET_DESCRIPTOR transaction for the CHANNEL_SELECT descriptor this is an OUIT packet followed by a DATA1 packet containing the descriptor data. The multi-channel device processes this data instantly upon receipt and returns either a STALL if it rejects this setup, or an ACK packet if it accepts it. Following the data transfer phase, is the handshake phase of the control transfer. This is an instantaneous change of transfer direction, i.e. if there is no data phase or the data phase was an OUT transaction, the handshake begins with an IN packet. If the data phase was an IN transaction, the handshake phase begins with an OUT packet. The peripheral responds to an IN packet, or the host follows an OUT packet with a zero length DATAx packet. The other end then sends an ACK packet to complete the control transfer.
During high speed operation, USB specification 2.0 requires that the data and the control interface endpoints support the PING protocol to limit NAK responses. The PING protocol consists of a PING packet containing the peripheral address and endpoint number. If the peripheral can accept the maximum packet size on an OUT transaction, or can return the maximum packet size on an IN transaction, it will respond to the PING with an ACK packet. Since the multi-channel device may be non-blocking in nature, it can respond to the PING with an ACK packet provided that the CHANNEL_SELECT descriptor is valid. If the CHANNEL_SELECT descriptor is invalid, the device is not in a configured state, or the designated endpoint is halted, it will respond to the PING with a STALL packet. After a successful PING the host proceeds to perform the data transfer. To reduce logic, the maximum packet size in this case is limited to 64 bytes (the maximum packet size for Full Speed operation). Therefore, 4 separate data transactions are required to transfer 256 bytes.
In accordance with embodiments, the system 100 shown in
The subrate control engine operation is directed by the settings within the register files 120. The control interface, consisting of an IN endpoint 116 and an OUT endpoint 118 serves as the host portal to the register files. Service requests from the subrate control engines are sent to the status interface 122 to be aggregated with service requests from all other subrate control engines. The control endpoint 105 contains the data for enumeration, the channel select descriptor, and a multiplexer for the busy status from all the subrate control engines, used when the bmDirection in the CHANNEL_SELECT descriptor is set to OUT.
The USB transport 103 handles the USB transport protocol for all endpoints. It also performs such functions as CRC generation and checking, and PID substitution to maintain correct data toggle state. The USB transport also is responsible for address generation and maintaining data transfer counts.
In accordance with embodiments of the present invention, systems disclosed herein may be scalable up to 32 I2C channels or any other suitable number of channels from a single USB slave device and can conduct unsupervised transactions once set up for one or more busses or channels is complete. For example,
Referring to
It is noted that USB specification version 2.0 defines a 480 megabit per second (Mb/s) transfer rate high speed (H/S) device option. Although H/S devices are capable of supporting the 12 Mb/s full speed (F/S) mode, due to limited speed, operation of the F/S mode may not be suitable. Further, it is noted that design for testability (DFT) rules generally dictate that devices have some manner of initiating the device to a known state, and for placing all output pins into a high impedance (3 state (high impedance un-driven)) condition to facilitate in-circuit testing. A system in accordance with the present invention may have at least one control pin for each of these functions.
The FPGA 312 (or USB2I2CH32 device) may include sixty four, 256 byte buffers. Half of the buffers may be configured as transmit buffers, that hold the data to be sent out on the I2C channels (or busses), and the other half may be configured as receive buffers, that either hold data received on the I2C channels for transmission back to the USB host 302, or in modes such as auto-polling, to hold the data for comparison to the data received on the I2C channels. Each I2C channel may have an individual transmit buffer and an individual receive buffer.
Although the transmit buffers can be used, from the USB host perspective, as write-only memory during normal device operation, all buffers may been setup as read/write memory to facilitate system diagnostics.
Each I2C channel, which may also be referred to as a bus, may have an associated active-low reset line 314 that allows all slave devices on that particular bus to be reset. The I2C bus state machine may itself be reset at any time by a separate active high bit in the launch reset register.
Each I2C bus may have an associated active-low interrupt line 316 to allow slave devices to signal a request for service. This reset may be enabled or disabled by a bit in transaction control register 0. If the interrupt is enabled and asserted, the host can have to conduct a polling operation to determine which device requires service and to reset the interrupt.
The SMBus specification and I2C mode devices can, in some cases, support a maximum data transfer rate of 100 Kilobits per second (Kb/s). The I2C specification also allows high speed devices, which support data transfer rates up to 400 Kb/s. Data transfer rates are dictated by SCL transitions. In order to accommodate SMBUS devices and standard mode I2C devices while not limiting the data transfer rate for high speed devices, the base frequency of SCL may be selectable, on a per bus basis, to either 100 or 400 Kilohertz (Khz).
The I2C channels may have associated signal data lines (SDLs) 318 and signal control lines (SCLs) 320. Both SDA and SCL may be open drain signals. SCL may be controlled primarily by the master, with a slave device able to sink it to less than 0.4 volts when it needs to request more time. This operation is known as clock stretching. SDA may initially be controlled by the master, but control may be transferred to the slave during read operations. An alternate master may also drive SDA low during arbitration. If either of these signals remain at a low level for an extended period of time, it may indicate a bus short, either a soft short, where a slave device is hung, or a hard short, where the bus is electrically shorted to logic ground. The period of time before a short is declared is programmable on a per bus basis. This period is also programmable for SDA and SCL, so they can have different values on the same bus.
Each bus can be individually configured to operate as an I2C master or slave device. While the bus is in the slave configuration, some of the registers may go unused and others are used in a different manner.
Each I2C bus may feature its own state machine to control operation. This means that every bus may operate without regard to what occurs on any other bus. Multiple I2C busses may be operated simultaneously.
An example transaction type is a read only transaction. During read only access, the slave device may be addressed from the slave address register with bit 0 forced to a logical one. One or more bytes of data may then be read from the slave device, with each byte, except for the last, acknowledged with an ACK pulse, and the last byte acknowledged with a negative acknowledge (NAK) pulse. Each received data byte is recorded in the receive buffer in sequential order, starting at location 0 during unary transactions, or after the last byte received during the first transaction during the second phase of compound transactions. If an error occurs during any phase of a read-only transaction, the transaction and any subsequent transaction may be terminated.
Another example transaction type is a compare only transaction. During compare only access, the slave device may be addressed from the slave address register with bit 0 forced to a logical one. One or more bytes of data can then read from the slave device, with each byte, except for the last, acknowledged with an ACK pulse, and the last byte acknowledged with a NAK pulse. Each received data byte can be compared with a byte from the receive buffer in sequential order, starting at location 0 during unary transactions, or after the last byte received during the first transaction during the second phase of compound transactions. During signal on mismatch modes, if the receive byte and the corresponding byte from the receive buffer do not match, the received byte can replace the corresponding byte in the receive buffer. The process can continue until all bytes specified for the transaction have been read and compared. All subsequent transaction may then be completed and a done flag may be then set. On signal on match modes, a mismatch is not recorded; however, a NAK pulse may be generated to the slave device to terminate the read, even if all specified for the transaction have not been read. If all bytes for the transaction match, all subsequent transactions are completed, and the done flag may be set. If an error occurs during any phase of a compare-only transaction, the transaction and any subsequent transaction is terminated.
During write only access, the slave device may be addressed from the slave address register with bit 0 forced to a logical zero. One or more bytes of data may then read from the transmit buffer in sequential order and written to the slave device. After the last byte is written, the host then sends a stop pulse. If at any point during the transaction the slave device does not send an ACK, the transaction and all subsequent transactions may be terminated and the error reported.
In read/write mode, the read transaction may be performed as described herein except that a stop pulse is not sent at the conclusion of the read. Instead, a restart is issued and a write transaction, similar to or the same as described herein is immediately performed.
During a compare/write transaction, a compare transaction, as described herein, may be performed. If the comparison is successful, a restart pulse, rather than a stop pulse may be issued, and a write transaction may be performed.
During a write/read transaction, a write transaction, as described herein, may performed, with the exception that a restart, rather than a stop pulse may be issued at the conclusion of the write, and a read transaction, as described herein, may then be conducted.
During write/compare transactions, a write transaction as described herein may be performed; however, at the conclusion of the write transaction, a restart, rather than a stop pulse may be issued, and then a compare operation as described herein may be conducted.
An auto-compare mode may be implemented to allow the host processor to be signaled with a done event only if the compare is successful, or a transaction fault occurs. Compare may be set for signal on match, or signal on mismatch and as described herein. Autocompare may be combined with auto-polling to conduct an unsupervised watchdog task.
Automatic polling may allow a set of I2C transaction to be repeatedly conducted at predetermined intervals for allowing devices to be monitored without direct intervention from the host processor. A polling interval may be set at any suitable interval, such as between 100 milliseconds and 6553.6 seconds in 100 millisecond increments. At the conclusion of each polling operation, the transmit and receive buffer addresses may be automatically reset to zero.
Transaction looping may allow a transaction to be repeatedly executed a number of times. The number of iterations may be programmable from 1 to 256, or any other suitable numbers. The transmit and receive buffer pointers may start at the address following the previous repetition, allowing different data to be read/written on each loop. The conclusion of the last iteration, the transmit and receive buffer addresses may be reset to zero. Transaction looping can be used to poll an entire subsystem with a single setup.
A compound transaction may be a complex transaction where more than one I2C base address is used. Compound transaction may be necessary for devices located behind an I2C multiplexer, or for devices on multi-host I2C busses. The FPGA 312 may support compound transaction using up to two I2C base addresses.
Each bus, when used in the master mode, can be setup to retry failed I2C transactions from one to three times, or any other suitable number of times. Automatic retry, as well as the number of retry attempts, may be programmable on a per bus basis. The interval between retry attempts may be programmable from 0 to 350 milliseconds in 50 millisecond increments or any other suitable configuration.
Although a ULPI interface is not a requirement for USB operation, most FPGAs do not function at a high enough speed to handle USB directly. The ULPI interface provides a parallel data interface to an external PHY at one eight of the serial data rate. Referring now to
The ULPI block then waits 614 for the USB host to respond by sending a single-ended zero (SE0), as represented by the receipt of a RCV command from the PHY with VBUS valid 616 and both LINESTATE 0 and LINESTATE 1 at a logical zero. It must validate the SE0 condition for a minimum of 2.5 microseconds.
Once SE0 has been validated, the ULPI block sends register write commands to the PHY to set the transceiver select to H/S and the mode to chirp. It then sends a TX command (NOPID) to begin the chirp 618. It lets the chirp persist for 1 millisecond, and then sends another TX command (NOPID) to resume normal H/S signaling.
When the USB host detects the chirp 622 it responds by sending a series of chirps that must be at least 40 microseconds, and no more than 60 microseconds long. The ULPI must detect a minimum chirp of chirp K-J-K-J-K-J. Each individual K and J must be detected for a minimum of 2.5 microseconds. Once the minimum sequence is detected, the ULPI block sends register write commands to the PHY to change mode to H/S 632 and then waits to detect squelch from the host, in order to know when it has completed chirp. It then sets FS (a USB full speed device) to zero and svalid to 1.
If the ULPI block does not detect the host chirps in 100 microseconds, it sends register write commands to the PHY to set transceiver select to F/S 626 and activate the pullup resistors. It then sets both fs 628 and svalid to 1.
During normal operation the ULPI block monitors the PHY for RCV commands 630. It monitors LINESTATE and VBUS valid 634, and generates a reset to all other downstream devices in the event of a disconnect or SE0 condition. When it detects USB packets 636, it activates ie_n to forward them to the USB transport block. On USB read transactions 638, as indicated by read from the USB transport block asserted high, it waits for dir to go low. It then pauses for one clock cycle for bus turn around, and generates a TX command to send the USB data packet back 640. Finally, it de-asserts oe_n on the next clock. When done becomes asserted, the ULPI block will generate stp for one clock cycle to indicate data end.
The ULPI block throttles USB data into and out of the USB transport block and the endpoints by use of de_n. When de_n is high, current data is held on the next rising edge of clk. When de_n is low, the data can transition to next data on the next rising edge of clk.
The ULPI block also examines the state of VBUS valid and LINESTATE during every receive command. If it detects VBUS invalid or SE0, it will immediately de-assert svalid and return to the initialization routine.
The USB transport block may implement a state machine and other hardware necessary to receive USB packets, perform error checking, activate endpoints, and control the flow of data between the endpoints and the ULPI interface block. It may include crc generator/checkers to check endpoint address fields in tokens and write data and to provide a check for read data. Further, it may include decode hardware to identify the various USB packet types and react accordingly. It may maintain data toggle synchronization via a PIDsubstitution mechanism. The USB transport block requires svalid from the ULPI interface block be active before it can respond to USB packets.
The USB transport block may be responsible for management of the USB transport layer protocol, creation of all handshake packets, and the addition of the crc to all data packets for the bulk and interrupt endpoints. It may activate the appropriate IN or OUT endpoints based on the token, monitors handshake packets from the host and maintains the data transfer counts, address pointers, and data toggle synchronization. It also buffers all SETUP data packets and processes all standard device requests.
Referring now to
Static data for ENDPOINT 0 410 may be maintained in a ROM. Dynamic data is stored in a set of registers. A set of multiplexers, controlled by the current address, selects between the two during the GET_DESCRIPTOR and SET_DESCRIPTOR commands.
ENDPOINT ½ 412 may be 2 bulk data endpoints, one IN, and one OUT, for transferring data into and out of the transmit and receive buffers. It may rely on a value from a vendor specific descriptor in ENDPOINT 0 410 to select the appropriate buffer, either via its write enable, or via the output enable to the data multiplexer (mux). The buffer addresses are maintained by the address pointer in the USB transport layer.
Write access to any buffer in ENDPOINT ½ 412 blocked if the corresponding channel in ENDPOINT ¾ 414 is in a busy state. Any write access attempted to those buffers during this period can result in a STALL response.
The data multiplexer block 416 selects buffer data to be read by the USB interface. It can be a 512×8 bit multiplexer, employing enhanced multiplexer functions that feature dual select inputs, to allow data selection in just 4 logic levels with a minimum number of logic blocks. Since most modern FPGA devices are based upon 4 input logic cells, using enhanced multiplexer logic on the first level allows selection between one of two data inputs or nothing, based on the select inputs.
Each byte from one of two sources requires 8 such cells, grouped into blocks. Each set of four enhanced multiplexer blocks feed one of 16 logical OR blocks on the next level. Each set of four logical OR blocks then serve as inputs to one of four logical OR blocks on the third level, which in turn serve as inputs to a logical OR block on the final level.
The transmit buffers 408 can be 32 256 byte dual port RAMS that connect between the USB 420 and the I2C state machines 406. The I2C access port (port 2) may be read-only, and the USB port is read/write. In order to implement in typical FPGA architectures, which have 4096 bit RAM blocks, 2 transmit buffers can be placed in each block. This requires that a multiplexer be used on port two, to allow access by either of two I2C state machines. The multiplexer can shift port 2 address on each clock cycle, alternating access between state machines. The T flip-flop7 used to toggle between the two addresses also generates the ninth address bit for port 2.
The transmit port also has special requirements. The write enables from each even odd pair have to be combined, and a ninth address bit generated. The write enable for the odd buffer is combined with the output enable for the odd buffer to generate this bit.
The receive buffers 409 are used to hold the data received from the I2C links, or to hold comparison data when the associated I2C link is performing auto-polling. They are almost identical to transmit buffers, with the exception that port 2 is a read/write port also, requiring an additional multiplexer for the I2C write enables.
Endpoint ¾ 414 may include a pair of bulk data endpoints, one IN and one OUT. The entire register file for a particular channel may be read from or written to as a single group. The register file for a channel may only be written when that channel is idle. Any attempt to write to the register file while the channel is busy will return a STALL response.
The system 400 may include an address sequencer 422 that receives the address from the USB transport layer 420 and translates it into 32 individual register enables. The system 400 includes I2C registers 424 that may be a set of 32 register files to control the operation and report the status of the I2C state machines. Each register file is structured in big endian format. The launch and reset register may be a write only register that sets the particular interface to its default conditions when a one is written to bit 0 or launches the defined I2C transaction when a one is written to bit 2. It may not be masked out. Write access is always permitted.
The mask register may be used to prevent write access to registers. Upon initialization, all registers in the file, except the status register, test register, and the launch and reset register, have read/write access. When the corresponding bit in the mask register is set, write access to that register byte is blocked. The mask register may not be masked out. Write access is always permitted.
The configuration register may be used to enable the I2C host state machine, set the clock speed, choose between master or slave operation, setup auto-polling, enable or disable the I2C interrupt, control the I2C peripheral reset, and to manually adjust the states of SDA and SCL for testing. It also contains an SCL gate which is used in conjunction with manual control of SDA to initialize all devices on that particular I2C bus by ensuring that any in progress transactions have been completed. SDA is manually set high and SCL gate is set to free run briefly. This ensures that all peripheral transactions have been completed, and the bus is idle.
The transaction control register is used only in the master mode to setup and start the current I2C transaction and define auto-retry. The least significant byte (LSB) is used for the first, or only transaction, and to define the auto-retry interval in 50 millisecond increments. The most significant byte (MSB) is used for compound transactions to define and enable the second transaction; and to setup the number of auto-retry attempts.
The loop iteration register may set the number of times (minus 1) to repeat the defined transactions. It may only be used in the master mode.
The slave address register may include the I2C peripheral device address in bits 7-1 of the LSB. Bit zero is unused and should be set to zero. The second byte of the slave address register is used during compound transactions to hold the base address of the second peripheral device, and contains the I2C peripheral device address in bits 7-1. Bit zero is unused and should be set to zero. When used in the slave mode the slave address register defines the I2C addresses that it can be recognized.
The transmit size register, used only in the master mode, may contain the number of bytes to transmit during the first, or only, transmit transaction in the LSB. The MSB of the transmit size register is used during compound transaction and holds the number of bytes to transmit in the second transaction. The total of the two transmit size bytes cannot exceed 256.
The receive size register, used only in the master mode, contains the number of bytes to receive during the first, or only, receive or compare transaction in the LSB. The MSB of the receive size register is used during compound transactions and holds the number of bytes to receive during the second receive or compare transaction. The total of the two receive size bytes may not exceed 256.
The short time limit register contains the time, in tens of milliseconds, for the SCL and SDA short detector to operate.
The maximum stretch register contains the maximum time that SCL has been held low since this register was last reset or re-written by the USB host. It allows fine tuning of the Short Time Limit Register.
The polling interval register sets the interval, in hundreds of milliseconds, for autopolling.
The sent count register may contain the number of bytes sent by the I2C host state machine during the current transaction. The LSB is used by the first, or only, transmit transaction. The MSB is used for compound transactions and contains the number of bytes sent for the second transmit transaction.
The receive count register contains the number of bytes received by the I2C host state machine during the current transaction. The LSB contains the number of bytes received during the first, or only, receive transaction. The MSB is used during compound transactions and contains the number of bytes received during the second receive transaction. The short timer contains the current elapsed time, in tens of milliseconds, that SCL has been held low. The short timer contains the current elapsed time, in tens of milliseconds, that SDA has been held low.
The status register may be a read only register that contains the current status of the associated I2C host state machine.
The I2C_BSY_N bit may get set when the transaction is stopped for any reason, whether for completion, error, or in compare operations when the compare is unsuccessful. The success bit becomes set when the entire transaction is successfully completed. For compare transactions, this includes the compare criteria for signaling to be met. During transaction looping, the status register contains the status from the final transaction executed. The success bit may not be set until the loop iteration register and the iteration count register match. The abort bit is set by a reset to an executing bus. Since some transactions may have both a write phase, and a read or compare phase, as many as four transactions have to be recorded. Address or data negative acknowledge (NAK) is recorded in a separate bit for each phase. The done bit for each phase only gets set if that phase has been successfully completed. SDA and SCL shorts are separately recorded, as is the state of the I2C interrupt. If a transaction fails, the failing phase can easily be detected by examining the NAK and done bits for each phase.
The iteration count register may be used only during transaction looping and contains the current iteration number minus 1.
The test register does not affect operation or report status of the I2C interface in any way. It is used by the USB for endpoint operational verification only.
The register memory map for endpoint 2 is setup to prevent unaligned accesses to any register and to write to the Launch and Reset register last so that launch delay circuitry is unnecessary.
The I2C state machines 406 may implement the I2C functions programmed into the I2C registers. They read data from the transmit buffers during send transaction, and either write data to the receive buffers, for standard transaction, or compare the current received data with the data in the receive buffer during auto-polling. They also implement compound transactions. Compound transactions are usually used to access a peripheral device behind an I2C multiplexer, or to access a shared I2C bus. Compound transactions require two different peripheral base addresses. Compound transactions are supported as long as the total transmit size to both peripherals does not exceed 256 bytes, and the total read or compare size from both peripherals does not exceed 256 bytes.
Endpoint 5 426 shown in
Table 4 below illustrates example FPGA input/output (I/O) pin descriptions. For example, the I/O pins may be for FPGA 312 shown in
The term “Dir” refers to Pin direction from the intellectual property perspective. I refers to Input. O refers to Output. I/O refers to bi-directional. Regarding “Type,” LVTTL−Vccio=3.3V nominal (Sources current from Vccio on high, sinks current to ground on low.) “OC” represents open collector (drain) (Sinks current to ground on low; high impedance un-driven on high.). “H” is active high, and “L” is active low.
Regarding pin descriptions, there are global control pins (2 pins). “gts_n” represents global 3 state control, is active low, and when active forces all output and bi-directional pins to high impedance un-driven state. “rst_gsr_n” represents global set/reset, is active low, and forces all blocks and I/O to power up conditions.
Regarding ULPI interface pins (12 pins), “clk” represents a 60 MHz clock provided by PHY, and may be the master timing source. “dir” represents direction and determines ownership of data bus. When “dir” is high, the PHY drives the data bus. When “dir” is low, the data bus is driven in accordance with the present subject matter.
“nxt” is a pin driven by the PHY to throttle data and to ensure common ambiguity during data bus turn around cycles. It may be sampled on the falling edge of clk. When “nxt” is driven low, the device driving the data bus holds the bus in its previous state. When “nxt” is driven high, the data bus driving device may transition to the next data state on the rising edge of clk. “nxt” is driven low for one clock cycle during bus turn around cycles to ensure that both the PHY and the IP data bus drivers are in a high impedance, un-driven state. This can guarantee common ambiguity during turn around cycles.
ULPI interface pins (12 pins) may include a “clk” (clock). Further, these pins may include a “dir” (direction) pin that determines when “dir” is high. The “stp_pad” pin may be driven to abort data driven by the PHY and obtain control of the data bus, or to signal end of data. The “data_pad” pins may be an 8 pin bi-directional data bus between the PHY and the IP. In the “data_pad” pins, data[0] is the least significant bit, and data[7] is the most significant bit.
The “I2C” resets (32 pins) are represented by “rst_i2c_n_pad” and may be active low, and have open drain outputs individually controlled by the I2C register set associated with that particular I2C bus. They may be used to globally reset all peripheral devices connected to that I2C bus.
The I2C busses (96 pins) may include “scl_pad,” “sda_pad,” and “i2c_int_n” pins. The “scl_pad” pins may include 32 open drain input/outputs individually controlled by the I2C state machine associated with a particular I2C bus. The “scl_pad” pins may be used to control the timing of to that I2C bus. “scl_pad” is normally driven low by the I2C state machine, but may be held in a low state by a peripheral device to throttle data, a condition referred to as clock stretching.
The “sda_pad” pins may include 32 open drain, bi-directional pins, each associated with a particular I2C bus. “sda_pad” may be used to control the I2C state and to implement a serial data link.
The “i2c_int_n” pins may include 32 active low inputs, each associated with a particular I2C bus, used by peripheral devices to request service. “i2c_int_n” is normally implemented as an open drain bus to multiple devices.
The USB connect control (1 pin) may be represented by “i2c_int_n” and include one active high pin to control the quick switch.
Regarding power on conditions, “stp_pad” may be driven high. “data_pad,” “rst_i2c_n_pad,” “scl_pad,” and “sda_pad” may have high impedance. “cnct” may be driven low.
Regarding interface requirements, the FPGA hardware and software interfaces may combine to form the first six layers of the seven layer the Open Systems Interconnect (OSI) model.
The USB physical layer may handled by the PHY as may be understood by those of skill in the art. In order to manage connection to the USB physical layer, a “quick switch,” an electrically controlled analog switch, may be added between the PHY and the USB physical connection, allowing the intellectual property to control connection to the USB. This quick switch may only operate on VBUS, so does not affect the longitudinal balance, terminating impedance, or signal quality of D+ and D−.
The ULPI interface may include 11 LVTTL signals: a 60 MHz clock signal driven by the PHY; 2 control signals, DIR and NXT, driven by the PHY; 1 control signal, STP, driven by the USB2I2CH32; and an eight-bit bidirectional data bus. DIR may control ownership of the bidirectional data bus. When DIR is high, data is driven by the PHY to the USB2I2CH32. When DIR is low, the USB2I2CH32 can drive data to the PHY. DIR will only transition on a rising edge of CLK. In order to guarantee minimum common ambiguity, neither the PHY or the USB2I2CH32 can drive the data bus during the first clock cycle after a DIR transition. This is known as a turn around cycle.
When DIR is low NXT is used by the PHY to throttle data transfers. When DIR and NXT are at a low level at the rising edge of a clock, the previous data is held constant on the data bus. When DIR is low and NXT is high at the rising edge of the clock, data will transition to the next data byte.
STP is used during data transfers when DIR is low by the USB2I2CH32 to indicate the end of data. When all data has been sent, the USB2I2CH32 drives STP high for one clock cycle.
When DIR is high, NXT is used to differentiate between USB traffic and RECEIVE commands. When NXT is low, it indicates a RECEIVE command. When NXT is high it indicates USB traffic. RECEIVE commands may be issued at any time DIR is high. The PHY may issue as many consecutive RECEIVE commands as it requires. This is done during USB transfers when the PHY is waiting for more data.
During periods when the PHY has no USB traffic to send and no line transitions to report with RECEIVE commands, it can hold DIR low. If the USB2I2CH32 has no traffic to send back during this period it can hold data and STP low. If the PHY then wants to begin USB traffic, it can assert NXT high in the same cycle as it drives DIR high to signal the beginning of USB traffic.
STP can also be used to abort a data transfer from the PHY to the USB2I2CH32. If STP is asserted for one clock cycle while DIR is high, the PHY can immediately stop the data transfer and drive DIR low. The PHY cannot drive DIR back high until the USB2I2CH32 drives STP high for one clock cycle again. The USB2I2CH32 only uses this function during reset, in order to send register write commands to disconnect the PHY from the USB bus (soft disconnect).
The PHY may send receive commands to the USB2I2CH32 in order to report VBUS, line state, and status information and to flag the beginning and end of USB traffic to the USB2I2CH32. The receive command consist of a single byte, sent when DIR is high and NXT is low, except when this condition occurs during a turn-around cycle.
The byte may be encoded as shown in Table 5 below.
Transmit commands can be used by the USB2I2CH32 to send idle code, read and write registers in the PHY, control chirp, initiate USB transfers, and to report errors. Transmit commands consist of a 2-bit command code and a 6-bit payload as shown in Table 6 below.
When performing a RegWrite command, some registers can support a set and clear operation at separate addresses. A set operation performs a logical or of the write date and the register contents. A clear operation performs a logical and of the write data and the register contents. The addresses used in the RegRead and the RegWQrite commands are as shown in Table 7 below.
The USB2I2CH32 does not use extended register reads or writes.
All USB packets may begin with a packet identifier (PID) field which indicates the type or direction of the data transfer and the format of the rest of the packet. The PID consists of a four bit identifier and a four bit check field. The check field is the ones complement of the identifier.
Token packets, except for SOF, may have a seven bit address and a four bit endpoint number field immediately following the PID. The SOF token uses these eleven bits to specify the frame number. Following these eleven bits is a five bit cyclic redundancy check (CRC) field. The CRC is the ones complement of the remainder after division of 11 bit address/endpoint (or frame number) field, least significant bit first, by the generating polynomial x5+x2+1. When the packet is checked, the 11 bits of the address/endpoint field may first run through the checker least significant bit (LSb) to most significant bit (MSb) and the the CRC is sent through MSb to LSb. The remainder can be x3+x2 in the absence of errors.
Data packets may consist of a PID, an integral number of data bytes that is less than or equal to the maximum allowed transfer size for the peripheral speed18, and a sixteen bit CRC that is the one's complement of the remainder after division of the data bytes by the generating polynomial x16+x15+x2+1. Upon reception the data and the CRC are again divided by the generating polynomial. In the absence of error the remainder will be x15+x3+x2+1 (800BH).
In addition to the CRC, bulk transfers are also protected by a data toggling mechanism whereby consecutive reads or writes to a particular endpoint in the same frame (without an intervening configuration command) will alternate between DATA0 and DATA1 PID's. The first data packet after an SOF or a SETUP token will be initialized to DATA0. The data PID will not toggle when a NAK or a corrupted ACK token is received.
Handshake packets may consist of only a PID. Handshake packets are used to report the status of a data transaction and can return values indicating successful reception of data, command acceptance or rejection, flow control, and halt conditions. Only transaction types that support flow control can return handshakes. Handshakes are always returned in the handshake phase of a transaction and may be returned, instead of data, in the data phase.
The only special packet that the USB2I2CH32 supports is the PING packet. PING protocol is required by the USB specification for endpoints 0, 1, 2, 3, and 4 when operating is high speed mode.
Control transfers minimally have two transaction stages: Setup and Status. A control transfer may optionally contain a Data stage between the Setup and Status stages. During the Setup stage, a SETUP transaction is used to transmit information to the control endpoint of a function. SETUP transactions are similar in format to an OUT but use a SETUP rather than an OUT PID. A SETUP always uses a DATA0 PID for the data field of the SETUP transaction. The function receiving a SETUP must accept the SETUP data and respond with ACK; if the data is corrupted, discard the data and return no handshake. In additional, the device receiving a SETUP packet must set its data toggle synchronization to one.
The Data stage, if present, of a control transfer consists of one or more IN or OUT transactions and follows the same protocol rules as bulk transfers. All the transactions in the Data stage must be in the same direction (i.e., all IN or all OUT). The amount of data to be sent during the data stage and its direction are specified during the Setup stage. If the amount of data exceeds the pre-negotiated data packet size, the data is sent in multiple transactions (IN or OUT) that carry the maximum packet size. Any remaining data is sent as a residual in the last transaction.
The status stage of a control transfer is the last transaction in the sequence. The status stage transactions follow the same protocol sequence as bulk transactions. Status stage for devices operating at high-speed also includes the PING protocol. A status stage is delineated by a change in direction of data flow from the previous stage and always uses a DATA1 PID. If, for example, the Data stage consists of OUT's, the status is a single IN transaction. If the control sequence has no Data stage, then it consists of a Setup stage followed by a Status stage consisting of an IN transaction. The DATA1 packet during the status stage is always a zero length packet.
The SETUP packet is a specially formatted, eight byte DATA0 packet that the host sends immediately following the SETUP token. It is used to convey the request type and the direction of control transfer. It is formatted as shown in Table 9 below.
The bmRequestType field identifies the characteristics of the specific request. In particular, this field identifies the direction of data transfer in the second phase of the control transfer. The state of the Direction bit is ignored if the wLength field is zero, signifying there is no Data stage. If the device receiving the SETUP packet does not support the requested transaction, or the endpoint to which the SETUP packet was directed is halted, the device can return a STALL packet on the first transaction of the data or status stage.
The USB specification defines a series of standard requests that all devices must support. In addition, a device class may define additional requests. A device vendor may also define requests supported by the device.
Requests may be directed to the device, an interface on the device, or a specific endpoint on a device. This field also specifies the intended recipient of the request. When an interface or endpoint is specified, the wIndex field identifies the interface or endpoint.
The bmRequest field specifies the particular request. The Type bits in the bmRequestType field modify the meaning of this field.
The contents of the wValue field vary according to the request. It is used to pass a parameter to the device, specific to the request.
The wIndex field can used in requests to specify an endpoint or an interface.
The wLength field defines the length of the data transferred during the second phase of the control transfer. The direction of data transfer (host-to-device/device-to-host) is indicated by the Direction bit of the bmRequestType field. If this field is zero, there is no data transfer phase. On an input request, a device must never return more data than is indicated by the wLength value; it may return less. On an output request, wLength will always indicate the exact amount of data to be sent by the host. Device behavior is undefined if the host should send more data than is specified in wLength.
In USB device framework, the device reports its identity and its capabilities to the host by means of a set of descriptors. Descriptors fall into one of three categories; standard, class specific, and vendor specific. The USB2I2CH32 device does not use any class specific descriptors.
Standard descriptors are used by all USB devices to report the basic identity and capabilities of the device. The first of these descriptors is the DEVICE type. It is formatted as shown in Table 10 below.
If this is a high speed capable device, a DEVICE_QUALIFIER descriptor will follow the DEVICE descriptor. The DEVICE_QUALIFIER defines how this device would operate if it were operating at the other speed. For example, if the device is currently operating at full-speed, the device_qualifier returns information about how it would operate at high-speed and vice-versa. The DEVICE_QUALIFIER descriptor is formatted as shown in Table 11 below.
The next standard descriptor is the CONFIGURATION descriptor. When the CONFIGURATION descriptor is requested, the device will return the CONFIGRATION descriptor and all INTERFACE_ASSOCIATION, INTERFACE, ENDPOINT, and class specific descriptors. It may optionally return vendor specific descriptors as well. The configuration descriptor is formatted as shown in Table 12 below.
High speed capable devices must also define a set of descriptors describing how the device would perform if it were operating at the other speed. The OTHER_SPEED_CONFIGURATION descriptor is used for this purpose. It is identical in operation and format to the CONFIGURATION descriptor except that the descriptor type is changed to OTHER_SPEED_COFIGURATION.
Most USB devices associate a single interface with a particular device function. There are some devices, however, that require multiple interfaces for a single function. In this scenario, the device will use an INTERFACE_ASSOCIATION descriptor immediately preceding the INTERFACE_DESCRIPTORS that are associated with each other. Multiple INTERFACE_ASSOCIATION descriptors are allowed. The INTERFACE_ASSOCIATION descriptor is formatted as shown in Table 13 below.
The INTERFACE descriptor describes a specific interface within a configuration. A configuration provides one or more interfaces, each with zero or more endpoint descriptors describing a unique set of endpoints within the configuration. When a configuration supports more than one interface, the endpoint descriptors for a particular interface follow the INTERFACE descriptor in the data returned by the GetConfiguration( ) request.
An interface may include alternate settings that allow the endpoints and/or their characteristics to be varied after the device has been configured. The default setting for an interface is always alternate setting zero.
The SetInterface( ) request is used to select an alternate setting or to return to the default setting. The GetInterface( ) request returns the selected alternate setting. Alternate settings allow a portion of the device configuration to be varied while other interfaces remain in operation. If a configuration has alternate settings for one or more of its interfaces, a separate INTERFACE descriptor and its associated endpoints are included for each setting.
If an interface uses only endpoint zero, no ENDPOINT descriptors follow the interface descriptor. In this case, the bNumEndpoints field must be set to zero. An INTERFACE descriptor never includes endpoint zero in the number of endpoints. The INTERFACE descriptor may be formatted as shown in Table 14 below.
ENDPOINT descriptors for each interface follow the INTERFACE descriptor for that interface The ENDPOINT descriptors are formatted as shown in Table 15 below.
STRING descriptors are not returned for the GetDescriptor commands for CONFIGURATION or OTHER_SPEED_CONFGURATION. They must be accessed with separate GetDesciptor commands foe STRING type, specifying the index. STRING descriptors are optional. If a device does not support string descriptors, all references to string descriptors within device, configuration, and interface descriptors must be reset to zero.
STRING descriptors may use UNICODE encodings as defined by The Unicode Standard, Worldwide Character Encoding, Version 3.0, The Unicode Consortium, Addison-Wesley Publishing Company, Reading, Mass. The strings in a USB device may support multiple languages. When requesting a STRING descriptor, the requester specifies the desired language using a sixteen bit language ID (LANGID) defined by the USB-IF. The list of currently defined USB LANGIDs can be found at http://www.usb.org/developers/docs.html. String index zero for all languages returns a STRING descriptor that contains an array of two-byte LANGID codes supported by the device. A USB device may omit all string descriptors. USB devices that omit all string descriptors must not return an array of LANGID codes.
The array of LANGID codes is not NULL-terminated. The size of the array (in bytes) is computed by subtracting two from the value of the first byte of the descriptor. UNICODE encoded strings are not NULL terminated either. STRING descriptors can be formatted as shown in Table 16 below.
The USB2I2CH32 may use two vendor specific descriptors. The first descriptor, known as the MULTI_CHANNEL_SUBRATE_CONTROLLER (MCSC) descriptor, informs the driver of the device architecture and the proper INYERFACE descriptor indices to use for each device activity. It is returned during the GetDescriptor command for CONFIGURATION. The second descriptor is the CHANNEL_SELECT descriptor. It is a dynamic descriptor and is only accessed by GetDescriptor and SetDescriptor commands for type CHANNEL_SELECT at index zero. The MULTI_CHANNEL_SUBRATE_CONTROLLER descriptor may be formatted as shown in Table 1 above. The CHANNEL_SELECT descriptor may be formatted as shown in Table 2 above.
Enumeration is the process where the USB host controller identifies a newly attached device, assigns it an address and a driver, configures it and readies it for operation. Enumeration may begin when a device is first attached.
During enumeration, the host may reset the device. Reset signaling allows the host to determine the connection speed of the device. The host can then issue a GetDescriptor command for DEVICE_TYPE and reads the first 8 bytes of the DEVICE descriptor. This allows it to determine the maximum packet size for ENDPOINT. It then resets the device again.
After the second reset the host sends a SET_ADDRESS command to the device. The new address does not take effect until after the successful completion of the status stage of the command. Subsequently, the host issues a GetDesciptor, DEVICE type command. This time it requests the full descriptor.
If the device is attached in F/S or H/S mode, the host then issues a GetDescriptor, DEVICE_QUALIFIER type to determine whether or not the device is capable of operating at another speed.
Subsequently, the host can read the device configurations specified in the NumConfigurations byte of the DEVICE descriptor. For the USB2I2CH32 device there is only one configuration. Then for each configuration, the host can first issues a GetDescriptor, CONFIGURATION type to read the 9 bytes of the descriptor to determine total size of the configuration, and then issue a GetDescriptor, CONFIGURATION type for the full configuration and all subsequent (INTERFACE_ASSOCIATION, INTERFACE, ENDPOINT, class, and/or vendor) descriptors. It then reads the descriptors using wTotalLength/CEMAXSIZE packets at CEMAXSIZE and one short packet21 until the total configuration is read.
Once all configurations are read, if the device supports more than one speed, it will issue one or more GetDescriptor, OTHER_SPEED_CONFIGURATION commands to determine how the device would operate at the other speed. Finally, the host will issue zero or more GetDescriptor, STRING type commands to read any string data available for the device. It then uses the class and subclass data available in the descriptors to load any class drivers necessary to operate the device. If there is no class specific data applicable to the devices, the host will use the vendor identification (VID) and product identification (PID) fields from the DEVICE descriptor in order to determine which driver to load.
When the driver is loaded, it will reread all CONFIGURATION and STRING descriptors, determine a configuration, read the device status, and finally issue a SetConfiguration command to the device. The device is now ready to use.
The USB2I2CH32 uses the SetDescriptor, CHANNEL_SELECT index 0 to manage its protocol for endpoints 1, 2, 3, and 4. When the SetDescriptor command completes successfully, the address counter is cleared to zero and the transfer size counter is set to the size specified in wLength. A SetDescriptor CHANNEL_SELECT index 0 command must precede any transfer to endpoints 1, 2, 3, and 4. You will get a STALL response if you attempt an IN or OUT transaction to endpoints 1, 2, 3, or 4 without first setting the CHANNEL_SELECT descriptor. If you issue a SetDescriptor CHANNEL_SELECT index 0 command with bmDirection set to OUT to a channel that is busy, you will receive a STALL response. The CHANNEL_SELECT descriptor may be used to reset an operating I2C bus.
In the next table, assume channel 0 is busy and channel 1 is not. The data for the CHANNEL_SELECT descriptor for channel 0 is as shown in Table 17 below.
The data for the CHANNEL_SELECT descriptor for channel 1 is as shown in Table 17 below.
The transactions would then appear as shown by
Data overruns may be handled differently between IN and OUT endpoints. Data overruns from an IN endpoint simply require USB2I2CH32 device to send a short packet at the end of the data. If the last packet sent was equal to the endpoint maximum transfer size, an additional zero length data packet is sent. For out endpoints, the overrun DATAx packet is acknowledged by a functional stall.
The I2C interface is a 2-wire, open drain, multi-master, multi-drop, half duplex, serial bus with transfer speeds of up to 3.4 Mbs. The I2C interface uses a master-slave protocol. All transfers may be unary (single master, single slave) in nature, and initiated and controlled by the master. Slave devices may be able to extend transfer timing by a “clockstretching” mechanism, whereby they can hold the transfer timing signal (SCL) low for an additional period. Individual I2C transactions may either read or write data from a single slave device.
In an I2C idle condition, all masters and all slaves may be in a non-driving state, and both SDA and SCL are at a high level. During warm system restarts, the USB2I2CH32 can provide a mechanism to return slave devices lacking asynchronous reset capabilities to idle condition.
I2C transfer timing may be set by the lowest speed device involved in the transfer. I2C is an open-drain bus; meaning that driving devices may only set the bus to a low level. Pullup resistors return it to a high level. The master attempts to set the driving speed by setting SCL low at intervals of twice the selected transfer bit rate (transfer rates for the USB2I2CH32 can be either 100 Kbs or 400 Kbs) and cease drive at 1//(2×transfer rate) later. If the slave device(s) needs to extend the transfer interval, it may continue to drive SCL low until it is ready to accept another bit. This process is known as “clock stretching”. When SCL returns to a high level, the master can wait at least 1/(2×transfer rate) before diving SCL low again. Clock stretching can only affect the total period of a bit transfer and not duty cycle of SCL.
Normally SDA can only transition while SCL is at a low level. There are two exceptions. When the I2C bus is transitioning from an idle to an active state, the master device will hold SCL inactive (high) while driving SDA from high to low. This is known as a start pulse. When the I2C bus is transitioning from an active to an idle state, the master may leave SCL high while transitioning SDA from low to high.
This is known as a stop pulse. Stop pulses are not required for every transaction. For instance, in the case where an I2C transaction immediately follows another transaction, the second start pulse can serve as both a stop pulse for the previous transaction and the start pulse for the subsequent transaction (known as a re-start).
I2C addresses and data are sent as octets (8-bits) on SDA, most significant bit first. Following each octet is a single cycle acknowledge sent from the address or data destination device.
I2C addresses are sent by the master with an octet on SDA immediately following the start pulse. The octet contains the slave device address in bits 7:1 and the direction of the data transfer in bit 0. A one in but zero indicates a read transaction, that is data will be transferred from the slave to the master. A zero indicates a write transaction where data is transferred from the master to the slave. When a slave device recognizes its address, it can pull SDA low for one SCL cycle immediately after the read/write bit of the address octet. This is known as address acknowledge. If SDA remains high during this period (negative acknowledge or NAK), the master will immediately terminate the transaction and return the bus to idle.
The master may begin an I2C read transaction be sending a start pulse followed by an octet containing the slave address in bits 7:1 and a 1 in bit 0, indicating a read operation. The slave device responds by pulling SDA low for a single cycle (address acknowledge), and then immediately sends an octet of data. The master responds to each data octet by pulling SDA low for a single cycle (data acknowledge) following each data octet if it wishes to continue reading subsequent data byes, or by leaving SDA high for this period (NAK) when the last byte has been transferred. The NAK terminates the transfer and the master and slave devices both return the bus to its idle state. There is no stop pulse required for I2C read transactions.
The master begins an I2C write transaction be sending a start pulse followed by an octet containing the slave address in bits 7:1 and a zero in bit 0, indicating a write operation. The slave device responds by pulling SDA low for a single cycle (address acknowledge). The master then begins sending octets of data. After each octet, the slave responds by pulling SDA low for a single cycle (data acknowledge). After the last byte of data is transferred the master issues a stop pulse if there are no subsequent I2C transactions, or a re-start to terminate the current transaction and begin the next.
Although the USB2I2CH32 resembles a Control, Bulk, Interrupt (CBI) device, the CBI class driver does not have enough flexibility to operate the subsystem. Therefore, a vendor specific class and protocol were defined for this device.
The USB2I2CH32 device driver may be able to communicate directly with the Enhanced Host Control Interface (EHCI) driver for high speed operation and with the Open Host Control Interface (OHCI) driver for full speed operation. The application can communicate with the USB2I2CH32 driver using file operations.
Because of the protocol used, the driver cannot be re-entrant and must employ a MUTEX such as a SPINLOCK. To facilitate optimal performance, it is suggested that the driver maintain a transaction queue.
I2C bus operations may be controlled and reported via a structured file. There is one structured file per bus. The files are named /dev/i2cbus<x> where x represents the I2C bus number. Each file contains transmit and receive buffers, followed by the structure:
representing bus values. The file is structured as follows:
The transmit and receive buffers may be read or written separately. From 1 to 256 bytes of the transmit or receive buffer may be read or written for any transaction. The I2C_REGS structure is also accessed separately. The entire structure must be read or written at one time. When initializing a transaction it must be written last. Normally a process will open a file and first write the transmit buffer. When that write is complete, it can write the receive buffer if a compare operation is going to be used. Finally, it can write the I2C_REGS structure to initiate the I2C bus transaction(s) and closes the file. It can repeat these steps for every bus it wishes to initiate. When the process is informed of an I2C completion via the status monitoring, it can reopen the file, read the receive buffer, read the I2C_REGS structure, and close the file. This can avoid the problems associated with too many file handles.
Status monitoring can be accomplished via a set of service requests read from the file /dev/i2cstatus as a single long unsigned. The read can complete once every two milliseconds for high speed mode or once every twenty milliseconds for full speed mode. Normally, a single process can perform the status monitoring task and then use inter process communications (IPC) message queues to relay the information to the I2C bus processes.
There may be a status mask associated with each IPC message queue. When a service request matching one of the bits in the mask is active, the monitoring task can enter a message into the associated queue. The I2C bus task can then know when to service its associated I2C busses.
When using an FPGA the configuration information needs to be installed in read-only memory (ROM). On some FPGAs, this memory is internal to the FPGA is normally accessed via a IEEE 1144.1 Joint Test Access Group (JTAG) bus. Other FPGAs use an external ROM, and access it with a variety of methods. When an external read only memory (ROM) is used, it may be a one-time programmable (OTP) device, or an erasable electronic programmable read only memory (EEPROM). An EEPROM with programming access via JTAG may be the best solution.
The ULPI and USB transport interfaces may, for example, implement the test modes required by the “Universal Serial Bus Specification Revision 2.0 Apr. 27, 2000” through use of the SetFeature(TEST_MODE), Device command. The standard test modes are:
-
- Test mode Test_SE0_NAK: Upon command, a port's transceiver must enter the high-speed receive mode and remain in that mode until the exit action is taken. This enables the testing of output impedance, low level output voltage, and loading characteristics. In addition, while in this mode, upstream facing ports (and only upstream facing ports) must respond to any IN token packet with a NAK handshake (only if the packet CRC is determined to be correct) within the normal allowed device response time. This enables testing of the device squelch level circuitry and, additionally, provides a general purpose stimulus/response test for basic functional testing.
- Test mode Test_J: Upon command, a port's transceiver must enter the high-speed J state and remain in that state until the exit action is taken. This enables the testing of the high output drive level on the D+ line.
- Test mode Test_K: Upon command, a port's transceiver must enter the high-speed K state and remain in that state until the exit action is taken. This enables the testing of the high output drive level on the D− line.
- Test mode Test_Packet: Upon command, a port must repetitively transmit the following test packet until the exit action is taken. This enables the testing of rise and fall times, eye patterns, jitter, and any other dynamic waveform specifications. The test packet is made up by concatenating the following strings. (Note: For J/K NRZI data, and for NRZ data, the bit on the left is the first one transmitted. “S” indicates that a bit stuff occurs, which inserts an “extra” NRZI data bit. “* N” is used to indicate N occurrences of a string of bits or symbols.). Table 20 shows an example test packet.
In an example, the port in Test_Packet mode must send this packet repetitively. The inter-packet timing must be no less than the minimum allowable inter-packet gap of 88 bit times (32 bit times as measured at the hosts receptacle), and no greater than 125 μs.
Provisions have been made in the I2C control register files to enable I2C line testing of both SDA and SCL. To perform a short test, use the manual control modes in the configuration register. The read back the state of SDA and SCL from the status register.
Endpoints 1 and 2 are setup so a system memory diagnostic can be run. The diagnostic must first the interface in a disabled state by means of the configuration register, and then the test patterns can be written to and read from the transmit and receive buffers.
As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium (including, but not limited to, non-transitory computer readable storage media). A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing. Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter situation scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
Aspects of the present invention are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a,” “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
The descriptions of the various embodiments of the present invention have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.
Claims
1. A method comprising:
- providing a system comprising a universal serial bus (USB) interface and a multi-channel interface configured to communicatively connect to a plurality of subrate channels;
- communicatively connecting the subrate channels with a computing device via the USB interface; and
- communicating, to the computing device, connection specifications for the subrate channels.
2. The method of claim 1, wherein the USB interface is a USB transport layer interface.
3. The method of claim 1, wherein the channels are one of I2C, RS-232, and RS-485 channels.
4. The method of claim 1, wherein communicating connection specifications comprises communicating, to the computing device, one of a number of the subrate channels and a subrate type.
5. The system of claim 1, wherein communicating connection specifications comprises communicating, to the computing device, one of transmit buffer information, receive buffer information, register information, and subrate protocol information.
6. The method of claim 1, wherein communicating, to the computing device, the connection specifications comprises communicating the connection specifications to the computing device during enumeration.
7. The method of claim 1, further comprising selecting one of the subrate channels for connection with the computing device via the USB interface.
8. The method of claim 1, further comprising resetting one of the subrate channels.
9. The method of claim 8, further comprising selecting a direction of communication of the subrate channels.
Type: Application
Filed: Oct 24, 2013
Publication Date: Apr 30, 2015
Applicant: International Business Machines Corporation (Armonk, NY)
Inventors: Daniel J. Barus (Raleigh, NC), Robert M. Piper (Apex, NC), Donald G. Polak (Graham, NC)
Application Number: 14/061,867
