HARDWARE TIMER MANAGER THAT SUPPORTS MULTIPLE ACCURACY LEVELS

Abstract

A hardware timer manager can be used in a network accelerator. The timer manager can support multiple timer precision levels. A timer manager can divide a total group of supported timer entries into multiple precision groups in a memory. The timer manager can check a programmed number of timer entries in a highest precision group before checking a single programmed timer entry in the next group, and repeat this check until a timer entry in the lowest precision group is checked, and then repeat from the beginning.

Description

TECHNICAL FIELD

[0001] The present disclosure relates generally to timer managers, and more particularly to timer managers configured to support multiple levels of precision for timers. BACKGROUND

[0002] In a digital system, it is useful to track the time of data and tasks in, outside, and / or throughout the system. This may be referred to as time stamping and can be useful for synchronizing the reference time used across multiple connected systems so they operate from the same reference point. Programming timers to expire at a set time can also be useful. Timers can be used to schedule future tasks and work and to set time limits for functions.

[0003] For software and firmware, it can be helpful if a timer manager handles timestamping and timer functionality and also provides users with a straightforward interface for interaction. Certain timer managers can be expensive depending on the number of timers they track, the level of time accuracy, which timestamping and timer ranges and features are supported, and how the timer manager delivers an event when a timer expires. SUMMARY

[0004] In one arrangement, a method comprises determining a number of timer entries in a first group of timer entries; accessing a first subset of the first group of timer entries containing the number of timer entries; determining whether any of the first subset of the first group of timer entries corresponds to a timer expiration; and after accessing the first subset of the first group of timer entries, accessing a timer entry of a second group of timer entries; and determining whether the timer entry of the second group of timer entries corresponds to a timer expiration; and after accessing the timer entry of the second group of timer entries, accessing a second subset of the first group of timer entries containing the number of timer entries; and determining whether any of the first subset of the first group of timer entries corresponds to a timer expiration.

[0005] In one arrangement, a network accelerator comprises a processor core; a processor scheduler communicatively coupled to the processor core; and a timer manager communicatively coupled to the processor scheduler, the timer manager comprising: a memory configured to store a plurality of timer entries comprising a first group of timer entries and a second group of timer entries; a plurality of registers configured to store first settings of a first group of the timer entries and store second settings of a second group of the timer entries;and hardware logic configured to determine whether the first group of timer entries corresponds to a timer expiration more often than the second group of timer entries, according to the first settings and the second settings, and further configured to communicate with the processor core via the processor scheduler in response to accessing the plurality of timer entries.;

[0006] In one arrangement, a hardware timer manager comprises a memory RAM configured to store a plurality of timer entries; a plurality of registers configured to store an indication of a first level of accuracy for a first group of timer entries and to store an indication of a second level of accuracy for a second group of timer entries; and hardware logic configured to determine whether the first group of timer entries corresponds to a timer expiration based on the first level of accuracy and determine whether the second group of timer entries corresponds to a timer expiration based on the second level of accuracy, further wherein the first level of accuracy is different from the second level of accuracy. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Having thus generally described the invention, reference is now made to the accompanying drawings, in which: Fig. 1 is an illustration of an example timer manager configured in accordance with some embodiments. Fig. 2 illustrates a format of a timer entry in timer RAM according to some embodiments. Fig. 3 illustrates an example method for managing multiple timer entry groups to provide multiple levels of accuracy, according to some embodiments. Fig. 4 illustrates an example method for managing groups of timer entries according to some embodiments. Fig. 5 is a diagram of an exemplary network accelerator that uses a timer manager (e.g., the timer manager of Fig. 1), according to some embodiments. Fig. 6 is a diagram of an exemplary SoC (System on a Chip) that implements the exemplary network accelerator of Fig. 5 may include, according to some embodiments. DETAILED DESCRIPTION

[0008] The present disclosure provides a timer manager that supports multiple levels of precision, automatic expiration event scheduling, and timestamps with synchronization capability.

[0009] The multiple accuracy levels enable high- and low-accuracy timers while keeping development costs low. In some examples, a timer manager works by dividing the total supported timers into accuracy groups, testing a programmed number of timers in a highest-accuracy group before testing one in the next group, and repeating this testing process until a lowest-accuracy group is tested, which is then repeated from the beginning. This supports a variety of timer expiration periods without sacrificing accuracy.

[0010] In some examples, the timer manager provides an event upon timer expiration, scheduling the event directly to a processor core connected in the system. This can happen automatically after a timer expires, if it has been checked. The timer manager pushes the event into a hardware queue to support buffering multiple timer events if the processor core is unable to service them in a timely manner.

[0011] In some examples, the timer manager supports a timestamping counter with a software interface to synchronize it with other timestampers in the system. The counter can be programmed directly, triggered by a signed 8-bit value (one-time adjustment), periodically incremented or decremented (adjustment for offset), and incremented by one or more timestamps every clock cycle.

[0012] The Timer Manager's software interface can be used to add or modify timer entries. To add a timer, the user (e.g., a processor core) can program each timer field, which contains the precision group the timer belongs to. At any time thereafter, the user can read the timer's status (whether it was successfully added) and index it for tracking purposes. The user can set whether the new timer is a single-shot or periodic timer. In the periodic case, the Timer Manager can automatically reactivate the timer upon expiration with a new expiration value based on its programmed period. To delete a timer, the user can program the index of the desired timer to be deleted.This fast access provides the user with more bandwidth and allows dynamic addition and deletion of timers for applications such as setting and removing a time limit function if the task was successfully completed before the time limit was reached.

[0013] While no particular advantage is required for any particular embodiment, in some examples, the Timer Manager's multiple precision groups can enable a wide variety of timer precision levels and expiration periods while keeping development costs low. The time stamping functionality with synchronization can be valuable for TSN (time-sensitive networking) and other networking and software applications. Direct event scheduling can be advantageous for systems and software that are highly event-driven. In these examples and others, the software interface can provide all necessary functionality while maintaining minimal accesses, allowing more user bandwidth.

[0014] Fig. 1 is an illustration of an exemplary timer manager 100 configured in accordance with some embodiments. The timer manager 100 may be implemented in any suitable manner, such as in a network accelerator, which is itself implemented within the circuitry of a SoC (System on a Chip). An example of a network accelerator is the network accelerator 500 of Fig. 5, and an exemplary SoC includes the SoC 600 from Fig. 6. Fig. 5 and Fig. 6 are described in more detail below.

[0015] The timer manager 100 includes timer registers 120, timer memory (e.g., RAM) 140, timer hardware logic 110, central counter adjustment logic 130, a non-real-time (first-in-first-out) FIFO buffer 102, and a real-time (RT) FIFO buffer 104. In this example, a processor core (not shown, such as in a network accelerator or an SoC) may configure a timer using the configuration interface 128 to write data to the timer registers 120. In response, the timer hardware logic 110 may add a timer entry to a corresponding group in the timer memory 140. The central counter 142 may be a counter register or other suitable data structure that either increments or decrements based on cycles of a clock (not shown).

[0016] Timer hardware logic 110 accesses the timer entries in timer memory 140 to determine expiration. For example, a given timer entry may include an expiration value indicating its expiration, and timer hardware logic 110 may compare the expiration value to a current value of central counter 122 to determine whether the timer entry has expired. If the timer entry has expired, timer hardware logic 110 may take a step in response to the expiration. One such step includes adjusting the expiration value if it is determined that the timer entry indicates that it is a periodic timer entry. Another such step includes writing a processor function pointer and a processor function argument from the timer entry to either the non-real-time FIFO buffer 102 or the real-time FIFO buffer 104.For example, some timer entries may include data indicating a real-time status or may include data indicating a non-real-time status, and the timer hardware logic 110 may use this data to write to either the FIFO buffer 102 or the FIFO buffer 104 in response to this status data.

[0017] FIFO buffer 102 may supply data to the non-real-time scheduler interface, and FIFO buffer 104 may supply data to a real-time scheduler interface. Each of the scheduler interfaces may be implemented in a processor scheduler (e.g., scheduler 507 of Fig. 5) that receives function pointers and arguments and provides ordered arbitration when presenting these function pointers and arguments to a processor (e.g., one of the processor cores 508 of Fig. 5). For example, the scheduler can treat real-time events with a higher priority than non-real-time events. This allows the processor core to execute a function based on the function pointer and the function argument in response to a timer expiration.

[0018] The timer registers 120 may act as a software interface for a processor core. For example, some or all of the timer registers 121 and 123-127 may be configured as MMRs (memory-mapped registers) in an address space of one or more processor cores (not shown). Examples of processor cores that can write to and read from the timer registers 120 include an application processor core (such as 610 of Fig. 6) and an accelerator processor core (such as one of the processor cores 508 of Fig. 5).

[0019] As previously mentioned, a single timer entry may be part of a particular group of timer entries, and each of these groups may correspond to a respective level of precision. A processor core may configure a timer group by writing to the group status registers 126 and the group subregisters 127. In one example, the group subregisters 127 may include data specifying timer indices that start each of the groups. In an example where 128 (0-127) timer entries can be accommodated in the timer memory 140, group 1 may start at index 0, group 2 may start at index 20, and so on and so forth until group x may start at index 63 and end at index 127. Of course, these are merely examples, and the scope of implementations may include any suitable number of timer entries and any suitable grouping of timer entries.

[0020] The group subregisters 127 may also include data specifying a number of timer entries to be checked in a group before a single entry in the next group is checked. This concept is explained in more detail below, and it configures the accuracy levels. In other words, certain groups may be checked with different frequencies than other groups, and the groups checked with higher frequencies are the higher accuracy groups, and the groups checked with lower frequencies are the lower accuracy groups.

[0021] In one example, a particular timer group can be locked by a processor core writing its starting index to a total number of timer entries (e.g., 128) and setting a total number of checks to zero.

[0022] Timer hardware logic 110 can write to and read from group status registers 126. Group status registers 126 can include data indicating whether a particular group is full or not full, a first free index of a group, and a next timer index to be checked within a group. Timer hardware logic 110 can read and, if necessary, update the data in group status registers 126 depending on how groups become full or not full, new timer entries are written or existing timer entries are deleted, and how a timer check progresses through a set of indices.

[0023] Registers 121 include go data and software reset data, both of which can be represented as a single bit or multiple bits. For example, a processor core can write a zero or one to timer memory 140 to cause a software reset of the timer entries. Furthermore, the processor core can write a zero or one to timer memory 140 (go data) to instruct timer hardware logic 110 to either stop or start checking the timer entries. Timer hardware logic 110 can read a value from register 121 and then take an appropriate action.

[0024] Although it is in Fig. 1, the timer registers 120 may also include one or more registers configured to store an initiator ID. For example, a processor core writing to the timer registers 120 may also write its processor ID to a register.

[0025] The central counter 122 may increment or decrement according to a system clock (not shown). In one example, the central counter 122 may include 56 bits specifying a value that is incremented each clock cycle and flips from all ones to all zeros upon reaching a value. The timer manager 100 further includes central counter increment and adjust logic 130 that may adjust a value of the central counter 122 under the control of either a processor core (e.g., 508 or 610) or the timer hardware logic 110.Examples of control by logic 130 would include: a value to increment the counter value per clock cycle, a one-time addition of a fixed signed eight-bit value to increase or decrease the counter value, a periodically repeating addition or subtraction to the most significant bit of the counter value, and a periodically repeating addition or subtraction to the least significant bit of the counter value. Of course, the scope of implementations may include any suitable adjustment of the counter value and any number of bits for the central counter 102.

[0026] Register 123 may be configured to receive data to add a new timer entry to one of the groups in timer memory 140. For example, data that may be written by a processor core to register 123 would include: a group to which the new timer entry is to be added, RT or NRT status of the new timer entry, single iteration or periodic iteration status of the timer entry, a processor function pointer associated with the new timer entry, a processor function argument associated with the new timer entry, and the like. During an add operation, a processor core may write to register 123, and timer hardware logic 110 may read the data from register 123 and set a corresponding timer entry in a corresponding group in timer memory 140.Timer hardware logic 110 may assign an index to the timer entry and then write that index to register 124, where the index placement in register 124 indicates successful addition of the timer entry. Timer hardware logic 110 may provide the index to the processor core. The processor core may read the index from register 124 to track the timer entry and also to determine that the timer entry was successfully added.

[0027] Additionally, memory space for a given group is finite, and in some cases, a group may be full. If a given group is full, timer hardware logic 110 can write to register 124 that a given group is full, thereby indicating that a processor core can create a new timer in that group.

[0028] Register 125 may be configured to store data associated with the deletion of an existing timer entry. For example, a processor core may cause a timer entry to be deleted by writing the index of that timer to register 125. Timer hardware logic 110 may then read the value from register 125 and delete the corresponding timer entry. In one example, timer hardware logic 110 may delete the timer entry by changing a mode of an entry to a free value, which is described in more detail with reference to Fig. 2 is discussed.

[0029] Fig. 2 is an illustration of an example format of a timer entry 200 in the timer memory 140, according to some embodiments. In some examples, each of the groups may span a particular address range in the timer memory 140, and any given timer entry in a group may be placed within that address range. In another example, each timer entry may occupy a word in a range of addresses for its group. Furthermore, the address ranges of the groups in the timer memory 140 may be physically adjacent and / or logically adjacent. For example, the last word in the address range of group 1 may be adjacent to the first word in group 2, and so on and so forth. This may be physically so in some cases. In other cases, the address ranges may be logical, and the logical addresses of each group may be adjacent, whether physically adjacent or not.

[0030] In the example of Fig. 2, timer entry 200 includes a 133-bit word written to timer memory 140. Timer entry 200 includes fields 210 that can be written by timer hardware logic 110 and that can be based on data written to registers 123-124 by a processor core.

[0031] The RT field specifies a priority of the timer entry, for example, whether the timer entry is real-time or non-real-time. The Offset field specifies a value to be added to a timer expiration value upon expiration of this timer entry, if the timer entry is a periodic timer entry, to indicate the end of the timer's next period. The Expiration Value field specifies when the time interval associated with the associated timer should expire. In some examples, the Expiration Value field specifies a corresponding value of the central counter 122 at which the timer entry expires. The Function field is a processor pointer designed to be sent to the scheduler (via one of the FIFO buffers 102, 104) upon expiration of the timer entry and which can specify a processor operation and / or code to be executed by the associated processor core. The Group field specifies which of the groups the timer entry belongs to.

[0032] The Mode field specifies the current state of a timer entry, such as free or running, and periodic or single. For example, a value of zero can indicate that the timer entry is free (e.g., ready to be written to for use as a new timer), as can be set by deleting the timer entry. Conversely, if the timer is already running, the Mode value can be a non-zero value that indicates whether the timer entry is a periodic-iteration entry or a single-iteration entry. As mentioned earlier, a timer entry that is periodic can have its expiration value modified by a value in the Offset field when the timer is determined to expire. A timer entry that is a single-iteration entry can be deleted after it is determined to have expired.The expiration of a timer may be accompanied by the timer hardware logic 110 sending the values ​​from the Function and Arg fields to the scheduler via one of the FIFO buffers 102, 104.

[0033] The Arg field is a processor function argument that accompanies the function pointer of the Function field. In one example, a function pointer may correspond to a specific processing operation, and the Arg value may represent a data memory address of a packet to be processed by the operation, although implementations may include any suitable function and argument.

[0034] Fig. 3 is an illustration of an example method 300 for managing multiple timer entry groups to provide multiple levels of accuracy, according to some embodiments. Method 300 may be performed, for example, by a timer manager, such as timer manager 100, including timer hardware logic 110. The groups, in this example, group 1 through group 3, may refer to groups of timer entries, such as those stored in timer memory 140 and configured using data in registers 126-127.

[0035] Furthermore, in this example, C1 refers to a number of checks in group 1 before a single check of a timer entry in group 2 is performed; C2 refers to a number of checks in group 2 before a single check of a timer entry in group 3 is performed. Although the example of Fig. 3 comprises three groups, it is understood that various embodiments may scale the number of groups as appropriate. For example, to expand from three groups to four groups, an embodiment may include a number C3 that refers to a number of checks in group 3 before a single check of a timer entry in group 4 is performed. In the example of Fig. 1, the values ​​C1-C3 can be stored in the register 127 and can be configured by an application processor core via the configuration interface 128.

[0036] In step 302, the timer manager checks a group 1 entry. For example, the timer hardware logic 110 may compare an expiration value in a first timer entry in group 1 with a current value of the central counter 122. In one example, the timer entry has expired if the current value of the central counter 122 exceeds the expiration value by less than half the maximum value of the central counter, taking into account rollover, and otherwise the timer entry has not expired. Of course, expiration may be defined in any suitable manner. Since there cannot be C1 active timer entries in group 1, the timer manager check in step 302 may include checking whether the respective timer entry is active.

[0037] Step 304 includes decrementing C1 by a value of one, and step 306 includes determining whether C1 has reached zero. If C1 has not yet reached zero, the method 300 loops back to step 302. In other words, the method 300 includes performing an integer number C1 of checks on entries in group 1 before checking a single entry of group 2 (step 308). In step 310, C2 is decremented by a value of one. In step 312, the timer hardware logic 110 checks whether C2 has reached zero. If C2 has not yet reached zero, the method 300 loops back to step 302. If C2 has reached zero, the method proceeds to step 314 to check a single entry of group 3. After checking the individual entry of group 3, the method 300 loops back to step 302.

[0038] Although it is in Fig. 3, the loop of steps 302-306 may include advancing from an address of a first timer entry to an address of a next timer entry each time the loop is executed. Therefore, the loop of steps 302-306 may perform a test of C1 individual timer entries in group 1. Similarly, each test of step 308 may include advancing from an address of a first timer entry of group 2 to an address of a next timer entry each time step 308 is executed. And each time step 314 is executed, it may advance from an address of a first timer entry in group 3 to an address of a next timer entry. Of course, each group in this example includes a finite number of entries, so once one end of an address range of a group is reached, the next test in that group may advance to the next timer entry of that group.

[0039] Furthermore, in this example, method 300 may be executed continuously as long as timer manager 100 is powered up and not reset. In other words, when a count C1 (or C2 or C3) goes to zero, such a count may be reinitialized back to the original and maximum count C1 (or C2 or C3). In some examples, method 300 may be halted by an application processor core changing a go bit in register 121 or causing a software reset by changing a value in register 121.

[0040] One way to understand method 300 is that it includes nested loops. For example, the inner nested loop represents checks of timer entries of group 1. The middle loop represents checks of timer entries of group 2, and the outer loop represents checks of timer entries of group 3. As a result of the nested loop structure, the timer entries of group 2 are checked more often than the timer entries of group 2, and the timer entries of group 2 are checked more often than the timer entries of group 3. In this example, group 1 represents a high-precision group of timer entries, group 2 represents a medium-precision group of timer entries, and group 3 represents a low-precision group of timer entries.

[0041] The following is an exemplary use case of the method 300, assuming a clock rate of 2 ns, wherein in each clock cycle the timer hardware logic 110 performs a check of a timer entry, such as in one of the steps 302, 308 or 314: • Timer entry / group check algorithm (3 groups) - C1 = Number of tests in Group 1 - C2 = Number of tests in Group 2 - Check C1 timer entries in group 1, then one in group 2 - Repeat until C2 timer entries in group 2 have been checked. - Checking an entry in Group 3 (adjacent to Group 2 testing) - Repeat by going back to group 1 • Timer group accuracy calculation - Definitions of the variables • Period = clock period • N1 = Number of timer entries in group 1 • N2 = Number of timer entries in group 2 • N3 = Number of timer entries in group 3 • C1 = Number of tests in Group 1 • C2 = Number of tests in Group 2 • P1 = Accuracy for Group 1 • P2 = Accuracy for Group 2 • P3 = Accuracy for Group 3 - Accuracy formulas • P1 = Period * (N1 + (N1 / C1) + (N1 / (C2 * C1))) • P2 = Period * (N2 + (N2 * C1) + (N2 / C2)) • P3 = Period * (N3 + (N3 * C2 * C1) + (N3 * C2)) - Example accuracy calculation • Period = 2ns • N1 = 20 • N2 = 30 • N3 = 40 • C1 = 10 • C2 = 5 • P1 = 2ns * (20 + (20 / 10) + (20 / (5 * 10))) = 44.8ns • P2 = 2ns * (30 + (30 * 10) + (30 / 5)) = 672ns • P3 = 2ns * (40 + (40 * 5 * 10) + (40 * 5)) = 4480ns

[0042] Thus, in the above example, each timer entry in Group 1 is checked by the timer hardware logic 110 every 44.8 ns, each timer entry in Group 2 is checked by the timer hardware logic 110 every 672 ns, and each timer entry in Group 3 is checked by the timer hardware logic 110 every 4480 ns. Note that there is a difference of more than an order of magnitude between the check frequency of Group 1 entries compared to Group 2 entries. There is also a difference of an order of magnitude between the check frequency of Group 1 entries compared to Group 3 entries. Of course, the check frequency depends on the parameters: clock cycle period, number of active timer entries in a group (N1-N3), and the values ​​of C1 and C2. Parameters N1-N3 may change when timers are added or deleted, and as noted above, C1 and C2 can be configured via the configuration interface 128.In some examples, the clock period may or may not be adjustable. The scope of implementations may include configuring the parameters in any suitable manner.

[0043] Fig. 4 is an illustration of the exemplary method 400 for managing groups of timer entries according to some embodiments. The method 400 may be performed by a timer manager, such as the timer manager 100 of Fig. 1. The example method 400 refers to three accuracy groups, although it is understood that the scope of implementations can be scaled to as many accuracy groups as appropriate.

[0044] In step 402, the timer manager accesses a first plurality (N) of timer entries of the first group to determine whether any of the first plurality of timer entries are active and to determine expiration of one or more of the first plurality of active timer entries. For example, step 402 may be illustrated by the loop of steps 302-306, where C1 corresponds to the first plurality N. An access operation in method 400 may include performing checks on timer entries in the groups, such as by comparing respective expiration values ​​of the active timer entries to a current value of a counter.

[0045] Step 402 may further include performing an appropriate step if it is determined that a timer entry has expired. In some examples, a timer entry has expired if the central counter exceeds an expiration value by less than half the maximum value of the central counter, taking into account counter flipping. In implementations that support both real-time (RT) and non-real-time (NRT) timer entries, a given timer entry may be considered not to have expired if it is either NRT and the NRT FIFO buffer is full, or if the timer entry is RT and the RT FIFO buffer is full and a timer entry is not in a highest precision level group. Examples of FIFO buffers include FIFO buffers 102 and 104 of Fig. 1, receive the data from the timer hardware logic 110 and forward this data to an interface of a processor scheduler (e.g., scheduler 507 of Fig. 5) lead.

[0046] When a timer entry expires, the timer manager can take an appropriate expiration step. In one example, the timer manager can push the values ​​from the Function and Arg fields of the expired timer entry into either the RT FIFO buffer or the NRT FIFO buffer, as appropriate. If an entry is a periodic entry, which is determined by the Mode field, the timer manager can calculate a new expiration value based on the Offset field and the Expiration Value field and then write the new value to the Expiration Value field. If the timer entry is a single-timer entry, which is determined by the Mode field, the timer manager can delete the timer entry by changing the Mode field to free.

[0047] In step 404, the timer manager accesses a first timer entry of the second group to determine whether the first timer entry is active and to determine expiration of the first timer entry. An example is shown in Fig. 3, the timer manager moves away from the loop of steps 302-306 to perform the test in step 308. When the test timer entry has expired, the timer manager may take an appropriate expiration step as described above.

[0048] In step 406, the timer manager accesses a second plurality N of timer entries in the first group to determine whether any of the second plurality of timer entries are active and to determine expiration of any active entries of the second plurality of timer entries. An example is described above with reference to Fig. 3, where step 312 comprises returning to step 302 in a loop after checking a single entry of group 2. The second plurality of timer entries in step 402 may be the same individual timer entries as the first plurality of timer entries. For example, the number of checks performed on group 1 in steps 402 and 406 may be different from a number of active timer entries in group 1. As previously mentioned, some implementations may include index-wise (e.g., address-wise) checking of timer entries, incrementing a timer entry index with each check and returning to the first timer entry after all active timer entries in the group have been checked. The number of active timer entries in a group may be greater than, less than, or equal to the number of checks performed in a loop.

[0049] When a given timer entry in the second plurality has expired, the timer manager may take an appropriate expiration step.

[0050] In step 408, the timer manager accesses a second timer entry of the second group to determine expiration of the second timer entry. An example is described above with reference to Fig. 3, where after completion of the inner loop of steps 302-306, a single timer entry of group 2 is checked. When the second timer entry has expired, the timer manager can take an appropriate expiration step.

[0051] In step 410, the timer manager accesses a third plurality of timer entries in the first group to determine whether any of the third plurality of timer entries are active and to determine expiration of any active entries of the third plurality of timer entries. If a given timer entry of the third plurality of timer entries has expired, the timer manager may take an appropriate expiration step. Step 410 illustrates that the test operation may repeat the loop of steps 302-306 after performing a test of an entry from group 2.

[0052] In step 412, the timer manager accesses a third timer entry of the second group to determine expiration of the third timer entry. When the third timer entry has expired, the timer manager can take an appropriate expiration step. Step 412 illustrates that each time the loop of steps 302-306 is executed, a transition to a check of a timer entry of group 2 can occur.

[0053] Step 414 involves accessing a fourth timer entry of the third group to determine expiration of the fourth timer entry. When the fourth timer entry has expired, the timer manager can take an appropriate expiration step. An example of step 414 is shown in Fig. 3, where the timer manager checks only a single timer entry from group 3 when it has checked a number C2 of timer entries from group 2.

[0054] In the example of method 400, the method may continue to be performed, such as by proceeding to step 402, after step 414 has been completed.

[0055] Fig. 5 is an illustration of an exemplary network accelerator 500 that includes a timer manager (e.g., the timer manager 100 of Fig. 1), according to some embodiments. The exemplary network accelerator 500 may be implemented in a SoC (System on a Chip), such as the exemplary SoC 600 of Fig. 6, be implemented.

[0056] When implemented in systems such as the network accelerator 500 and the SoC 600, the timer manager 100 may provide multiple timer groups, each of the groups having a different degree of precision. An example of a lower-precision operation performed by a lower-precision timer group (e.g., group 3 of Fig. 3) includes a transport control protocol (TCP) retransmission timer. For example, network accelerator 501 may transmit a TCP packet and then initialize a timer entry with a cautious arrival time of an acknowledgment packet (e.g., on the order of seconds). If network accelerator 500 determines that the acknowledgment packet will be received before determining that the timer entry has expired, network accelerator 500 may cause the timer manager to delete the timer entry. However, if network accelerator 500 determines that the acknowledgment packet was not received after determining that the timer entry has expired, network accelerator 500 may perform a TCP retransmission.

[0057] In an example of a medium-precision operation, the network accelerator 500 may perform audio-video bridging (AVB). In an example AVB operation, AVB packets are sent at regular intervals and allocated time slots to guarantee a specific latency. An example latency may be 2 ms for Class A traffic and 50 ms for Class B traffic. The network accelerator 500 may cause the timer manager to set a first periodic timer entry for 2 ms and a second periodic timer entry for 50 ms. The first periodic timer entry may include an offset field corresponding to 2 ms, a function field corresponding to a packet to be transmitted, and an arg field pointing to an address of Class A packets.Similarly, the second periodic timer entry may include an offset field corresponding to 50 ms, a function field corresponding to a packet transfer operation, and an arg field pointing to an address of class B packets.

[0058] In one example of a high-precision operation, the timer manager may enable time synchronization for time-sensitive networking (TSN). The high-precision operation may be on the order of nanoseconds. For example, the network accelerator 500 may include a first port, and another network accelerator, perhaps in a different SoC, may include a second port. The network accelerator 500 may use its timer manager to synchronize timestamps from the first port to the second port. Such an operation may include receiving a packet having a timestamp from the other network accelerator at the first port of the first network accelerator and sending a packet having a timestamp from the network accelerator 500 to the second port of the other network accelerator.A processor core of the network accelerator 500 may perform such sending and receiving of time-stamped packets to ultimately generate synchronization.

[0059] Some embodiments may provide advantages over other embodiments. For example, the timer manager discussed here may provide multiple levels of accuracy by testing different groups using different testing frequencies. In contrast, other systems may include a timer manager that tests all of its timer entries at the same frequency, thereby wasting some logical resources by providing a higher testing frequency than is appropriate for some lower-frequency operations. Fig. 1 can be implemented using hardware suitable for providing a desired number of groups and a desired degree of accuracy for the groups, thereby allowing more efficient use of logic. More efficient use of logic can lead to a smaller number of transistors for implementing this logic, thereby saving semiconductor area.

[0060] Furthermore, the exemplary timer manager 100 can be Fig. 1 include registers 123-127 to allow the configuration of groups and to allow the configuration of individual timer entries. Such registers may be accessible by an application processor core of the SoC 600 outside of the network accelerator 500 and may also be accessible by one or more processor cores of the network accelerator 500. The processor cores may read and write registers 123-127 to communicate with the timer manager 100 to thereby configure groups and timer entries. The availability of registers 123-127 to processor cores may allow flexibility and efficiency when configuring groups and timer entries.

[0061] Further with reference to Fig. 5, the network accelerator 500 includes a plurality of processor cores 508, which may include any suitable processor cores, general-purpose or otherwise, and with an instruction set of any size. In one example, each of the processor cores 508 executes firmware to provide processing functionality for the network accelerator 500. For example, as mentioned above, the timer manager 100 may take a run step that includes transmitting a function specification and an argument to the scheduler 507. The scheduler 507 may then pass this function specification and argument to one of the processor cores 508. Further, the processor cores 508 may include functionality for configuring registers 120. The processor cores 508 may fetch instructions from the instruction memory 506 or receive instruction pointers over the bus 593 from the direct memory access (DMA) interface 513.

[0062] An application processor core may offload network functions to the network accelerator 500 (e.g., at 610) so that the application processor core does not have to perform these functions itself. The configuration interface 503 allows an application processor core to communicate with any of the components of the network accelerator 500. For example, an application processor core may communicate over bus 591, and such communication may write to registers 120 and / or may cause an instruction to be transferred to one of the processor cores 508.

[0063] The security accelerator 502 may perform security functions on behalf of the processor cores 508. For example, some types of packets (e.g., Ethernet packets) may be designated as untrusted. In such an example, the processor cores 508 may cause such packets to be designated as either secure or untrusted by the security accelerator 502 before further processing.

[0064] Packet switch interface (PSI) endpoints 504 and 516 can receive packets via buses 592 and 594, respectively, and transfer packets into and out of the network accelerator 500. Upon receiving a packet, a PSI endpoint 504, 516 can coordinate with the memory manager (MMS) 515 to allocate space in the data memory 511. After allocating space in the data memory 511, the PSI endpoint 504, 516 can then store that packet in the allocated address range in the data memory 500.

[0065] The network accelerator 500 includes two PSI endpoints 504, 516 for increased bandwidth, with PSI endpoint 504 being dedicated to Ethernet use and PSI endpoint 516 dedicated to other packet protocols. However, various embodiments may be configured to accommodate more or fewer PSI endpoints as needed.

[0066] In some examples, an application processor core may configure steps to be taken for specific packets by writing lookup table entries to lookup table memory 512. When a packet is received and ready for processing, a processor core 508 may cause one of the lookup table engines 505 to perform a lookup table operation on the lookup table entries in lookup table memory 512. A lookup table operation may result in subsequent steps, such as events being sent by a lookup table engine 505 to the scheduler 507, where such an event may cause a step to be performed by the processor core 508.

[0067] In some examples, queue manager 510 may be used by processor cores 508 to manage queues.

[0068] The larger system in which the network accelerator 500 is implemented (e.g., the SoC 600) can transmit interrupts to the processor cores 508 via the interrupt interface 514 and the buses 595.

[0069] Priority manager 517 is implemented to prioritize some packets over others based on configuration data from an application processor core. For example, some packets may include data indicating a priority level, and priority manager 517 may perform priority functions, such as enforcing an order of data memory allocation for packets based on the packets' priority levels.

[0070] The various components are communicatively coupled by data switches 509 within the network accelerator 500.

[0071] Fig.6 is an illustration of an exemplary SoC 600 according to some embodiments. The network accelerator 500 may be implemented on the SoC 600, although the scope of implementations may include implementing the network accelerator 500 in any suitable system for offloading network functions by any suitable processor core.

[0072] In this example, Ethernet packets can be received by Ethernet packet switch 620. Packets of other protocols, such as CAM (Controller Area Network), can be received by packet switch 625. However, implementations can include more or fewer packet switches as needed to accommodate more or fewer publication protocols.

[0073] Continuing with a packet receive operation, the packets from packet switches 620, 625 are then transferred to packet direct memory access 630, which, in this example, formats the various packets into one or more formats efficient for processing by network accelerator 500. Once packet DMA 630 has formatted the packets, packet DMA 630 may transfer the packets to network accelerator 500 via buses 592, 594. Packet direct memory access 630 may communicate with the rest of SoC 610 via system packet channels 635.

[0074] As previously mentioned, the network accelerator 500 may perform network functions on the packets, allowing offloading of network functions from the rest of the SoC 610. Examples of operations that the network accelerator 500 may perform include, but are not limited to, reformatting a packet from one protocol to another (e.g., Ethernet to CAN or vice versa), dropping a packet, forwarding a packet to another endpoint, sending payload data from a packet to a component of the rest of the SoC 610, and the like. For an outgoing packet, the network accelerator 500 may transfer such a packet over one of the buses 592, 594 to either the Ethernet packet switch 620 or the packet switch 625 to the packet DMA 630. The network accelerator 500 may also transfer the payload data from the packet over bus 593 to the rest of the SoC 610.

[0075] The remainder of the SoC 610 can be configured as needed. For example, the remainder of the SoC 610 can include one or more processor cores (e.g., application processor cores, digital signal processing cores, and the like), system memory, memory interfaces or accelerators, and the like.

[0076] The present disclosure is described with reference to the accompanying figures. The figures are not drawn to scale, but are provided merely to illustrate the disclosure. Several aspects of the disclosure are described below with reference to example applications for illustrative purposes. It should also be understood that numerous specific details, relationships, and procedures are set forth to provide an understanding of the disclosure. The present disclosure is not limited by the illustrated arrangement of steps or events, as some steps may occur in different orders and / or concurrently with other acts or events. Further, not all illustrated acts or events are required to implement a methodology according to the present disclosure.

[0077] Corresponding numbers and symbols in the several figures generally refer to corresponding parts unless otherwise indicated. The figures are not necessarily drawn to scale. Throughout the drawings, like reference numerals refer to like elements, and the various features are not necessarily drawn to scale. In the following discussion and in the claims, the terms "include," "containing," "with," "having," "with," or variations thereof are intended to be inclusive in a manner similar to "comprising" and should therefore be construed as "including, but not limited to...". Additionally, the terms "coupled," "coupling," and / or "coupled" encompass indirect or direct electrical or mechanical connections or combinations thereof.For example, when a first device is electrically coupled to a second device or is electrically coupled to a second device, this connection may be via a direct electrical connection or via an indirect electrical connection through one or more intervening devices and / or connections. Elements that are electrically connected to intervening wires or other conductors are considered coupled. Terms such as "top," "bottom," "front," "back," "over," "top," "below," "beneath," and the like may be used in the present disclosure. These terms should not be construed to limit the position or orientation of a structure or element, but should be used as a spatial relationship between structures or elements.

[0078] The term "semiconductor chip" is used here. A semiconductor device can be a discrete semiconductor device such as a bipolar transistor, several discrete devices such as a pair of power FET switches fabricated together on a single semiconductor chip, or a semiconductor chip can be an integrated circuit with multiple semiconductor devices, such as the multiple capacitors in an A / D converter. The semiconductor device can include passive devices such as resistors, inductors, filters, sensors, or active devices such as transistors. The semiconductor device can be an integrated circuit in which hundreds or thousands of transistors are coupled to form a functional circuit, such as a microprocessor or a memory device. The semiconductor device may also be referred to herein as a semiconductor device or integrated circuit (IC) chip.

[0079] The term "semiconductor encapsulation" is used here. A semiconductor encapsulation comprises at least one semiconductor chip electrically coupled with terminals, and an encapsulation body that protects and covers the semiconductor chip. In some arrangements, multiple semiconductor chips can be encapsulated together. For example, a power metal oxide semiconductor (MOS) field effect transistor (FET) semiconductor device and a second semiconductor device (e.g., a gate driver chip or a controller chip) can be assembled to form a single encapsulated electronic device. Additional components such as passive components like capacitors, resistors, and inductors or coils can be integrated into the packaged electronic device. The semiconductor chip is mounted with an encapsulation substrate that provides conductive lines. A portion of the conductive lines forms the connections for the encapsulated device.In wire-bonded integrated circuit packages, bond wires couple conductive lines of an encapsulation substrate to bond pads on the semiconductor chip. The semiconductor chip may be mounted on the encapsulation substrate with a device side facing away from the substrate and a backside facing the substrate, and is mounted on a chip pad of the encapsulation substrate. The semiconductor package may include an encapsulation body formed by a thermosetting epoxy resin mold compound in a molding process or by using epoxy, plastics, or resins that are liquid at room temperature and subsequently cured. The encapsulation body may provide a hermetic seal for the encapsulated device.The encapsulation body may be formed in a mold using an encapsulation process, but a portion of the leads of the encapsulation substrate is left uncovered during encapsulation, with these exposed lead portions forming the terminals for the semiconductor encapsulation. Semiconductor encapsulation may also be referred to as 'integrated circuit encapsulation,' 'microelectronic package,' or 'semiconductor device encapsulation.'

[0080] Although various examples of the present disclosure have been described above, it should be understood that they have been presented only by way of example and not by way of limitation. Numerous changes to the given examples can be made in accordance with the present disclosure without departing from the spirit or scope of the disclosure. Changes are possible in the described embodiments, and other embodiments are possible within the scope of the claims. Therefore, the validity and scope of the present invention should not be limited by any of the examples described above. Rather, the scope of the disclosure should be determined in accordance with the following claims and their equivalents.

Claims

[1] Method comprising: Determining a number of timer entries in a first group of timer entries; Accessing a first subset of the first group of timer entries containing the number of timer entries; Determining whether any of the first subset of the first group of timer entries corresponds to a timer expiration; and after accessing the first subset of the first group of timer entries: Accessing a timer entry of a second group of timer entries; and Determining whether the timer entry of the second group of timer entries corresponds to a timer expiration; and after accessing the timer entry of the second group of timer entries: Accessing a second subset of the first group of timer entries containing the number of timer entries; and Determine whether any of the first subset of the first group of timer entries corresponds to a timer expiration. [2] The method according to claim 1, wherein the number of timer entries is a first number of timer entries; and the procedure further comprises: Determining a second number of timer entries in the second group of timer entries; and Accessing a subset of the second group of timer entries containing the second number of timer entries between each access to a third group of timer entries. [3] The method of claim 2, further comprising: Receiving an instruction from an application processor core specifying the first number of timer entries and the second number of timer entries. [4] The method of claim 3, further comprising: Resetting the first number of timer entries and the second number of timer entries in response to an instruction from an application processor core. [5] The method of claim 1, further comprising: Storing the timer entries of the first group of timer entries in first respective address ranges in a memory and storing the timer entries of the second group of timer entries in second respective address ranges in the memory. [6] The method of claim 1, wherein determining whether a given timer entry of either the first group of timer entries or the second group of timer entries corresponds to a timer expiration comprises: Comparing a first value stored in the given timer entry with a value of a counter; and Determine whether the given timer entry corresponds to a timer expiration based on the comparison. [7] The method of claim 6, further comprising: if it is determined that the given timer entry corresponds to a timer expiration, sending a function pointer to a processor scheduler and sending a function argument to the processor scheduler. [8] The method of claim 6, further comprising: if it is determined that the given timer entry corresponds to a timer expiration, and if it is determined that the given timer entry is identified as a periodic timer entry, modifying the first value. [9] The method of claim 6, further comprising: if it is determined that the given timer entry corresponds to a timer expiration, sending a function pointer to a processor scheduler and sending a function argument to the processor scheduler using either a first buffer or a second buffer depending on whether the given timer entry is specified as a real-time (RT) timer entry or a non-real-time (non-RT) timer entry. [10] The method of claim 1, further comprising: Receiving data via an MMR (memory managed register) from an application processor core, the data specifying multiple values ​​of a new timer entry; and Storing the new timer entry in a memory in a range of addresses associated with the first group of timer entries, the new timer entry including values ​​based on the data. [11] The method of claim 1, further comprising: Receiving data via an MMR (memory managed register) from an application processor core, the data specifying an index of an existing timer entry of the first group of timer entries to be deleted; Storing the second value in the existing timer entry, where the second value indicates that the existing timer entry is free. [12] Network accelerators, including: a processor core, a processor scheduler communicatively coupled to the processor core; and a timer manager communicatively coupled to the processor scheduler, the timer manager comprising: a memory configured to store a plurality of timer entries comprising a first group of timer entries and a second group of timer entries; a plurality of registers configured to store first settings of a first group of timer entries and to store second settings of a second group of timer entries; and Hardware logic configured to determine whether the first group of timer entries corresponds to a timer expiration more often than the second group of timer entries, according to the first settings and the second settings, and further configured to communicate with the processor core via the processor scheduler in response to accessing the plurality of timer entries. [13] The network accelerator of claim 12, wherein the hardware logic is configured to determine whether a first timer entry of the first group of timer entries corresponds to a timer expiration by comparing a first value in the first timer entry with a value of a counter of the timer manager. [14] The network accelerator of claim 13, wherein the hardware logic is configured to send a processor function pointer and a processor function argument of the first timer entry to the processor scheduler when it is determined that the first timer entry corresponds to a timer expiration. [15] The network accelerator of claim 13, wherein the hardware logic is configured to change the first value based at least in part on determining that the first timer entry is a periodic timer entry when it is determined that the first timer entry corresponds to a timer expiration. [16] Hardware timer manager, including: a memory designed to store multiple timer entries; a plurality of registers configured to store an indication of a first degree of accuracy for a first group of timer entries and to store an indication of a second degree of accuracy for a second group of timer entries; and Hardware logic configured to determine whether the first group of timer entries corresponds to a timer expiration based on the first level of accuracy and determine whether the second group of timer entries corresponds to a timer expiration based on the second level of accuracy, further wherein the first level of accuracy is different from the second level of accuracy. [17] The hardware timer manager of claim 16, wherein the indication of the first degree of accuracy comprises a value defining a number of accesses to the first group of timer entries between each access to the second group of timer entries. [18] The hardware timer manager of claim 16, wherein the plurality of registers comprises a plurality of MMRs (memory mapped registers), the MMRs being coupled to an application processor core configured to write the first precision level indication and the second precision level indication. [19] The hardware timer manager of claim 16, wherein the hardware logic is further configured to Determining that a first timer entry of the first group of timer entries corresponds to a timer expiration; and Sending a processor function pointer and a processor function argument of the first timer entry to a processor core if the first timer entry corresponds to a timer expiration. [20] The hardware timer manager of claim 19, wherein the processor function argument refers to a packet stored in a data memory of a network accelerator, and wherein the hardware timer manager and the processor core are included in the network accelerator.

Images