Microprogrammable SDRAM memory interface controller

TECHNICAL FIELD

The present invention relates, in general, to synchronous dynamic random access memory (SDRAM) and, more specifically, to an SDRAM controller that is microprogrammable.

BACKGROUND OF THE INVENTION

SDRAM is a generic name for various kinds of dynamic random access memories (DRAM) that are synchronized with the clock speed of a microprocessor. In this manner, an SDRAM increases the number of instructions that the microprocessor may perform in a given time.

Typically, SDRAMs are fabricated as separate integrated circuits from other system components. The SDRAMs, microprocessor, and other components of the system are interconnected via a system bus. An SDRAM controller, which is placed between the system bus and the SDRAM, facilitates communication between the microprocessor and the SDRAM, and controls the functioning of the SDRAM. Many of the SDRAM controllers are application specific integrated circuits (ASICs), each providing specific functionality for a predetermined SDRAM.

The memory in the SDRAM is organized in banks. Typically, the number of memory banks may range from 2 to 16, or more. Corresponding to each of these SDRAM banks, there is a memory request queue in the SDRAM controller. A memory request basically involves a row address strobe (RAS) command and a column address strobe (CAS) command for accessing data in a memory bank. The controller has a request scheduler and a RAS/CAS generator which processes requests for all the memory banks in an orderly and timely manner. To control the operation of an SDRAM, the controller may use standard signals, such as address, row address select (RAS), column address select (CAS), write enable (WE), and data input/output mask (DQM) assertions.

The controller, typically, may handle multiple requests from different requestors, such as multiple processors. The controller may arbitrate among these different requestors and grant service (reading data from or writing data to a memory bank) to each requestor in an orderly manner.

In an SDRAM, when a row address and a column address of the initial data have been specified, subsequent addresses are automatically generated to output data in succession synchronously to a clock. The number of data (burst length) provided in succession may be selected by a number, such as 2, 4, or 8. In a burst mode for data accesses synchronously to the clock, data may be read out at a higher speed, since data are accessible per clock.

Because SDRAM memory cells are capacitive, the charge they contain dissipates with time. As the charge is lost, so is the data in the memory cells. To prevent this from happening, an SDRAM must be refreshed. This is done by periodically restoring the charge on the individual memory cells. In addition, the SDRAM may use a feature called auto pre-charge, which allows the memory chip circuitry to close a page automatically at the end of a burst. Auto pre-charge may be used, because the burst transfers are of a fixed length, and the end time of the transfers is known.

Long lead times are typically required to develop and manufacture a custom device, such as an SDRAM controller. Moreover, by the time the SDRAM controller is commercially available, new features may be introduced into the SDRAM, thereby necessitating another design and development of the SDRAM controller and causing more expense. Furthermore, in a multiple requestor environment, the requirement of each requestor for accessing data may change, thereby necessitating yet another design and development phase and causing even more expense.

A need arises, therefore, for a controller that may be used in an application/project and reused in another application/project, without having to undergo an expensive design and development phase. A need also arises for a controller that may accommodate changing needs of a data requestor, as well as the addition or deletion of a data requestor. This invention addresses such needs.

SUMMARY OF THE INVENTION

To meet this and other needs, and in view of its purposes, the present invention provides a programmable synchronous dynamic random access memory (SDRAM) controller including an arbitration unit for receiving service requests from multiple requestors to access an SDRAM, and a lookup table of identifiers corresponding to the multiple requestors, in which the identifiers are stored in a sequence of addresses. The arbitration unit is configured to sequentially access each address in the sequence of addresses, and grant service to a requestor, based on an identifier stored in an address accessed.

In another embodiment, the present invention provides an SDRAM controller including a service unit for receiving a service request from at least one requestor to access an SDRAM and perform an SDRAM transaction; a memory for storing instructions at various addresses of the memory, the instructions used for performing a plurality of SDRAM transactions; and a lookup table of a sequence of addresses corresponding to at least a portion of the instructions stored in the memory, the portion of the instructions defining the SDRAM transaction. The service unit is configured to execute the SDRAM transaction based on the sequence of addresses in the lookup table. The SDRAM controller may also include a service unit for receiving service requests from multiple requestors to access the SDRAM, and another lookup table of identifiers corresponding to the multiple requestors, the identifiers stored in another sequence of addresses. The service unit is configured to sequentially access each address in the other sequence of addresses, and grant service to a requestor based on an identifier stored in an address accessed.

In yet another embodiment, the invention provides a method of controlling access to an SDRAM. The method includes the steps of: (a) receiving service requests from multiple requestors to access the SDRAM; (b) storing a sequence of identifiers in a lookup table, the identifiers corresponding to the multiple requestors; (c) sequentially accessing the sequence of identifiers in the lookup table; and (d) granting a requestor access to the SDRAM based on an identifier accessed in the sequence of identifiers.

In still another embodiment, the invention provides a method of controlling access to an SDRAM. The method includes the steps of: (a) receiving a service request from at least one requestor to access the SDRAM and perform an SDRAM transaction; (b) storing, in a first memory, instructions at various addresses, the instructions used for performing a plurality of SDRAM transactions; (c) storing, in a second memory, a sequence of addresses corresponding to at least a portion of the instructions stored in the first memory, the sequence of addresses defining the SDRAM transaction; and (d) executing the SDRAM transaction based on the sequence of addresses stored in the second memory.

In a further embodiment, the invention provides a method of programming an SDRAM controller. The method includes the steps of: (a) identifying a plurality of requestors to access the SDRAM, wherein each of the requestors is configured to perform a sequence of instructions; (b) storing, in a first memory, a plurality of instructions for controlling the SDRAM, each instruction stored at a different address in the first memory; (c) storing, in a second memory, a plurality of sequences of addresses, each sequence of addresses corresponding to a sequence of instructions stored in the first memory; and (d) performing a sequence of instructions for a requestor by using a sequence of addresses stored in the second memory to execute a corresponding sequence of instructions stored in the first memory.

It is understood that the foregoing general description and the following detailed description are exemplary, but are not restrictive, of the invention.

BRIEF DESCRIPTION OF THE DRAWING

The invention is best understood from the following detailed description when read in connection with the accompanying drawing. Included in the drawing are the following figures:

<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram of a processing system incorporating a microprogrammable SDRAM controller, in accordance with an embodiment of the invention;

<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram of a microprogrammable SDRAM controller, in accordance with an embodiment of the invention;

<figref idref="DRAWINGS">FIG. 3</figref> is a flow diagram depicting a method used by a microprogrammable SDRAM controller, in accordance with an embodiment of the invention;

<figref idref="DRAWINGS">FIG. 4</figref> is a block diagram of a service arbitration unit (SAU) incorporated into the microprogrammable SDRAM controller of <figref idref="DRAWINGS">FIG. 2</figref>, in accordance with an embodiment of the invention; and

<figref idref="DRAWINGS">FIG. 5</figref> is a block diagram of an instruction execution unit (IEU) incorporated into the microprogrammable SDRAM controller of <figref idref="DRAWINGS">FIG. 2</figref>, in accordance with an embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

In accordance with the present invention, a microprogrammable SDRAM memory interface controller is provided. The microprogrammable features of the invention provide flexibility for using the controller across multiple applications or projects, thereby reducing or eliminating a need for hardware redesign. The present invention may advantageously be used in applications or projects that have uncertain requirements or are subject to future revision and enhancement.

Referring to <figref idref="DRAWINGS">FIG. 1</figref>, there is shown a processing system, generally designated as <b>10</b>, in accordance with an embodiment of the present invention. Processing system <b>10</b> includes microprogrammable SDRAM controller <b>20</b> coupled between multiple memory requestors (generally designated as <b>11</b> to <b>14</b>) and SDRAM memory <b>16</b>. In a typical embodiment, microprocessor <b>15</b> may also be coupled to microprogrammable controller <b>20</b>.

Microprocessor <b>15</b> may be, for example, an Intel processor. As will be explained, microprocessor <b>15</b> may be used to store various instructions into SDRAM controller <b>20</b> and be programmed to execute specific instructions for reading/writing from/to the SDRAM memory for each memory requestor. Microprocessor <b>15</b> may also be used to store access priorities into the SDRAM controller for the requestors, so that SDRAM controller <b>20</b> may arbitrate among the multiple requestors for access to the SDRAM memory.

It will be appreciated that memory requestors <b>11</b> through <b>14</b> and SDRAM memory <b>16</b>, as well as microprocessor <b>15</b>, are not necessarily physically in proximity to SDRAM controller <b>20</b>.

Referring next to <figref idref="DRAWINGS">FIG. 2</figref>, there is shown SDRAM controller <b>20</b> in accordance with an embodiment of the present invention. SDRAM controller <b>20</b> includes the service arbitration unit (SAU), which is generally designated as <b>23</b>, and is coupled between the programmable instruction sequence unit (PISU), generally designated as <b>21</b>, and the programmable arbitration schedule unit (PASU), generally designated as <b>26</b>. Also included are the programmable instruction memory unit (PIMU), generally designated as <b>22</b>, which is coupled between PISU <b>21</b> and the instruction execution unit (IEU), generally designated as <b>24</b>. SDRAM controller <b>20</b> further includes the external interface unit (EIU), generally designated as <b>25</b>, and the write data selection unit (WDSU), generally designated as <b>27</b>, both coupled to IEU <b>24</b>.

SAU <b>23</b> is configured to receive service requests from one or more requestors by way of the service request lines (only one shown). A service request may arrive one at a time, or multiple requests may arrive concurrently. As will be explained, the SAU arbitrates among the requestors and grants access to one and only one of the requestors at any given time. Access may be granted based on a programmable schedule that establishes priorities among the service requestors.

PASU <b>26</b> provides the schedule to the SAU in the form of a lookup table stored in memory. An example of a lookup table, which may be externally programmed by a user, is shown in Table 1. As shown, the table includes 16 addresses and each address includes a corresponding priority service ID. It will be appreciated that each service ID (A–R are shown) may be, but does not have to be, a different requestor. Accordingly, up to 16 different requestors may be programmed into the schedule shown in table 1. For example, at address 0, requestor A has the highest priority, at address 1, requestor B has the highest priority, and so on.

<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 1</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>programmable schedule as a lookup table, stored in PASU</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="42pt" align="center" /><colspec colname="2" colwidth="147pt" align="center" /><tbody valign="top"><row><entry /><entry>ADDRESS</entry><entry>PRIORITY SERVICE ID</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="42pt" align="char" char="." /><colspec colname="2" colwidth="147pt" align="center" /><tbody valign="top"><row><entry /><entry>0</entry><entry>A</entry></row><row><entry /><entry>1</entry><entry>B</entry></row><row><entry /><entry>2</entry><entry>C</entry></row><row><entry /><entry>3</entry><entry>D</entry></row><row><entry /><entry>4</entry><entry>E</entry></row><row><entry /><entry>5</entry><entry>F</entry></row><row><entry /><entry>6</entry><entry>G</entry></row><row><entry /><entry>7</entry><entry>H</entry></row><row><entry /><entry>8</entry><entry>J</entry></row><row><entry /><entry>9</entry><entry>K</entry></row><row><entry /><entry>10</entry><entry>L</entry></row><row><entry /><entry>11</entry><entry>M</entry></row><row><entry /><entry>12</entry><entry>N</entry></row><row><entry /><entry>13</entry><entry>P</entry></row><row><entry /><entry>14</entry><entry>Q</entry></row><row><entry /><entry>15</entry><entry>R</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

In operation, the SAU addresses the PASU lookup table in sequence. Thus, at time zero, the address points to address zero. At address zero, requestor A has the highest priority. Addressing the PASU lookup table with an address of zero, the SAU is informed that requestor A has the highest priority. If multiple requestors, for example A and B, concurrently request service, A is granted the service by the SAU. After A is granted service and completes reading or writing data from/to the SDRAM, the SAU addresses the PASU lookup table with the next address, namely address 1. The SAU is then informed that requestor B has the highest priority. If multiple requestors request service, while the SAU is addressing address 1, requestor B is granted the service. After requestor B completes execution, the address is incremented to the next address, namely address 2 in the table. If requestor C requests service simultaneously with other requestors, requestor C with the highest priority service ID is granted the service request. Accordingly, the input and output operation, as shown in Table 2, between the SAU and the PASU, may be considered as sequencing through a sequence of addresses, or moving down a schedule, beginning at address O and ending at address 15.

<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 2</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Input/output operation between the SAU and the PASU</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="42pt" align="center" /><colspec colname="2" colwidth="126pt" align="center" /><tbody valign="top"><row><entry /><entry>INPUT</entry><entry>OUTPUT</entry></row><row><entry /><entry>SCHEDULE</entry><entry>PRIORITY</entry></row><row><entry /><entry>ADDRESS</entry><entry>SERVICE</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="42pt" align="char" char="." /><colspec colname="2" colwidth="126pt" align="center" /><tbody valign="top"><row><entry /><entry>0</entry><entry>A</entry></row><row><entry /><entry>1</entry><entry>B</entry></row><row><entry /><entry>2</entry><entry>C</entry></row><row><entry /><entry>3</entry><entry>D</entry></row><row><entry /><entry>4</entry><entry>E</entry></row><row><entry /><entry>5</entry><entry>F</entry></row><row><entry /><entry>6</entry><entry>G</entry></row><row><entry /><entry>7</entry><entry>H</entry></row><row><entry /><entry>8</entry><entry>J</entry></row><row><entry /><entry>9</entry><entry>K</entry></row><row><entry /><entry>10</entry><entry>L</entry></row><row><entry /><entry>11</entry><entry>M</entry></row><row><entry /><entry>12</entry><entry>N</entry></row><row><entry /><entry>13</entry><entry>P</entry></row><row><entry /><entry>14</entry><entry>Q</entry></row><row><entry /><entry>15</entry><entry>R</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

It will be appreciated that in a situation where the input address is pointing to address 0, and requestor A is inactive but other requestors are requesting service, the SAU may invoke a rule to determine who should be granted the service. The rule may be, for example, that priority is granted to a least recently used (LRU) requestor among the remaining service requestors.

In an embodiment contemplated by the invention, the priority service ID value of table 1 is programmable. The schedule address sequence of table 2 is fixed and advances in sequence upon the SAU completing a service for a requestor, by using a priority service acknowledge. The priority service IDs, however, may be programmed in any manner desirable by a user. Moreover, if the priority service request for a requestor at a corresponding address is inactive, priority may follow a LRU rule among the remaining service requestors.

Since the priority service ID shown in table 1 is programmable, it will be appreciated that requestor A, for example, may be granted a higher percentage of service requests than other requestors (for example B, C, D and E) by inserting into table 1 mostly “A” priority IDs. Thus, the sequence in table 1 may be programmed, for example, as “A,A,A,A,B,C,D,E”. Similarly, requestor B may be starved, or provided no access, by omitting B from the table. Accordingly, the amount of resource provided each requestor may be manipulated by changing the priority service IDs in table 1. (Of course, if table 1 is changed, the content of table 2 is correspondingly changed.)

Similar to PASU <b>26</b>, PISU <b>21</b> is a programmable unit that provides an array of sequences in a lookup table, stored in memory. As shown in table 3, each service ID (or requestor) has a unique group of 16 position codes that are used to select 16 addresses in PIMU <b>22</b>. Thus, requestor A has programmable position codes A₀–A₁₅, requestor B has programmable position codes B₀–B₁₅, and so on.

<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="280pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 3</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Programmable sequence as a lookup table stored in the PISU</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="266pt" align="center" /><tbody valign="top"><row><entry /><entry>POSITION CODE</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="17"><colspec colname="1" colwidth="14pt" align="center" /><colspec colname="2" colwidth="14pt" align="left" /><colspec colname="3" colwidth="14pt" align="left" /><colspec colname="4" colwidth="14pt" align="left" /><colspec colname="5" colwidth="14pt" align="left" /><colspec colname="6" colwidth="14pt" align="left" /><colspec colname="7" colwidth="14pt" align="left" /><colspec colname="8" colwidth="14pt" align="left" /><colspec colname="9" colwidth="14pt" align="left" /><colspec colname="10" colwidth="14pt" align="left" /><colspec colname="11" colwidth="14pt" align="left" /><colspec colname="12" colwidth="21pt" align="left" /><colspec colname="13" colwidth="21pt" align="left" /><colspec colname="14" colwidth="21pt" align="left" /><colspec colname="15" colwidth="21pt" align="left" /><colspec colname="16" colwidth="21pt" align="left" /><colspec colname="17" colwidth="21pt" align="left" /><tbody valign="top"><row><entry>ID</entry><entry>0</entry><entry>1</entry><entry>2</entry><entry>3</entry><entry>4</entry><entry>5</entry><entry>6</entry><entry>7</entry><entry>8</entry><entry>9</entry><entry>10</entry><entry>11</entry><entry>12</entry><entry>13</entry><entry>14</entry><entry>15</entry></row><row><entry namest="1" nameend="17" align="center" rowsep="1" /></row><row><entry>A</entry><entry>A0</entry><entry>A1</entry><entry>A2</entry><entry>A3</entry><entry>A4</entry><entry>A5</entry><entry>A6</entry><entry>A7</entry><entry>A8</entry><entry>A9</entry><entry>A10</entry><entry>A11</entry><entry>A12</entry><entry>A13</entry><entry>A14</entry><entry>A14</entry></row><row><entry>B</entry><entry>B0</entry><entry>B1</entry><entry>B2</entry><entry>B3</entry><entry>B4</entry><entry>B5</entry><entry>B6</entry><entry>B7</entry><entry>B8</entry><entry>B9</entry><entry>B10</entry><entry>B11</entry><entry>B12</entry><entry>B13</entry><entry>B14</entry><entry>B15</entry></row><row><entry>C</entry><entry>C0</entry><entry>C1</entry><entry>C2</entry><entry>C3</entry><entry>C4</entry><entry>C5</entry><entry>C6</entry><entry>C7</entry><entry>C8</entry><entry>C9</entry><entry>C10</entry><entry>C11</entry><entry>C12</entry><entry>C13</entry><entry>C14</entry><entry>C15</entry></row><row><entry>D</entry><entry>D0</entry><entry>D1</entry><entry>D2</entry><entry>D3</entry><entry>D4</entry><entry>D5</entry><entry>D6</entry><entry>D7</entry><entry>D8</entry><entry>D9</entry><entry>D10</entry><entry>D11</entry><entry>D12</entry><entry>D13</entry><entry>D14</entry><entry>D15</entry></row><row><entry>E</entry><entry>E0</entry><entry>E1</entry><entry>E2</entry><entry>E3</entry><entry>E4</entry><entry>E5</entry><entry>E6</entry><entry>E7</entry><entry>E8</entry><entry>E9</entry><entry>E10</entry><entry>E11</entry><entry>E12</entry><entry>E13</entry><entry>E14</entry><entry>E15</entry></row><row><entry>F</entry><entry>F0</entry><entry>F1</entry><entry>F2</entry><entry>F3</entry><entry>F4</entry><entry>F5</entry><entry>F6</entry><entry>F7</entry><entry>F8</entry><entry>F9</entry><entry>F10</entry><entry>F11</entry><entry>F12</entry><entry>F13</entry><entry>F14</entry><entry>F15</entry></row><row><entry>G</entry><entry>G0</entry><entry>G1</entry><entry>G2</entry><entry>G3</entry><entry>G4</entry><entry>G5</entry><entry>G6</entry><entry>G7</entry><entry>G8</entry><entry>G9</entry><entry>G10</entry><entry>G11</entry><entry>G12</entry><entry>G13</entry><entry>G14</entry><entry>G15</entry></row><row><entry>H</entry><entry>H0</entry><entry>H1</entry><entry>H2</entry><entry>H3</entry><entry>H4</entry><entry>H5</entry><entry>H6</entry><entry>H7</entry><entry>H8</entry><entry>H9</entry><entry>H10</entry><entry>H11</entry><entry>H12</entry><entry>H13</entry><entry>H14</entry><entry>H15</entry></row><row><entry>J</entry><entry>J0</entry><entry>J1</entry><entry>J2</entry><entry>J3</entry><entry>J4</entry><entry>J5</entry><entry>J6</entry><entry>J7</entry><entry>J8</entry><entry>J9</entry><entry>J10</entry><entry>J11</entry><entry>J12</entry><entry>J13</entry><entry>J14</entry><entry>J15</entry></row><row><entry>K</entry><entry>K0</entry><entry>K1</entry><entry>K2</entry><entry>K3</entry><entry>K4</entry><entry>K5</entry><entry>K6</entry><entry>K7</entry><entry>K8</entry><entry>K9</entry><entry>K10</entry><entry>K11</entry><entry>K12</entry><entry>K13</entry><entry>K14</entry><entry>K15</entry></row><row><entry>L</entry><entry>L0</entry><entry>L1</entry><entry>L2</entry><entry>L3</entry><entry>L4</entry><entry>L5</entry><entry>L6</entry><entry>L7</entry><entry>L8</entry><entry>L9</entry><entry>L10</entry><entry>L11</entry><entry>L12</entry><entry>L13</entry><entry>L14</entry><entry>L15</entry></row><row><entry>M</entry><entry>M0</entry><entry>M1</entry><entry>M2</entry><entry>M3</entry><entry>M4</entry><entry>M5</entry><entry>M6</entry><entry>M7</entry><entry>M8</entry><entry>M9</entry><entry>M10</entry><entry>M11</entry><entry>M12</entry><entry>M13</entry><entry>M14</entry><entry>M15</entry></row><row><entry>N</entry><entry>N0</entry><entry>N1</entry><entry>N2</entry><entry>N3</entry><entry>N4</entry><entry>N5</entry><entry>N6</entry><entry>N7</entry><entry>N8</entry><entry>N9</entry><entry>N10</entry><entry>N11</entry><entry>N12</entry><entry>N13</entry><entry>N14</entry><entry>N15</entry></row><row><entry>P</entry><entry>P0</entry><entry>P1</entry><entry>P2</entry><entry>P3</entry><entry>P4</entry><entry>P5</entry><entry>P6</entry><entry>P7</entry><entry>P8</entry><entry>P9</entry><entry>P10</entry><entry>P11</entry><entry>P12</entry><entry>P13</entry><entry>P14</entry><entry>P15</entry></row><row><entry>Q</entry><entry>Q0</entry><entry>Q1</entry><entry>Q2</entry><entry>Q3</entry><entry>Q4</entry><entry>Q5</entry><entry>Q6</entry><entry>Q7</entry><entry>Q8</entry><entry>Q9</entry><entry>Q10</entry><entry>Q11</entry><entry>Q12</entry><entry>Q13</entry><entry>Q14</entry><entry>Q15</entry></row><row><entry>R</entry><entry>R0</entry><entry>R1</entry><entry>R2</entry><entry>R3</entry><entry>R4</entry><entry>R5</entry><entry>R6</entry><entry>R7</entry><entry>R8</entry><entry>R9</entry><entry>R10</entry><entry>R11</entry><entry>R12</entry><entry>R13</entry><entry>R14</entry><entry>R15</entry></row><row><entry namest="1" nameend="17" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

As will be explained, each position code is an address in PIMU <b>22</b> that points to an instruction. Accordingly, up to 16 different instructions may be addressed by the PISU for each requestor. Although in the embodiment shown 16 different instructions may be programmed for each requestor, it will be appreciated that fewer instructions may generally be used. For example, requestor A may require position codes A₀–A₆(seven instructions), requestor B may require position codes B₀–B₃(four instructions), and so on.

Furthermore, position code A₀and position code B₀, for example, may point to an address containing a single instruction in PIMU <b>22</b>, or may point to different addresses containing different instructions in PIMU <b>22</b>. In this manner, the number of instructions stored in PIMU <b>22</b> may be reduced, since only different instructions need to be stored in the PIMU. The position codes of each requestor may be dynamically adapted to string together any set of instructions that are stored in PIMU <b>22</b>. In this manner, the invention provides a set of position codes that are tailored to the needs of each requestor and advantageously allows the user to uniquely program any particular service requested by a requestor.

Referring next to table 4, there is shown the input/output operation provided from the SAU, via the PISU, to the PIMU. For each service ID (or requestor), the SAU provides the PISU a sequence of position codes as inputs and, in turn, the PISU provides a sequence of addresses (for example A₀–A₁₅) as outputs to the PIMU. If requestor B, for example, is being serviced by the SAU, then service ID “B” and position codes B₀–B₁₅(for example) are sequentially provided to PIMU <b>22</b>. In this manner, requestor B may execute its own set of instructions to read/write data to/from the SDRAM. Each of position codes B₀–B₁₅is an address in the memory of PIMU <b>22</b>. As already discussed, another requestor, for example C, may have position codes C₀–C₁₅, which may be addresses in the PIMU that are identical to the addresses pointed to by B₀–B₁₅, respectively. In such circumstance, requestor C may be programmed to have an identical sequence of instructions as requestor B (for example).

In an embodiment of the invention, the sequence of position codes for a requestor may be used to select a unique group or set of 16 PIMU addresses. The PIMU address values are programmable. The first position code of a PISU sequence is always zero and the last position code of a PISU sequence may be programmed. The last position code of a PISU sequence may be determined by an end code value.

The position code may be incremented to the next position code by the SAU, upon generation of an execution request from the SAU to IEU <b>24</b>, as shown in <figref idref="DRAWINGS">FIG. 2</figref>. The IEU may perform an SDRAM transaction, defined as an execution of a sequence of position codes, which, in turn, is a sequence of PIMU addresses, shown in table 4, that select a sequence of PIMU instructions.

<tables id="TABLE-US-00004" num="00004"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 4</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Input/output operation of the PISU</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="119pt" align="center" /><colspec colname="2" colwidth="21pt" align="center" /><colspec colname="3" colwidth="63pt" align="left" /><tbody valign="top"><row><entry /><entry>INPUT</entry><entry /><entry>OUTPUT</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="35pt" align="center" /><colspec colname="2" colwidth="105pt" align="center" /><colspec colname="3" colwidth="63pt" align="left" /><tbody valign="top"><row><entry /><entry>SERVICE</entry><entry>SEQUENCE</entry><entry>PIMU</entry></row><row><entry /><entry>ID</entry><entry>POSITION CODE</entry><entry>ADDRESS</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="35pt" align="center" /><colspec colname="2" colwidth="105pt" align="char" char="." /><colspec colname="3" colwidth="63pt" align="left" /><tbody valign="top"><row><entry /><entry>A</entry><entry>0</entry><entry>A0</entry></row><row><entry /><entry /><entry>1</entry><entry>A1</entry></row><row><entry /><entry /><entry>2</entry><entry>A2</entry></row><row><entry /><entry /><entry>3</entry><entry>A3</entry></row><row><entry /><entry /><entry>4</entry><entry>A4</entry></row><row><entry /><entry /><entry>5</entry><entry>A5</entry></row><row><entry /><entry /><entry>6</entry><entry>A6</entry></row><row><entry /><entry /><entry>7</entry><entry>A7</entry></row><row><entry /><entry /><entry>8</entry><entry>A8</entry></row><row><entry /><entry /><entry>9</entry><entry>A9</entry></row><row><entry /><entry /><entry>10</entry><entry>A10</entry></row><row><entry /><entry /><entry>11</entry><entry>A11</entry></row><row><entry /><entry /><entry>12</entry><entry>A12</entry></row><row><entry /><entry /><entry>13</entry><entry>A13</entry></row><row><entry /><entry /><entry>14</entry><entry>A14</entry></row><row><entry /><entry /><entry>15</entry><entry>A15</entry></row><row><entry /><entry>B</entry><entry>0</entry><entry>B0</entry></row><row><entry /><entry /><entry>1</entry><entry>B1</entry></row><row><entry /><entry /><entry>2</entry><entry>B2</entry></row><row><entry /><entry /><entry>3</entry><entry>B3</entry></row><row><entry /><entry /><entry>4</entry><entry>B4</entry></row><row><entry /><entry /><entry>5</entry><entry>B5</entry></row><row><entry /><entry /><entry>6</entry><entry>B6</entry></row><row><entry /><entry /><entry>7</entry><entry>B7</entry></row><row><entry /><entry /><entry>.</entry></row><row><entry /><entry /><entry>.</entry></row><row><entry /><entry /><entry>.</entry></row><row><entry /><entry>R</entry><entry>8</entry><entry>R8</entry></row><row><entry /><entry /><entry>9</entry><entry>R9</entry></row><row><entry /><entry /><entry>10</entry><entry>R10</entry></row><row><entry /><entry /><entry>11</entry><entry>R11</entry></row><row><entry /><entry /><entry>12</entry><entry>R12</entry></row><row><entry /><entry /><entry>13</entry><entry>R13</entry></row><row><entry /><entry /><entry>14</entry><entry>R14</entry></row><row><entry /><entry /><entry>15</entry><entry>R15</entry></row><row><entry /><entry namest="offset" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

Similar to the PISU, PIMU <b>22</b> is a programmable lookup table stored in a memory. As shown in Table 5, PIMU <b>22</b> includes 32 addresses each storing an output instruction. For example, address 0 includes instructions I₀, address 1 includes instruction I₁, address 2 includes instruction I₂, and so on. Although the embodiment of table 5 shows 32 instructions, the invention may be expanded to include more memory for an increased number of instructions. It will be appreciated, however, that typically an SDRAM transaction is a sequence of no more than 9 instructions (based on a set of instructions as shown, for example, in table 9).

<tables id="TABLE-US-00005" num="00005"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 5</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Programmable instructions in a lookup table stored in the PIMU</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="35pt" align="left" /><colspec colname="1" colwidth="42pt" align="center" /><colspec colname="2" colwidth="140pt" align="center" /><tbody valign="top"><row><entry /><entry>INPUT</entry><entry>OUTPUT</entry></row><row><entry /><entry>ADDRESS</entry><entry>INSTRUCTION</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="35pt" align="left" /><colspec colname="1" colwidth="42pt" align="char" char="." /><colspec colname="2" colwidth="140pt" align="center" /><tbody valign="top"><row><entry /><entry>0</entry><entry>I0 </entry></row><row><entry /><entry>1</entry><entry>I1 </entry></row><row><entry /><entry>2</entry><entry>I2 </entry></row><row><entry /><entry>3</entry><entry>I3 </entry></row><row><entry /><entry>4</entry><entry>I4 </entry></row><row><entry /><entry>5</entry><entry>I5 </entry></row><row><entry /><entry>6</entry><entry>I6 </entry></row><row><entry /><entry>7</entry><entry>I7 </entry></row><row><entry /><entry>8</entry><entry>I8 </entry></row><row><entry /><entry>9</entry><entry>I9 </entry></row><row><entry /><entry>10</entry><entry>I10</entry></row><row><entry /><entry>11</entry><entry>I11</entry></row><row><entry /><entry>12</entry><entry>I12</entry></row><row><entry /><entry>13</entry><entry>I13</entry></row><row><entry /><entry>14</entry><entry>I14</entry></row><row><entry /><entry>15</entry><entry>I15</entry></row><row><entry /><entry>16</entry><entry>I16</entry></row><row><entry /><entry>17</entry><entry>I17</entry></row><row><entry /><entry>18</entry><entry>I18</entry></row><row><entry /><entry>19</entry><entry>I19</entry></row><row><entry /><entry>20</entry><entry>I20</entry></row><row><entry /><entry>21</entry><entry>I21</entry></row><row><entry /><entry>22</entry><entry>I22</entry></row><row><entry /><entry>23</entry><entry>I23</entry></row><row><entry /><entry>24</entry><entry>I24</entry></row><row><entry /><entry>25</entry><entry>I25</entry></row><row><entry /><entry>26</entry><entry>I26</entry></row><row><entry /><entry>27</entry><entry>I27</entry></row><row><entry /><entry>28</entry><entry>I28</entry></row><row><entry /><entry>29</entry><entry>I29</entry></row><row><entry /><entry>30</entry><entry>I30</entry></row><row><entry /><entry>31</entry><entry>I31</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

An example of PIMU instruction is shown in Tables 6–8. An instruction, as exemplified, consists of 19 bits. Bits 0–5 define the duration of the instruction in terms of clock cycles. Bit 13 is the row address strobe (RAS) enable, bit 12 is the column address strobe (CAS) enable, and bit 11 is the write enable (WEN). Bits 7–10 are data mask bytes 0–3. BA is defined as bank address.

<tables id="TABLE-US-00006" num="00006"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 6</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>An example of a PIMU instruction format</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="35pt" align="center" /><colspec colname="2" colwidth="91pt" align="left" /><colspec colname="3" colwidth="91pt" align="left" /><tbody valign="top"><row><entry>BIT(s)</entry><entry>FUNCTION</entry><entry>DEFINITION</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>18</entry><entry>Read Data Type Instruction</entry><entry>0 = Inactive, 1 = Active</entry></row><row><entry>17</entry><entry>Write Data Type Instruction</entry><entry>0 = Inactive, 1 = Active</entry></row><row><entry>16</entry><entry>Address Control</entry><entry>See Table 7</entry></row><row><entry>15</entry><entry>Bank Precharge Control</entry><entry>See Table 8</entry></row><row><entry>14</entry><entry>SDRAM Signal CKE Level</entry><entry>0 = Low, 1 = High</entry></row><row><entry>13</entry><entry>SDRAM Signal RAS Level</entry><entry>0 = Low, 1 = High</entry></row><row><entry>12</entry><entry>SDRAM Signal CAS Level</entry><entry>0 = Low, 1 = High</entry></row><row><entry>11</entry><entry>SDRAM Signal WEN Level</entry><entry>0 = Low, 1 = High</entry></row><row><entry>10</entry><entry>SDRAM Signal DQM3 Level</entry><entry>0 = Active, 1 = Inactive</entry></row><row><entry> 9</entry><entry>SDRAM Signal DQM2 Level</entry><entry>0 = Active, 1 = Inactive</entry></row><row><entry> 8</entry><entry>SDRAM Signal DQM1 Level</entry><entry>0 = Active, 1 = Inactive</entry></row><row><entry> 7</entry><entry>SDRAM Signal DQM0 Level</entry><entry>0 = Active, 1 = Inactive</entry></row><row><entry> 6</entry><entry>SDRAM Signals DATA(31:0)</entry><entry>0 = In(read), 1 = Out(write)</entry></row><row><entry /><entry>Direction Control</entry></row><row><entry>5:0</entry><entry>Instruction Duration</entry><entry>Clock_Cycles + 1</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

<tables id="TABLE-US-00007" num="00007"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 7</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Bit 16, address control</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="35pt" align="center" /><colspec colname="2" colwidth="56pt" align="left" /><colspec colname="3" colwidth="126pt" align="left" /><tbody valign="top"><row><entry /><entry>SDRAM</entry><entry /></row><row><entry>VALUE</entry><entry>COMMAND</entry><entry>DEFINITION</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>1</entry><entry>“Activate” or</entry><entry>SDRAM Signals BA(1:0) = Internal</entry></row><row><entry /><entry>“Mode Register</entry><entry>Address (20:19) = Bank</entry></row><row><entry /><entry>Set”</entry><entry>SDRAM Signals ADDR(10:0) = Internal</entry></row><row><entry /><entry /><entry>Address (18:8) = Row</entry></row><row><entry>0</entry><entry>“Read”, “Write”,</entry><entry>SDRAM Signals BA(1:0) = Internal</entry></row><row><entry /><entry>or “Precharge”</entry><entry>Address (20:19) = Bank</entry></row><row><entry /><entry /><entry>SDRAM Signals ADDR(10) = Bank</entry></row><row><entry /><entry /><entry>Precharge Control</entry></row><row><entry /><entry /><entry>SDRAM Signals ADDR(9:8) = Internal</entry></row><row><entry /><entry /><entry>Address(9:8)</entry></row><row><entry /><entry /><entry>SDRAM Signals ADDR(7:0) = Internal</entry></row><row><entry /><entry /><entry>Address(7:0) = Column</entry></row><row><entry>X</entry><entry>Others</entry><entry>Value Irrelevant</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

<tables id="TABLE-US-00008" num="00008"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 8</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Bit 15, bank precharge control</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="77pt" align="left" /><colspec colname="2" colwidth="140pt" align="left" /><tbody valign="top"><row><entry>SDRAM COMMAND</entry><entry>DEFINITION</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>“Read” or “Write”</entry><entry>0 = Auto Precharge Disable, 1 = Auto</entry></row><row><entry /><entry>Precharge Enable</entry></row><row><entry>“Precharge”</entry><entry>0 = Precharge Current Bank, 1 = Precharge</entry></row><row><entry /><entry>Both Banks</entry></row><row><entry>Others</entry><entry>Value Irrevelant</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

Details of instruction formats and typical command instructions (as in table 9) may be found in different SDRAM specifications provided by manufacturers. One such specification is NEC Data Sheet of 16M-bit Synchronous DRAMs provided by NEC Corporation, Document No. M12939EJ3V0DS00 (third edition), published in April 1998, which is incorporated herein by reference in its entirety.

Referring again to <figref idref="DRAWINGS">FIG. 2</figref>, PIMU <b>22</b> may store any set of instructions for an SDRAM, including instructions that may be different from those shown in table 9. Based on the programmed sequence stored in PISU <b>21</b>, each requestor may construct or execute its own SDRAM transaction. With respect to the instructions exemplified in table 9, the instructions may be arranged in any sequence of PIMU address values for each sequence of position codes per requestor.

<tables id="TABLE-US-00009" num="00009"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 9</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Typical SDRAM command instructions</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="168pt" align="center" /><tbody valign="top"><row><entry /><entry>DEFINITION</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="7"><colspec colname="1" colwidth="49pt" align="left" /><colspec colname="2" colwidth="21pt" align="center" /><colspec colname="3" colwidth="21pt" align="center" /><colspec colname="4" colwidth="21pt" align="center" /><colspec colname="5" colwidth="21pt" align="center" /><colspec colname="6" colwidth="35pt" align="center" /><colspec colname="7" colwidth="49pt" align="left" /><tbody valign="top"><row><entry>COMMAND</entry><entry>CKE</entry><entry>RAS</entry><entry>CAS</entry><entry>WEN</entry><entry>DQM(3:0)</entry><entry>ADDR(12:0)</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1" /></row><row><entry>ACTIVATE</entry><entry>1</entry><entry>0</entry><entry>1</entry><entry>1</entry><entry>X</entry><entry>Bank/Row</entry></row><row><entry>AUTO</entry><entry>1</entry><entry>0</entry><entry>0</entry><entry>1</entry><entry>X</entry><entry>x</entry></row><row><entry>REFRESH</entry></row><row><entry>MODE</entry><entry>1</entry><entry>0</entry><entry>0</entry><entry>0</entry><entry>X</entry><entry>Bank/Row</entry></row><row><entry>REGISTER</entry></row><row><entry>SET</entry></row><row><entry>NOP</entry><entry>1</entry><entry>1</entry><entry>1</entry><entry>1</entry><entry>X</entry><entry>x</entry></row><row><entry>PRECHARGE</entry><entry>1</entry><entry>0</entry><entry>1</entry><entry>0</entry><entry>X</entry><entry>Bank/Column</entry></row><row><entry>READ</entry><entry>1</entry><entry>1</entry><entry>0</entry><entry>1</entry><entry>0 or 1</entry><entry>Bank/Column</entry></row><row><entry>SELF</entry><entry>0</entry><entry>0</entry><entry>0</entry><entry>1</entry><entry>X</entry><entry>x</entry></row><row><entry>REFRESH</entry></row><row><entry>TERMINATE</entry><entry>1</entry><entry>1</entry><entry>1</entry><entry>0</entry><entry>X</entry><entry>x</entry></row><row><entry>WRITE</entry><entry>1</entry><entry>1</entry><entry>0</entry><entry>0</entry><entry>0 or 1</entry><entry>Bank/Column</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

Each instruction is provided to IEU <b>24</b> by PIMU <b>22</b>. The instruction is executed upon receiving an execution request from SAU <b>23</b> to IEU <b>24</b>. When the IEU completes executing the instruction, the IEU provides an execution acknowledge to the SAU. An execution acknowledge is returned to the SAU from the IEU for every execution request of an instruction. The SAU increments the PISU position code (input to the PISU), so that the IEU may receive the next instruction in the sequence, as an output from the PIMU. Upon the next execution request, the IEU begins executing that next instruction provided from the PIMU.

The IEU continues to execute the instructions, until the SAU determines that the last instruction had been executed. Arrival of the last instruction may be determined by the SAU, based on a last PISU address comparison (as described later, with reference to register <b>42</b> shown in <figref idref="DRAWINGS">FIG. 4</figref>). After detecting the last PISU address, the SAU may be ready to receive and arbitrate the next service request(s).

As necessary, IEU <b>24</b> provides control to EIU <b>25</b> and WDSU <b>27</b>. During a read instruction, the EIU is enabled to receive SDRAM data and transmit the received data to the appropriate requestor. During a write instruction, WDSU <b>27</b> is enabled to receive data from the appropriate requestor and pass the received data, via EIU <b>25</b>, to the SDRAM.

Referring now to <figref idref="DRAWINGS">FIG. 3</figref>, there is shown method <b>30</b> provided by the invention for operation of SDRAM controller <b>20</b> of <figref idref="DRAWINGS">FIG. 2</figref>. As shown, method <b>30</b> enters step <b>31</b>, in which the SAU may receive multiple SDRAM service requests. The method enters step <b>32</b>, in which the SAU addresses the PASU to determine which requestor has the highest service priority. The method, at next step <b>33</b>, provides a priority service ID to the SAU based on a lookup table stored in the PASU. The SAU selects a requestor, based on the priority service ID, by acknowledging the requestor and granting service to the requestor (step <b>34</b>).

After acknowledging the requestor in step <b>34</b>, the PASU advances to the next address in the sequence of addresses in its lookup table (step <b>35</b>). Depending on the selected service ID priority, the method by way of the SAU provides a position code of the requestor to the PISU (step <b>36</b>). The PISU, in turn, provides an address to the PIMU based on the sequence of position codes stored in the PISU lookup table (step <b>37</b>).

In step <b>38</b>, the PIMU provides an instruction (output) to the IEU, based on the address (input) provided from the PISU. In step <b>39</b>, the SAU issues an instruction execution request to the IEU and then increments the PISU position code. Next, step <b>40</b> of the method, by way of the IEU, executes the instruction, providing data and control to the EIU and the WDSU, as appropriate.

Upon completing the instruction, the IEU provides an execution acknowledge to the SAU in step <b>41</b>. This handshake between the IEU and the SAU is repeated for every instruction. When the SAU detects the last PISU address, in step <b>42</b>, the method branches to decision box <b>43</b>, having become aware that the last instruction for a requestor has been received.

So long as the last instruction is not received, the method branches back to step <b>36</b>. During step <b>36</b>, the SAU provides the PISU with the next position code in the sequence, so that the requestor may execute the next instruction in the sequence. If decision box <b>43</b>, on the other hand, determines that the last instruction has been received, method <b>30</b> branches back to step <b>31</b> having becoming aware that the SDRAM transaction for the particular requestor is finished. The SAU is ready to receive the next SDRAM service request(s) and arbitrate which requestor should be granted service.

Referring next to <figref idref="DRAWINGS">FIG. 4</figref>, there is shown an embodiment of an SAU, generally designated as <b>40</b>. As shown, SAU <b>40</b> includes state machine <b>43</b> receiving/sending control and status from/to multiple requestors (<figref idref="DRAWINGS">FIG. 1</figref>), the microprocessor (<figref idref="DRAWINGS">FIG. 1</figref>), the PISU (<figref idref="DRAWINGS">FIG. 2</figref>) and the PASU (<figref idref="DRAWINGS">FIG. 2</figref>). When receiving a service request from one or more requestors, state machine <b>43</b> enters a state of providing service to the requestor and exits the state by sending a service acknowledge to the requestor.

When servicing the requestor, state machine <b>43</b> increments counter <b>45</b> and enters a priority determination state by sending the next address (for example address 1 in the programmable schedule shown in Table 1) to the PASU. The state machine exits this state, after receiving the PASU data (namely, a priority service ID) located at the address sent to the PASU.

When the state machine is idle and other requestors are awaiting service, the state machine enters an LRU state and communicates with LRU control <b>44</b>. The least recently used (LRU) requestor is identified and given service priority. The state machine exits this state, after being informed of the identity of the LRU requestor.

Yet another state is a PISU addressing state entered by state machine <b>43</b> upon loading and incrementing counter <b>41</b>. The counter is loaded at 0 and sequentially advanced, as shown in Table 3. For every increment of counter <b>41</b>, a corresponding address (sequence position code in Table 4) is output to the PISU (<figref idref="DRAWINGS">FIG. 2</figref>). An execution request (IEU REQ (n)) is sent to the IEU (<figref idref="DRAWINGS">FIG. 2</figref>) for every sequence position code address provided to the PISU. After the IEU executes an instruction corresponding to a sequence position code address, the IEU sends an execution acknowledge (IEU ACK (n)).

The state machine, upon receiving the IEU ACK (n), increments counter <b>41</b> and sends the next sequence position code address to the PISU. The sequencing continues, until the last instruction is executed by the IEU for the n^threquestor (shown as a service ID in Tables 3 and 4). The occurrence of the last instruction may be determined by state machine <b>43</b> upon a comparison between the address sent to the PISU and an address stored in register <b>42</b> containing the last PISU address.

Upon detecting the last PISU address and upon receiving an IEU ACK (n), state machine <b>43</b> returns to idle and is ready for the next service request from another memory requestor.

An embodiment of an IEU is shown in <figref idref="DRAWINGS">FIG. 5</figref>, generally designated as <b>50</b>. IEU <b>50</b> includes state machine <b>53</b> servicing state machine <b>43</b> (<figref idref="DRAWINGS">FIG. 4</figref>). For every IEU REQ (n) received from state machine <b>43</b>, instruction data is received from the PIMU (<figref idref="DRAWINGS">FIG. 2</figref>) and stored in register <b>51</b>. The PIMU data may be 19 bits wide and may include the format shown in Table 6. The instruction duration (6 bits) may be stored in register <b>52</b>, so that state machine <b>53</b> may count down a number of clock cycles to zero, as specified by the instruction duration. Upon completing the PIMU instruction, state machine <b>53</b> sends an IEU ACK (n) to state machine <b>43</b>.

As shown, control bits may be provided to the SDRAM, by way of the EIU (<figref idref="DRAWINGS">FIG. 2</figref>) from register <b>54</b>. Write data received from a memory requestor, by way of the WDSU (<figref idref="DRAWINGS">FIG. 2</figref>), may be buffered in register <b>56</b> and sent to the SDRAM, by way of the EIU. Finally, read data received from the SDRAM, by way of the EIU, may be buffered in register <b>57</b>. Registers <b>56</b> and <b>57</b> may each be 32 bits wide, for example.

As shown, state machine <b>53</b> may provide a READ REQ (n) to the EIU and enable the EIU to send data from the SDRAM to a memory requestor. State machine <b>53</b> may, on the other hand, provide a WDSU REQ (n) to the WDSU, so that the WDSU is enabled and may send data arriving from a memory requestor to the SDRAM, by way of the EIU.

As shown, IEU <b>50</b> includes clock generator <b>55</b>, which provides synchronization to the controller and the SDRAM.

Although the invention is illustrated and described herein with reference to specific embodiments, the invention is not intended to be limited to the details shown. Rather, various modifications may be made in the details within the scope and range of equivalents of the claims and without departing from the invention.