Patent Application
20080005366
1. Field
The present application relates to apparatus and methods for an interface and, more particularly, apparatus and methods effecting an interface controlled through utilization of dedicated hardware that does not require software dynamic intervention for carrying out communication over the interface.
2. Background
In electrical devices, particular those utilizing microprocessors and integrated circuits, communications between circuits in such devices normally require some type of interfacing to effect those communications. Certain types of interfaces, such as those between a hardware circuit to another hardware circuit utilize the intervention of software instructions for addressing the communications and determining what type of communication signals are being communicated. As an example, in communication devices, such as mobile phone devices, it is known to communicate between a microprocessor (e.g., a General Purpose Processor (GPP) or digital signal processor (DSP)) or other hardware circuitry and one or more RF (Radio Frequency) chips, which are used for transmitting and receiving wireless signals, using an interface, such as a serial interface. Typically, the RF chips communicate with either the microprocessor or a dedicated hardware controller, both of which may issue requests (e.g., read and writes) via the interface. In this example, the interface may be a serial bus interface, which is known for providing control of RF chips, but other known types of serial or parallel interfaces may also be utilized. It is noted that the RF chips may consist of integrated circuits (RFIC), circuit blocks or circuit modules
Furthermore, given the examples above, specific types of control in a communication device are effected via the interface with the RF chips. In particular, various functional blocks within an RF chip require initialization and updates when certain events occur. One such event is when the communication device is powered on. Another event could be when the device switches between active states and sleep states (for conserving energy) while being powered on and off. Other control communications carried out via the interface could include updating DC correction values and changing gain states. Typically, the routing for these service requests, also termed “hardware requests” since they are typically originated by dedicated hardware, is performed by hard coding the service routines for each service (hardware) request. Such hard coding, however, can result in inflexible hardware prone to errors.
According to an aspect of the present disclosure, a hardware request controller for control of interfacing between a hardware circuit and another circuit is disclosed. The controller includes a first memory configured to receive and store data concerning memory address locations in another memory. A second memory is also included and configured to receive and store at least one of read data or write data used for reading data from and writing data to the another circuit. The controller further includes master state machine logic configured to receive at least one hardware request command from the hardware circuit and to determine address locations to be accessed in the second memory based on the data concerning memory locations stored in the first memory. Finally, the controller includes interface dependent logic configured to transfer read out data from the second memory to the another circuit via an interface bus.
According to another aspect of the present disclosure, an interface apparatus is disclosed having a microprocessor interface configured to interface the interface apparatus with a microprocessor. The apparatus also includes a hardware request controller configured as a hardware circuit and operable to receive hardware requests from hardware circuits and data from the microprocessor through the microprocessor interface. The interface apparatus further includes a bus interface module including a software port configured to receive data from the microprocessor interface, an arbiter configured to arbitrate between data output by the software port and the hardware request controller, and a bus interface configured to communicate data from at least one of the hardware request controller and the microprocessor to an external circuitry via an interface bus.
According to still another aspect of the present disclosure, a transceiver is disclosed including at least one radio frequency transmission circuit and a microprocessor interface configured to interface the interface apparatus with a microprocessor. The transceiver also includes a hardware request controller configured as a hardware circuit and operable to receive hardware requests from hardware circuits and data from the microprocessor through the microprocessor interface. Finally, the transceiver features a bus interface module including a software port configured to receive data from the microprocessor interface, an arbiter configured to arbitrate between data output by the software port and the hardware request controller, and a bus interface configured to communicate data from at least one of the hardware request controller and the microprocessor to the at least one radio frequency transmission circuit via an interface bus.
According to yet another aspect of the present disclosure a method for interfacing between a first hardware circuit and a second circuit is disclosed. The method includes receiving at least one hardware request from the first hardware circuit; reading address data from a first memory device based on a mapping of the at least one hardware request to a memory location in the first memory, wherein the address data includes memory location information of data stored in a second memory device; reading the data stored in the second memory device by using the address data read from the first memory to an interface module; and executing an operation in the interface module to interface with the second circuit based on the data read from the second memory device.
According to another aspect of the present disclosure, an apparatus for interfacing two circuits is disclosed. The apparatus includes means for receiving at least one hardware request from the first hardware circuit; means for reading address data from a first memory device based on a mapping of the at least one hardware request to a memory location in the first memory, wherein the address data includes memory location information of data stored in a second memory device; means for reading the data stored in the second memory device by using the address data read from the first memory to an interface module; and means for executing an operation in the interface module to interface with the second circuit based on the data read from the second memory device.
According to still another aspect of the present disclosure, a computer-readable medium encoded with a set of instructions is disclosed. The instructions include an instruction for receiving at least one hardware request from the first hardware circuit; an instruction for reading address data from a first memory device based on a mapping of the at least one hardware request to a memory location in the first memory, wherein the address data includes memory location information of data stored in a second memory device; an instruction for reading the data stored in the second memory device by using the address data read from the first memory to an interface module; and an instruction for executing an operation in the interface module to interface with the second circuit based on the data read from the second memory device.
Like numerals refer to like parts throughout the several figures of the drawings.
The present disclosure includes methods and apparatus for effecting an interface that is flexible by allowing software coding of hardware portions of the interface. In particular,
The transceiver module 101 further includes an interface module 104 used as an interface for requests and instructions communicated between the microprocessor 102 and hardware circuits 103 with RF chips 118. The interface module 104 may be supported by and in communication with the microprocessor 102 via one or more interfaces 106, such as a General Purpose Input Output (GPIO), an external bus interface, SPI or I2C buses as examples.
Interface module 104 includes a microprocessor interface 108, which serves to transmit requests and information between the module 104 and the microprocessor 102. Interface module 104 also includes a hardware request controller 110, which receives hardware service requests 112 from the hardware circuits 103 within the transceiver module 104. Such hardware requests could include, but are not limited to, DC Offset correction, automatic gain control (AGC) and sleep control commands for energy saving sleep operation of the transceiver module 104. It is noted, however, that the disclosed implementation is not limiting, and the requests could be any type of requests, such as read/write requests that are communicated from one device to another via an interface, whether serial or parallel.
The hardware request controller 110 serves to receive hardware requests 112 and, in turn, effect the timing or ordering of the output of these requests to a bus interface module 114, as will be explained below in connection with
The requests output by the hardware request controller 110 are sent to the bus interface module 114 via connection 115 in order to execute write and read operations with the RF chips 118 over the bus interface module 114 and bus 120 using various signals, which will be discussed later. It is noted here, however, that although the bus interface module 114 and bus 120 in the disclosed examples typically effect a serial bus interface, one of ordinary skill in the art will appreciate that the present disclosed interface may also be applicable to other types of interfaces as well, such as parallel interfaces.
Additionally, as illustrated with a microprocessor interface bus 116, the hardware request controller 110 may also receive configuration data from software run by microprocessor 102, via the microprocessor interface 108. The interface bus 116 is also configured to direct software requests directly to the bus interface module 114. The bus interface module 114 decides or “arbitrates” between hardware requests from the hardware request controller 110 via connection 115 and software requests received via interface 108 and interface bus 116. The requests and accompanying data are sent to RF chips 118 (e.g., data write requests). Additionally, data may be received from the RF chips 118 (e.g., data read requests).
The system of
Of further note,
In servicing requests, the master state machine 302 directs the reading and writing of data within a configuration memory 304 and a data memory 306. The configuration and data memories 304, 306 store address and data information for write and read operation performed over the serial interface module 114. Additionally, the controller 110 includes configuration memory address logic 308 to point to dedicated address space within the configuration memory 304 for each hardware and software request received by the controller 110.
Concerning the configuration address logic 308, this logic 308 assigns each type of hardware request with its own individual corresponding address location in the configuration memory 304. In particular, logic 308 assigns starting addresses, which are actually corresponding addresses within the configuration memory 304. Thus, each type of hardware request is mapped to a corresponding starting address within the configuration memory 304 by logic 308, which in turn contains address information and the numbers of locations for data within the data memory 306. When a particular hardware request is received, the configuration address logic 308 provides the address location to point to within the configuration memory 304. As an example of one configuration, which is illustrated in
Once the pointer of configuration memory 304 is updated after a request is received, a corresponding data memory address 314 is read from the memory location in the configuration memory 304. As an illustration,
It is noted that the width of the configuration memory 304 (or 402 in
The operation described above is effected under direction of an interface dependent logic 320 that issues a memory index signal 315 to allow memory addresses 314 to be read out of the configuration memory 304 by an address generation logic/multiplexer 316 causing the particular data memory address to be selected for the pointer location of the data memory 306.
As illustrated further in
A memory location 414 following the address field 412 contains data to be written for write operations (e.g., WR_DATA). In the case of a read, on the other hand, the data field, such as shown at located 418, after an address field (e.g., location 416) represents the expected data that will be read (e.g., EXP_DATA). Additionally, a location 420 following expected read data is used to mask specific bits during comparison. The bit positions indicated by a 1 in the mask are then excluded (or, alternatively, included, whereas positions indicated by a zero are excluded) from comparison. If the most significant bit (410) of the data field is set to a value of one (1), for example, the read or write command stored therein will be ignored and no operation (NOP) will be performed. An example of a NOP is illustrated by location 432, including a write operation. The MSB field 410 of location 432 is set to a value of one (1) and, thus, will ensure no operation is performed.
According to another featured aspect, a transaction can also be delayed by a time amount specified by either one or two locations preceding the address location. As an example, the delay values listed can be in multiples of clock cycles of the clock supplied to the hardware request controller 110. More particularly, in a wireless transceiver that utilizes a Temperature Compensated Crystal Oscillator (TCXO) for system timing, the delay could be set to multiples of 20 TCXO clock cycles, for example. Accordingly, a value of 25 decimal would yield a delay of the next transaction by 25*20 (=500) TXCO clock cycles. If the delay value is small enough to fit within one row, the most significant bit of the first delay location can be cleared (i.e., set to a binary value of 0). The rest of the bits (i.e., the eight bit field 422 of the location) then represent the time by which the next transaction will be delayed. In such cases, the next row within the data memory 408 will hold the address of the next transaction. Examples of these delay entries are shown with reference numbers 424 and 426 in
On the other hand, if a delay value is too great to be stored within a single row of the data memory 408, the most significant bit of the first delay location can be set to a binary value of one (1) and the location immediately following that location can be further used to represent the delay. In such a case, the eight bits (field 422 excluding the most significant bit field 410) are read from the first location and this first eight bits forms the LSB and the least significant eight bits (plus one bit, which is MSB field 410) from the second location forms the MSB of the delay value. An illustration of such a delay entry may be seen in
If a transaction has to be delayed by a value greater than what can be specified in two locations in the data memory 408, adjacent instructions can be marked as No Operation (NOP) by setting the MSB of the data field (410) to a binary value of one (1). The delay fields corresponding to these NOP instructions will still be valid and can be combined to create even larger delays between transactions if needed.
Turning again to
It is further noted that the master state machine logic 302 or data memory control logic within the hardware request controller 110 may include a counter or counters (not shown) in order to keep track of how many locations are read from the data memory 306. The counter or counters could also be used to keep track of how many times data from registers in the RF chips 118 have been read out prior to matching the expected value.
At block 506, the state machine next determines whether multiple requests have been received. If two or more requests are pending, flow proceeds to block 507 where priority between the requests is determined and then flow proceeds to block 508. This priority may be determined by the state machine 302. Alternatively, if only one request is received as determined at block 506, flow simply proceeds directly to block 508
At block 508 the state machine 302 directs a read operation of the address and number of location (NUM LOCATIONS) from the configuration memory 304. As an example of an implementation of this functionality, the master state machine 302 causes the memory index signal 314 to be delivered by the address generation logic/multiplexer logic 316 through signal 313 to effect reading of the data in configuration memory 304 to data memory 306. It is noted that the process 500 will remain at block 508 until all of the configuration memory locations are read and the pointers and counters are updated.
After the configuration memory locations are read, flow proceeds to block 510, where the data in the data memory 306 is read out iteratively. Further details of the operation of block 510 are discussed below in connection with
It is noted that for the particular implementation of
Once a request is received, the process 600 proceeds to decision block 606, which differentiates between whether the request will require a read or write of data to or from the RF chips 118, as an example, or is a No Operation (NOP) entry, like that illustrated by data memory location 432, discussed previously. If the instruction is a read instruction, flow proceeds to block 608; where the instruction is read out from the data memory to direct the interface module 114 to read data from the RF chips 118. If the instruction requires a checking or comparison of the data read from the RF chips 118 to an expected value, as discussed previously in connection with entries 420 and 418 in
Decision block 612 determines whether a delay is desired. If a delay is desired, flow proceeds to block 614, where the delay operation is effected for a prescribed time period. For example, if the data read from data memory 306 includes two delays, such as delays illustrated by locations 428 and 430 in
If the instructions read from the data memory 306 indicate a write instruction as determined at decision block 606 , flow will proceed to block 618. At block 618, data to be written to the RF chips 118 stored in the data memory (e.g., location 414 shown in
Finally, if the data read from the data memory indicates a NOP (i.e., the MSB of the next location in data memory 306 is equal to a “1”) as determined at block 606, flow simply proceeds to decision block 622 to determine if a delay is desired. If so, flow proceeds to block 614 for delay of a prescribed period as determined by the data read out from data memory 306 and then flow proceeds to termination block 616. Alternatively at block 620, if no delay is desired, flow simply proceeds directly to block 616.
It is noted that the process 600 correlates to the process of block 510 in
Concerning the effecting of read commands in the particular disclosed in the example of
According to another example, hardware request controller 110, in conjunction with the interface module 114, may be used to turn on the RF chips 118, such as at start up of the transceiver or when the transceiver enters or is brought out of an energy-saving sleep mode. In the situations of bringing the transceiver into or out of a sleep mode, in particular, the RF chip turn on (or off) may be accomplished by writing predetermined data from the software via interface 116 to specific locations in the data memory 306 during start-up.
Turning back to
The apparatus 700 further includes means for reading the data stored in the second memory device 710 by using the address data read from the first memory device 706 and reading the data to an interface module to an interface module 714. The interface module is also in communication with means for executing an operation in the interface module 712, in order to effect interfacing with the second circuit based on the data read from the second memory device 708.
It is noted that the first and second memory devices 706, 708 correspond to the configuration memory 304 and the data memory 306, discussed previously. Additionally, means 702, 704 and 710 may implemented by the master state machine 302 and the state machine in the data memory 306, discussed above. Means 712 may be implemented by the state machine 302, the data memory state machine, the interface dependent logic 320, and the arbiter 204 discussed above. Finally, the interface module 714 may be implemented by the interface module 114 discussed previously.
The disclosed apparatus and methods afford an interface utilizing hardware that is more flexibly configured with a reconfigurable configuration and data memories. This allows the hardware to have more flexibility like software to reduce errors typical with hardcoding in previous interfaces without the attendant latency inherent with serving these requests in software compliant with different interfaces. Accordingly, the present interface ensures that requests from hardware circuits are communicated in a timely fashion to avoid errors resulting from missed timing due to delay of either hardware or software.
The examples described above are merely exemplary and those skilled in the art may now make numerous uses of, and departures from, the above-described examples without departing from the inventive concepts disclosed herein. Various modifications to these examples may be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other examples, e.g., in an instant messaging service or any general wireless data communication applications, without departing from the spirit or scope of the novel aspects described herein. Thus, the scope of the disclosure is not intended to be limited to the examples shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein. The word “exemplary” is used exclusively herein to mean “serving as an example, instance, or illustration.” Any example described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other examples. Accordingly, the novel aspects described herein is to be defined solely by the scope of the following claims.
