Generic interface for operating modes of modules

A generic interface for a module, method of providing a generic interface, and a module controller system providing a register slave having a generic interface are described. The interface includes an addressable interface, a control interface, and a module interface configured to interact with two or more module configurations. The interface has multiple operating modes at least one of which includes a monitor mode. The method includes receiving an address from a register master identifying the module address to be monitored, reading the received module address content from the module, and transmitting the read content to the monitor port. The system includes a register master, a register slave connected with the register master and adapted to connect with the module, and a monitor port connected with the register slave to receive the monitored module address contents. The register slave configured to interact with two or more module configurations and having a monitor mode for monitoring a specified module address.

FIELD OF THE INVENTION

The present invention relates to a generic interface for operating modes of modules.

BACKGROUND

Microprocessors often include modules for storing instructions and data and/or for operating on instructions and data. The modules include storage or memory modules and functional modules. Memory modules include registers, random access memory, read only memory, etc. Functional modules include counters, finite state machines, output of logic functions, etc. The microprocessor accesses the modules through the use of a control system including a register master connected with one or more register slaves. One or more of the register slaves are associated with, and provide the microprocessor interface to, a module. That is, the microprocessor transmits an address to the register master and specifies whether a read of data located at the provided address is to be performed or a write of data provided by the microprocessor to the provided address is to be performed. The register master communicates this information to the register slave.

The register slave then requests an access to a particular location, e.g., a memory location if the module is a memory module, a logic function if the module is a functional module, specified by the provided address. The access type is specified by a read or write control signal. The register slave interface with the module varies based on the control signals, i.e., the control and data signals transmitted across the register slave-module interface varies depending on the module to which the register slave is interfaced.

In many cases the module access is partitioned into two separate pieces: a master component such as the register master and a slave component such as the register slave. The master component handles interfacing with the microprocessor bus. The slave component is custom configured for each particular module type and handles interfacing with the module. The master component communicates with the slave component using a particular protocol, i.e., timing and order of data and control signals. Each module to be addressed under previous approaches requires design and testing of a new interface between the microprocessor, register master, slave component, and module. Further, for each new module to be interfaced with a microprocessor, design and testing of a corresponding slave component is required. That is, each slave component interface with the master component and the module is designed anew for each new module to which the slave component is interfaced.

Designing anew or redesigning the slave component for each new module incurs increased development time and cost. Further, testing requirements are increased for both functionality (correctness), timing, and corner case condition detection and correction. Further still, increased testing and development frequently requires increased time and cost related to updating testing tools and procedures to account for a new design. Further still, in order to obtain additional functional capabilities in a new design, e.g., testability, additional design and development costs are incurred.

SUMMARY

An apparatus embodiment of a generic interface for a module includes an addressable interface, a control interface, and a module interface configured to interact with two or more module configurations. The interface has multiple operating modes at least one of which includes a monitor mode.

A method embodiment of providing a generic interface for a module, where the generic interface is connected with the module, a register master, and a monitor port, the generic interface having multiple operating modes, includes receiving an address from the register master identifying the module address to be monitored, reading the received module address content from the module, and transmitting the read content to the monitor port.

A system embodiment of a module interface providing a register slave having a generic interface for a module, where the register slave has multiple operating modes, includes a register master, a register slave connected with the register master and adapted to connect with the module, a monitor port connected with the register slave to receive the monitored module address contents. The register slave is configured to interact with two or more module configurations and have a monitor mode for monitoring a specified module address.

Construction and operation of embodiments according to the present invention will become readily apparent to those skilled in the art from the following detailed description, wherein the embodiments are shown and described, simply by way of illustration of the best mode contemplated of carrying out the invention. As will be realized, the invention is capable of other and different embodiments, and its several details are capable of modifications in various obvious respects, all without departing from the invention.

DETAILED DESCRIPTION

FIG. 1depicts a high level block diagram of a portion of a microprocessor100. Various components are provided on microprocessor100including a register master102, a register slave104, a module106, a second register slave108, a second module110, a third module112, a third register slave114, and a monitor module116. Register slave104is designed to provide a generic interface for module106.

Second register slave108and third register slave114are identical to register slave104; however, the second and third register slaves may differ in terms of the connection with and interaction with second module110and third module112in accordance with the below description of embodiments according to the present invention. For ease of description, register slave104will be primarily described below.

Register master102interacts with other components of microprocessor100including register slaves104,108, and114, monitor module116, and a central processing unit among others. Register master102reads and writes data received from the CPU (not shown) to/from a specified location in a module106,110,112. Register master102transmits a read/write request from the CPU to the modules106,110, and112. The transmitted read/write request includes an address specifying a location as well as an indication of whether the request is a read or a write of data. If register master102requests writing of data, the read/write request further includes the data to be written to the address. Additionally, additional control signals are transmitted from register master102to modules106,110, and112for controlling the operation of the included register slaves104,108, and114. For example, one such control signal causes a register slave (104,108, and114) to begin monitoring a particular address in the connected module (106,110, and112).

According to an embodiment, during register slave104monitoring of a particular address in a connected module106, the read content of the address is continuously monitored by the register slave in order to provide observability within the module. For example, monitoring by register slave104may provide insight into not only memory location contents, but also to data and other information regarding the operation, status, etc. internal to modules including logic functions. As described below, register slave104provides monitored data to monitor module116.

Module106is a module, e.g., a memory storage medium such as a random access memory (RAM) or a read only memory (ROM), registers, counters, and other types of storage and logic gates, in communication with register master102via register slave104to which data is read and written by the CPU during execution.

Module106interacts with the CPU via register master102and register slave104. As described above with respect to register master102, the register master exchanges signals with module106. In particular, register master102exchanges signals with register slave104which is coupled with and forms a part of module106. In an embodiment, register slave104forms the interface for module106to communicate with additional components of microprocessor100. In another embodiment, register slave104is a component separate from, but connected with, module106and forming the interface for the module.

In one embodiment, third module112monitors events from a given memory location passing along first monitor channel bus126and second monitor channel bus128(described below). In this manner, third module112functions as a counter based on the content of the channel (126,128).

Monitor module116connects with register master102, module106(via register slave104), second module110(via second register slave108), and third module112(via third register slave114). Monitor module116connects with an output port118of microprocessor100in order to enable monitoring of the contents of a memory location in one of modules106,110, and112.

A master/slave (M/S) bus120interconnects register master102with register slave104, second register slave108, third register slave114, and monitor module116thereby enabling the transfer of data from the register master to the other components104,108,114, and116. The data passed along the M/S bus120includes addressing, data to be written, and control information, e.g., a read/write signals, etc.

A read data bus122connects register slave104, second register slave108, and third register slave114to register master102and monitor module116thereby enabling the transfer of read data from modules106,110,112to the register master and the monitor module. The data passed along read data bus122includes data read from a memory location in one of modules106,110,112.

A monitor control bus124connects register master102with register slave104, second register slave108, third register slave114, and monitor module116to allow the register master to transmit monitor control signals to the register slaves and to the monitor module. The monitor control signals are used to control addressing information transmitted from a register slave104,108,114to a module106,110,112, as described below in detail. If one of the register slaves104,108,114is monitoring a memory location and one of the modules106,110,112and providing this information to monitor module116via read data bus122, monitor control bus124provides a mechanism to enable/disable such monitoring by a register slave.

A first monitor channel bus126, shared with read data bus122, provides data from read data bus122to monitor module116and thereby to output port118. Monitoring of data along first monitor channel bus126is altered upon a CPU-based read occurrence from register master102as the CPU-based read is a higher priority. In accordance with an embodiment, register master102performs only a single read or write at a time, e.g., only a single module106,110, or112is read or written.

A second monitor channel bus128provides monitored data from register slave104, second register slave108, third register slave114, and register master102. In an embodiment, second monitor channel bus128provides monitored data from register slave104,108,114by transferring monitor data to the monitor module116. In accordance with an embodiment, a single module may be monitored per monitor channel bus126,128.

FIG. 2depicts a high-level input/output diagram of register slave104, as well as indicating five interconnection options for connecting between register slave104and module106. Each of the five interconnection options will be described in further detail below; however, it is to be understood that combinations of the input and output connections identified inFIG. 2may result in more than five interconnection options.

As depicted inFIG. 2, register slave104receives the following input signals: a module identifier input, e.g., module id[9:0]200, a mask input, e.g., mask[6:0]201, a clock input, e.g., clk202, a reset input, e.g., reset_L203, a ‘monitor on’ input, e.g., monitor_on204, a CPU speed monitor input, e.g., cpu_speed_mon205, and a CPU command, address, and data (CAD) input, e.g., cpu_cad[16:0]206. Specifically, ‘monitor on’ input204, CPU speed monitor input205, and CPU CAD input206transfer over M/S bus120from register master102(FIG. 1) to register slave104. The module identifier input200is a unique module id number identifying the module106and provides an identifier of the module connected to the register slave from the module to the register slave. For example, module identifier input200may specify a range of addresses for which addresses the module is responsible.

Mask input201enables handling modules of different size and/or addressing ranges. In combination with module identifier input200, mask input201enables divvying up the addressing space among multiple modules.

Reset line203causes a reset of the register slave104. In one embodiment, reset line203is always asserted and causes a reset if driven low.

Register slave104transmits monitor data via first and second monitor channel buses126,128(FIG. 1). Monitor data includes data stored in a particular memory location of module106connected to register slave104. In one embodiment, register slave104includes a storage mechanism, e.g., a buffer, for storing data received from a monitored location of module106.

Turning now to the interface with module106, register slave104transmits the following output signals to the module: an upper read address, e.g., slv_read_dup_addr[27:2]208, a lower read address, e.g., slv_read_dlo_addr[27:2]209, a slave read monitor signal, e.g., slv_read_mon210, an address, e.g., slv_addr[27:2]211, an address monitor, e.g., slv_addr_mon212, a read not write (RNWR) signal, e.g., slv_rnwr213, a slave request, e.g., slv_req214, and a write data signal, e.g., slv_wr_data[31:0]215. Register slave104receives the following input signals from module106: a first read data input, e.g., slv_rd_data[31:16]218, a second read data input, e.g., slv_rd_data[15:0]219, an acknowledgement input, e.g., slv_ack220, a monitor lower valid input, e.g., mon_dlo_valid221, and a monitor upper valid input, e.g., mon_dup_valid222.

A further description of each of the above-identified signals is now provided. The output signals from register slave104to module106are addressed first. Upper read address208, lower read address209, and address211are all signals indicating specific location to be read/written from/to in module106. Write data signal215is the data to be written to the specified module location, i.e., as specified using address211.

FIG. 8, described in more detail below, depicting a high level logic diagram of an addressing mechanism according to an embodiment is referred to in conjunction with the description ofFIG. 2. Register master102provides desired address locations of module106to be monitored via monitored address registers, e.g., mon_add_lo_reg301(FIG. 8) and a second monitored address, e.g., mon_add_up_reg302(FIG. 8). For example, CPU (not shown) specifies via register master102which address locations in module106are to be monitored. Similarly, register master102stores an address to be read/written in address register300(FIG. 8).

RNWR signal213and slave request214are shared and common to different types of module106. On a CPU write, address signal211, address monitor signal212, and write data signal215provide the CPU write data if upper read address208lower read address209, and slave read monitor signal210are either inactive or driving the monitor needed signals if ‘monitor on’ input signal204is true. On a CPU read, upper read address208, lower read address209, slave read monitor signal210, address signal211, address monitor signal212, and write data signal215provide the CPU read data. On a CPU write, the read-write ports (FIG. 8) are affected, as described above. On a CPU read, the 2 sets of ports: read and read-write (FIG. 8) are affected, as described above.

The register slave contains a sequencer, e.g., a finite state machine (not shown), defining the series of events with the appropriate controls for supporting different possible states of the interface of register slave104to module106: a ‘totally inactive’ state; an ‘only monitoring data’ state; a ‘CPU write without monitoring on’ state; a ‘CPU read without monitoring on’ state; a ‘CPU write with monitoring on’ state and a ‘CPU read with monitoring on’ state. In an embodiment, these 6 different states describe the entire needed functionality of the register slave104and module106interface.

Each of the above-listed states is now described with respect to the status of particular signals on the register slave104and module106interface. True and false signal designations indicate assertion or de-assertion of the particular signal, respectively. In the ‘totally inactive’ state, slave request214, address monitor212and read monitor210signals are false.

In the state of ‘only monitoring data’, slave request214is false, address monitor212and read monitor210are both true, address bus211and lower read address209drive the data contained in the address low register301, and upper read address208drives the data contained in the address up register302.

In the ‘CPU write without monitoring on’ state, slave request214is true, RNWR signal213is false, address monitor212and read monitor210are both false, address bus211drives the data contained in address register300, and write data bus215drives the data to be written in module106.

In the ‘CPU read without monitoring on’ state, slave request214is true, RNWR signal213is true, address monitor212and read monitor210are both false, address busses211,208and209drive the data contained in address register300, and write data bus215is inactive.

In the ‘CPU write with monitoring on’ state, slave request214is true, RNWR signal213is false, upper address208drives the data contained in the address up register302, lower address209drives the data contained in the address low register301, read monitor210is true, address monitor212is false, address bus211drives the data contained in address register300, and write data bus215drives the data to be written in the module106.

In the ‘CPU read with monitoring on’ state, slave request214is true, RNWR signal213is true, address monitor212and read monitor210are both false, address busses211,208and209drive the data contained in address register300, and write data bus215is inactive.

Slave read monitor signal210, address monitor212, RNWR signal213, and slave request214all work together to specify the monitoring status and/or CPU access of register slave104in combination with module106. Slave read monitor signal210specifies whether the address provided by upper read address208, and lower read address209are module locations requested to be monitored. Address monitor212specifies whether the address211is a module location requested to be monitored. If address monitor212is asserted (or true), then the address provided is a monitored address. In an embodiment, if ‘monitor on’ input204is true and there is no CPU access to module106,110, the different monitored address busses208,209are constantly updated with the contents of their respective monitored address registers301,302.

RNWR signal213specifies whether a particular CPU signal provided address (specified in conjunction with address monitor212and read monitor210) is a read and not a write signal for a particular module location. Slave request214specifies whether a particular access of module106is a CPU-based access (if asserted or true)

We turn now to the input signals received by register slave104from module106. First read data input218and second read data input219are respectively the upper half-word and the lower half-word of the data stored at 1 or 2 specific module location(s) in module106as specified by the addresses transmitted from the register slave. First read data input218and second read data input219are subsequently provided by register slave104to monitor channel bus126and monitor channel bus128. Module106transmits acknowledgement input220to register slave104in response to a CPU access of a specific location of a module106by the register slave. Module106transmits a monitor lower valid input221and a monitor upper valid input222to indicate the validity of monitored data provided to register slave104via first read data input218and second read data input219. For example, if data provided by module106via first read data input218and second read data input219is provided in response to a CPU-based access of the module, then each of the monitor lower valid input221and monitor upper valid input222is not asserted or set to indicate false.

The configuration of signals specified in each of the options1-5ofFIG. 2enables the CPU reading and writing of data to a specified address of module106while preserving the ability to monitor the data at an address in the module. Register slave104operates independent of the particular implementation (options1-5) of module106and passes along data (received via first read data218and/or second read data219), acknowledgement input220and monitor validity (monitor lower valid input221and monitor upper valid input222).

If register slave104is monitoring a particular module106address, one or both of first and second monitor channel buses126,128provide the contents of the monitored module address(es) to monitor module116. In order for register slave104to be monitoring1or2module locations, first the 2 address registers up302and low301must be set-up appropriately by a CPU write of information to the registers, then CPU CAD input206asserts ‘monitor on’ input204(or true) to register slave104. Responsive to receiving the signal monitor on input204true, register slave104asserts slave read monitor signal210, address monitor212, and provides the address to monitored upper read address208, lower read address209, and address211.

If register slave104is monitoring a particular module106address and the CPU attempts to perform a read from module106, the register slave halts monitoring and presents the CPU-based read address to the module. Further specifically, register slave104deasserts slave read monitor signal210, address monitor212, asserts RNWR signal213, slave request214, and provides the CPU-based address to upper read address208, lower read address209, and address211. After reading of the CPU-based address is complete, register slave104resumes monitoring as described above.

With respect to each of the options depicted inFIG. 2, unless specified by a not connected (NC) symbol in the particular option column the module supports the reading and/or writing of the corresponding signals to/from register slave104. The “same” symbol with respect to options1,2, and3indicates that the same signal is transmitted from module106to register slave104.

FIG. 3depicts the interaction between register slave104and module106according to the first option ofFIG. 2. The first option is a single address read/write bus implementation of module106. As depicted inFIG. 3, module106includes an address decoder receiving and decoding address signal, e.g., slv_addr[27:2]211, from register slave104. In an embodiment, controls line is used to transfer address monitor, e.g., slv_addr_mon212, RNWR, e.g., slv_mwr signal213, and slave request, e.g., slv_req214(FIG. 2) from register slave104to module106and to transfer acknowledgement input, e.g., slv_ack220, monitor lower valid input, e.g., mon_dlo_valid221, and monitor upper valid input, e.g., mon_dup_valid222, from the module to the register slave. Slave read data, e.g., slv_rd_data[31:16]218and slv_rd_data[15:0]219signals are transferred from module106to register slave104.

FIG. 4depicts the interaction between register slave104and module106according to the second option ofFIG. 2. The implementation of module106according to the second option includes two independent address read bus and address write bus interfaces. As depicted inFIG. 4, module106includes separate read and write decoders such that the write decoder receives address signal, e.g., slv_addr[27:2]211and the read decoder receives lower read address, e.g., slv_read_lo_addr[27:2]209from register slave104. In an embodiment, controls line is used to transfer slave read monitor signal, e.g., slv_read_mon210, RNWR signal, e.g., slv_mwr213, and slave request, e.g., slv_req214(FIG. 2) from register slave104to module106and to transfer acknowledgement input, e.g., slv_ack220, monitor lower valid input, e.g., mon_dlo_valid221, and monitor upper valid input, e.g., mon_dup_valid222from the module to the register slave.

FIG. 5depicts the interaction between register slave104and module106according to the third option ofFIG. 2. The implementation of module106according to the third option includes a split read data bus having two independent read address bus interfaces. As depicted inFIG. 5, module106includes not only separate read and write decoders, but the read decoder is further divided into separate upper and lower read decoders. Lower read decoder receives lower read address209and upper read decoder receives upper read address208from register slave104. Additionally, according to theFIG. 5embodiment, first read data input, e.g., slv_rd_data[31:16]218and second read data input, e.g., slv_rd_data[15:0]219are used to provide data read from module106to register slave104. In an embodiment, controls line is used to transfer slave read monitor signal, e.g., slv_read_mon210, RNWR signal, e.g., slv_mwr213, and slave request, e.g., slv_req214(FIG. 2) from register slave104to module106and to transfer acknowledgement input, e.g., slv_ack220, monitor lower valid input, e.g., mon_dlo_valid221, and monitor upper valid input, e.g., mon_dup_valid222from the module to the register slave.

FIG. 6depicts the interaction between register slave104and module106according to the fourth option ofFIG. 2. The implementation of module106according to the fourth option includes a non-writable memory having a single address read bus interface. As depicted inFIG. 6, module106includes a single read decoder receiving lower read address, e.g., slv_read_dlo_addr[27:2]209from register slave104. In an embodiment, controls line is used to transfer slave read monitor signal, e.g., slv_read_mon210, RNWR signal, e.g., slvmmwr213, and slave request, e.g., slv_req214(FIG. 2) from register slave104to module106and to transfer acknowledgement input, e.g., slv_ack220, monitor lower valid input, e.g., mon_dlo_valid221, and monitor upper valid input, e.g., mon_dup_valid222from the module to the register slave.

FIG. 7depicts the interaction between register slave104and module106according to the fifth option ofFIG. 2. The implementation of module106according to the fifth option includes a non-writable memory having a split read data bus with two independent address read buses. As depicted inFIG. 7, module106includes separate upper and lower read decoders receiving upper read address, e.g., slv_read_dup_addr[27:2]208and lower read address, e.g., slv_read_dlo_addr[27:2]209, respectively. Module106provides data to register slave104via first read data input218and second read data input219. In an embodiment, controls line is used to transfer slave read monitor signal, e.g., slv_read_mon210, RNWR signal, e.g., slv_mwr213, and slave request, e.g., slv_req214(FIG. 2) from register slave104to module106and to transfer acknowledgement input, e.g., slv_ack220, monitor lower valid input, e.g., mon_dlo_valid221, and monitor upper valid input, e.g., mon_dup_valid222from the module to the register slave.

FIGS. 8 and 9depict high-level logic diagrams of the determination of address and data transmissions from register slave104to module106. With particular reference toFIG. 8, multiplex monitor read signal800specifies a CPU-based read access of module106. Multiplex monitor RDWRT signal802specifies a CPU-based read/write access of module106. Multiplex monitor read signal800determines whether monitored data, e.g., specified by an address stored in mon_add_up_jeg302, or a CPU-based memory location read data, e.g., cpu_addr_reg300, is transferred via multiplexer804from register slave104, e.g., via slv_read_dup_addr208, and similarly with respect to multiplexer806with respect to mon_add_lo_reg301and cpu_addr_reg300. Multiplex monitor RDWRT signal802controls multiplexer808to determine whether to transfer monitored data, e.g., specified by an address stored in mon_add_lo_reg301, or a CPU-based memory location read data, e.g., cpu_addr_reg300, via slv_addr signal211.

FIG. 9. depicts signaling used in transferring data via register slave104to the first and second channel monitor buses126,128. In particular, the slv_ack signal (acknowledgement input220ofFIG. 2from module106) indicates that read data on the read data bus, e.g., slv_rd_data[31:16]218and slv_rd_data[15:0]219, matches the requested CPU-based memory read location. When monitoring is active the mon_dup_valid (upper monitor valid input222ofFIG. 2) is high (asserted) for the upper half word of data including valid monitor data, e.g., slv_rd_data[31:16]218and respectively the mon_dlo_valid (lower monitor valid input221ofFIG. 2) is high (asserted) for the lower half-word of data including valid monitor data, e.g., slv_rd_data[15:0]219.

Up_on_channel_1900and up_on_channel_2901are stored in a control register in register slave104and are used to determine which channel, i.e., channel_1and channel_2corresponding to first and second monitor channel buses126and128, the data is passed on.

In conjunction with up_on_channel_1900and up_on_channel_2901, channel_1on902and channel_2on903specify the active register_slave104,108,112for daisy chaining of information transmitted along the channels.

FIG. 10depicts the flexibility of the register slave interface described above. In particular as depicted inFIG. 10, the register slave is able to interface to a module which is a composite of multiple sub-modules. e.g., multiple heterogeneous moduls/sub-modules. The signals depicted as traversing the interface between register slave104and module106are as described above with respect toFIG. 2.

It will be readily seen by one of ordinary skill in the art that the embodiments fulfills one or more of the advantages set forth above. After reading the foregoing specification, one of ordinary skill will be able to affect various changes, substitutions of equivalents and various other aspects of the embodiments as broadly disclosed herein. It is therefore intended that the protection granted hereon be limited only by the definition contained in the appended claims and equivalents thereof.