Hardware timer manager supporting multiple precision levels

Abstract

The invention relates to a hardware timer manager supporting multiple precision levels. A hardware timer manager (100) may be used in a network accelerator. The timer manager may support timers of multiple precision levels. The timer manager may split a total group of supported timer entries into a plurality of precision groups in memory (140). The timer manager may check the programmed number of timer entries in the highest precision group prior to checking a single programmed timer entry in the next group, and repeat this check scheme until checking the timer entries in the lowest precision group, followed by repeating from the beginning.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 553,182, filed February 14, 2024, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] The present disclosure relates generally to timer managers, and more particularly to a timer manager configured to support multiple levels of precision for a timer. Background Art

[0004] In digital systems, it's useful to track when data and tasks enter, leave, and / or travel through the system. This is called a timestamp and can be helpful for synchronizing time references used across multiple connected systems so they operate from the same reference point. It can also be useful to program timers to expire within set time periods. Timers can be used to schedule future tasks and jobs, and to set timeouts for functions.

[0005] For software and firmware, it can be helpful to have a timer manager handle the timestamp and timer functionality and provide a simple interface for user interaction. Some timer managers can be expensive, depending on the number of timers they track, the level of time precision, the timestamp and timer ranges and features supported, and how the timer manager provides events when timers expire. Summary of the Invention

[0006] In one arrangement, a method includes: determining the number of timer entries in a first group of timer entries; accessing a first subset of the first group of timer entries that includes the number of timer entries; determining whether any one 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 in a second group of timer entries; and determining whether the timer entry in the second group of timer entries corresponds to a timer expiration; and after accessing the timer entry in the second group of timer entries: accessing a second subset of the first group of timer entries that includes the number of timer entries; and determining whether any one of the second subset of the first group of timer entries corresponds to a timer expiration.

[0007] In one arrangement, a network accelerator includes: a processor core; a processor scheduler communicatively coupled to the processor core; and a timer manager communicatively coupled to the processor scheduler, wherein the timer manager includes: a memory configured to store a plurality of timer entries, the plurality of timer entries including a first set of timer entries and a second set of timer entries; a plurality of registers configured to store a first setting for the first set of timer entries and to store a second setting for the second set of timer entries; and hardware logic configured to determine, based on the first setting and the second setting, whether the first set of timer entries corresponds to timer expiration more frequently than the second set of timer entries, and further configured to communicate with the processor core via the processor scheduler in response to accessing the plurality of timer entries.

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

[0009] Having thus generally described the invention, reference will now be made to the accompanying drawings, in which:

[0010] Figure 1 is an illustration of an example timer manager adapted in accordance with some embodiments.

[0011] Figure 2 is an illustration of the format of a timer entry within a timer RAM according to some embodiments.

[0012] Figure 3 is an illustration of an example method for managing multiple timer entry groups to provide multiple levels of precision, according to some embodiments.

[0013] Figure 4 is an illustration of an example method for managing timer entry groups in accordance with some embodiments.

[0014] Figure 5 is a diagram of an example network accelerator that may include a timer manager (e.g., Figure 1 Timer Manager).

[0015] Figure 6 is a diagram of an example system on a chip (SoC) that may include Figure 5 An example network accelerator. DETAILED DESCRIPTION

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

[0017] Multiple precision levels allow for both high-precision and low-precision timers while maintaining a low design cost. In some examples, the timer manager operates by splitting the total supported timers into precision groups, checking a programmed number of timers in the highest-precision group before checking timers in the next group, and repeating this checking scheme until the lowest-precision group is checked, then starting over from the beginning. This supports a range of timer expiration cycles without sacrificing precision.

[0018] In some examples, the timer manager provides events when a timer expires by dispatching the events directly to a processor core connected to the system. This can occur automatically after checking that the timer has expired. The timer manager pushes events to a hardware queue to support buffering of multiple timer events when a processor core is unable to service them in a timely manner.

[0019] In some instances, the timer manager supports a timestamp counter with a software interface to synchronize it with other timestamps in the system. The counter can be directly programmed to nudge by an 8-bit signed value (adjust once), increment or decrement periodically (adjust for skew), and increment by one or more times per clock.

[0020] The software interface of the timer manager 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 containing which precision group the timer belongs to. At any time thereafter, the user can read the status of the timer (whether it was successfully added) and the index to keep track of the timer. The user can set whether the new timer is a one-shot timer or a periodic timer. If it is periodic, the timer manager can automatically reconfigure the timer with a new expiration value after the timer expires based on the programmed period of the timer. To delete a timer, the user can program the index of the timer they wish to delete. This fast access provides more bandwidth for the user and allows for the dynamic addition and deletion of timers for applications that set and remove timeout functions, such as when a task is successfully completed before a timeout occurs.

[0021] While no particular advantage is required for any particular embodiment, in some instances, multiple precision groups of a timer manager can enable a wide range of timer accuracy levels and expiration periods while maintaining a low design cost. Having synchronized timestamp functionality can be valuable for time-sensitive networking (TSN) and other network and software applications. Direct event scheduling can be advantageous for highly event-driven systems and software. In these and other instances, a software interface can provide all necessary functionality while maintaining minimal access that allows for more user bandwidth.

[0022] Figure 1 is a diagram of an example timer manager 100 adapted in accordance with some embodiments. The timer manager 100 may be implemented in any suitable manner, such as in a network accelerator that is itself implemented within the circuitry of a system on a chip (SoC). Examples of network accelerators include Figure 5 The network accelerator 500, and the example SoC includes Figure 6 SoC 600. The following describes in more detail Figure 5 and 6 .

[0023] 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 SoC, can configure the timer using a configuration interface 128 to write data to the timer registers 120. In response, the timer hardware logic 110 can add a timer entry to the appropriate group in the timer memory 140. The central counter 122 can be a counter register or other suitable data structure that is incremented or decremented based on cycles of a clock (not shown).

[0024] Timer hardware logic 110 accesses 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 with the 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 an action in response to the expiration. One such action includes adjusting the expiration value in response to determining that the timer entry indicates that it is a periodic timer entry. Another such action includes writing a processor function pointer and processor function arguments from the timer entry to non-real-time FIFO buffer 102 or 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 timer hardware logic 110 may use the data in response to the status data to write to FIFO buffer 102 or FIFO buffer 104.

[0025] FIFO buffer 102 may provide data to a non-real-time scheduler interface, and FIFO buffer 104 may provide data to a real-time scheduler interface. Each of the scheduler interfaces may be included in a processor scheduler (e.g., Figure 5 The processor dispatcher receives the function pointer and arguments and provides them to the processor (e.g., Figure 5 The scheduler may provide orderly arbitration when a timer is executed (e.g., one of the processor cores 508). For example, the scheduler may prioritize real-time events over non-real-time events. In this manner, a processor core may execute a function based on a function pointer and function arguments in response to a timer expiring.

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

[0027] As noted above, individual timer entries may be part of a specific group of timer entries, and each of the groups may correspond to a respective level of precision. The processor core may configure a timer group by writing to the group status register 126 and the group portion register 127. In one example, the group portion register 127 may contain data indicating the timer index at which each of the groups is started. In an example where the timer memory 140 can accommodate 128 (0-127) timer entries, group 1 may begin at index 0, group 2 may begin at index 20, and so on, until group X may begin at index 63 and end at index 127. Of course, these are merely examples, and the scope of embodiments may include any suitable number of timer entries and any suitable grouping of timer entries.

[0028] The group portion register 127 may also contain data indicating the number of timer entries to check in a group before checking a single entry in the next group. This concept is explained in more detail below and configures the level of precision. In other words, some groups may be checked at a different frequency than other groups, and groups checked at a higher frequency are higher precision groups, while groups checked at a lower frequency are lower precision groups.

[0029] In one example, a particular timer group may be disabled by a processor core that writes the starting index of the particular timer group to the total number of timer entries (eg, 128) and sets the check number to zero.

[0030] The group status register 126 can be written to and read by the timer hardware logic 110. The group status register 126 can contain data indicating whether a particular group is full or not full, the first free index of the group, and the next timer index to be checked in the group. As the group becomes full or not full, the timer hardware logic 110 can read and, if appropriate, update the data in the group status register 126 and write new timer entries or delete existing timer entries as the timer check progresses through the index set.

[0031] Register 121 includes go data and software reset data, either of which can be represented as a single bit or multiple bits. For example, the processor core can write a zero or a one to cause a software reset of the timer entry in the timer memory 140. The processor core can also write a zero or a one to instruct the timer hardware logic 110 to stop or start checking the timer entry (go data) in the timer memory 140. The timer hardware logic 110 can read the value from register 121 and then perform the corresponding action.

[0032] although Figure 11. Although not shown in FIG. 1, the timer register 120 may also include one or more registers configured to store the initiator's ID. For example, a processor core writing to the timer register 120 may also write its processor ID to the register.

[0033] The central counter 122 can count up (increment) or count down (decrement) according to a system clock (not shown). In one example, the central counter 122 may include 56 bits indicating a value that increments with each clock cycle and rolls over to an all-ones value after reaching an all-ones value. The timer manager 100 further includes central counter increment and adjustment logic 130, which can adjust the value of the central counter 122 under the control of a processor core (e.g., 508 or 610) or the timer hardware logic 110. Examples of control performed by the logic 130 may include: a value for incrementing the counter value per clock cycle, a single addition of a fixed eight-bit signed value for increasing or decreasing the counter value, a periodically repeated addition or subtraction of the most significant bit of the counter value, and a periodically repeated addition or subtraction of the least significant bit of the counter value. Of course, the scope of the implementation may include any suitable adjustment of the counter value and any number of bits of the central counter 122.

[0034] Register 123 can be configured to contain data for adding a new timer entry to one of the groups in timer memory 140. For example, the data that can be written to register 123 by the processor core may include: the group to which the new timer entry is to be added, the RT or NRT status of the new timer entry, the single iteration or periodic iteration status of the timer entry, a processor function pointer associated with the new timer entry, processor function arguments associated with the new timer entry, etc. During an add operation, the processor core can write to register 123, and timer hardware logic 110 can read the data from register 123 and set the appropriate timer entry in the appropriate group within timer memory 140. Timer hardware logic 110 can assign an index to the timer entry and then write the index to register 124, where the placement of the index in register 124 indicates the successful addition of the timer entry. Timer hardware logic 110 can indicate the index to the processor core. The processor core can read the index from register 124 to track the timer entry and also to determine that the timer entry has been successfully added.

[0035] In addition, the memory space for a particular group is limited, and in some instances, the group may be full. If a particular group is full, the timer hardware logic 110 may write that the particular group is full to the register 124, thereby instructing the processor core to create a new timer in that group.

[0036] Register 125 may be configured to store data associated with deleting an existing timer entry. For example, the processor core may cause a timer entry to be deleted by writing the index of the timer to register 125. Subsequently, timer hardware logic 110 may read the value from register 125 and delete the corresponding timer entry. In one example, timer hardware logic 110 may delete a timer entry by changing the mode of the entry to an idle value, which is relative to Figure 2 Discuss in more detail.

[0037] Figure 2 is a diagram of an example format of timer entries 200 within timer memory 140 according to some embodiments. In some examples, each of the groups may span a specific address range within timer memory 140, and each given timer entry in the group may be placed within that address range. In another example, each timer entry may occupy a word within the address range of its group. Furthermore, the address ranges of the groups may be physically adjacent and / or logically adjacent within timer memory 140. 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. In some examples, this may be physically true. In other examples, the address ranges may be logical, and the logical addresses of each group may be adjacent, whether or not they are physically adjacent.

[0038] exist Figure 2 In the example of , timer entry 200 comprises a 133-bit word that is written to timer memory 140. Timer entry 200 comprises field 210 that may be written by timer hardware logic 110 and may be based on data written to registers 123-124 by the processor core.

[0039] The field RT indicates the priority of the timer entry, for example, whether the timer entry is real-time or non-real-time. The field Offset indicates the value to be added to the timer expiry value when the timer entry expires to indicate the end of the next period of the timer, in the case where the timer entry is a periodic timer entry. The field Expiry Value indicates when the time interval associated with the associated timer expires. In some instances, the Expiry Value field specifies the corresponding value of the central counter 122 at which the timer entry expires. The field Function is a processor pointer that is configured to be sent to the scheduler (via one of the FIFO buffers 102, 104) when the timer entry expires, and which may specify a processor operation and / or code to be executed by the associated processor core. The field Group indicates to which of the groups the timer entry belongs.

[0040] The Mode field indicates the current state of the timer entry, such as idle or running and periodic or single. For example, a value of zero may indicate that the timer entry is idle (e.g., ready to be written to for use as a new timer), such as may be set by deleting the timer entry. On the other hand, if the timer is currently running, the Mode value may be a non-zero value indicating whether the timer entry is a periodic iteration entry or a single iteration entry. As noted above, when a timer is determined to have expired, a periodic timer entry may have its expiration value modified by the value in the Offset field. A single iteration timer entry may be deleted after being determined to have expired. The expiration of a timer may be accompanied by the timer hardware logic 110 transmitting the values from the Function field and the Arg field to the scheduler via one of the FIFO buffers 102, 104.

[0041] The Arg field is a processor function argument that appears with the function pointer in the Function field. In one example, the function pointer may correspond to a specific processing operation, and the Arg value may represent the data memory address of the packet to be processed by the operation, but the scope of the implementation may include any suitable functions and arguments.

[0042] Figure 3 is an illustration of an example method 300 for managing multiple timer entry groups to provide multiple levels of precision, according to some embodiments. Method 300 may be performed, for example, by a timer manager, such as timer manager 100 having timer hardware logic 110. In this example, Group 1-Group 3 may refer to groups of timer entries, such as may be stored in timer memory 140 and configured using data in registers 126-127.

[0043] Furthermore, in this example, C1 refers to the number of checks in Group 1 before a single check is made on the timer entry in Group 2; and C2 refers to the number of checks in Group 2 before a single check is made on the timer entry in Group 3. Figure 3 The example includes three groups, but it should be understood that various embodiments may scale the number of groups as needed. For example, to expand from three groups to four groups, an embodiment may include the number C3, which refers to the number of checks in group 3 before a single check is made on the timer entry in group 4. Figure 1 In the example of , values C1 - C3 may be stored in registers 127 and may be configured by the application processor core through configuration interface 128 .

[0044] At act 302, the timer manager checks the Group 1 entry. For example, the timer hardware logic 110 may compare the expiration value in the first timer entry in Group 1 with the current value of the central counter 122. In one example, 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), then the timer entry has expired; otherwise, the timer entry has not expired. Of course, expiration may be defined in any suitable manner. Since there may not be C1 active timer entries in Group 1, the timer manager check at act 302 may include checking whether the corresponding timer entry is active.

[0045] Action 304 includes decrementing C1 by a value of one, and action 306 includes determining whether C1 has reached zero. If C1 has not reached zero, method 300 loops back to action 302. In other words, method 300 includes performing an integer C1 checks on the entries within Group 1 before checking the single entry of Group 2 at action 308. At action 310, C2 is decremented by a value of one. At action 312, timer hardware logic 110 checks whether C2 has reached zero. If C2 has not reached zero, method 300 loops back to action 302. If C2 has reached zero, method 300 proceeds to action 314 to check the single entry of Group 3. After checking the single entry of Group 3, method 300 loops back to action 302.

[0046] Although not in Figure 3 Although not specifically shown in FIG, the loop of actions 302-306 may include progressing from the address of the first timer entry to the address of the next timer entry with each execution of the loop. Thus, the loop of actions 302-306 may perform checks on C1 individual timer entries within group 1. Similarly, each check of action 308 may include progressing from the address of the first timer entry in group 2 to the address of the next timer entry with each execution of action 308. And, each time action 314 is executed, it may progress from the address of the first timer entry in group 3 to the address of the next timer entry. Of course, in this example, each group includes a finite number of entries, so once the end of a group's address range is reached, the next check within that group may proceed to the first timer entry in that group.

[0047] Furthermore, in this example, method 300 can be executed continuously as long as timer manager 100 is powered on and not reset. In other words, when quantity C1 (or C2, or C3) reaches zero, such quantity can be reinitialized back to the original and maximum quantity C1 (or C2, or C3). In some examples, method 300 can be stopped by the application processor core changing the carry bit in register 121 or by causing a software reset by changing the value in register 121.

[0048] One way to understand method 300 is that it includes nested loops. For example, the inner nested loop represents a check of Group 1 timer entries. The middle loop includes a check of Group 2 timer entries, and the outer loop includes a check of Group 3 timer entries. Due to the nested loop structure, Group 1 timer entries are checked more frequently than Group 2 timer entries, and Group 2 timer entries are checked more frequently than Group 3 timer entries. 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.

[0049] The following is an example use case of method 300 assuming a clock rate of 2 ns, where at each clock cycle, timer hardware logic 110 performs a check on a timer entry, such as in one of actions 302 , 308 , or 314 :

[0050] Timer entry / group checking algorithm (3 groups)

[0051] – C1 = number of checks in group 1

[0052] – C2 = number of checks in group 2

[0053] – Check C1 timer entries in group 1, then check timer entries in group 2

[0054] – Repeat until C2 timer entries in group 2 have been checked

[0055] – Check for timer entries in group 3 (adjacent to group 2 check)

[0056] – Repeat by returning to set 1

[0057] Timer group accuracy calculation

[0058] –Variable definition

[0059] Period = clock cycle

[0060] N1 = number of timer entries in group 1

[0061] N2 = number of timer entries in group 2

[0062] N3 = number of timer entries in group 3

[0063] C1 = number of checks in group 1

[0064] C2 = number of checks in group 2

[0065] P1 = Accuracy of Group 1

[0066] P2 = Accuracy of Group 2

[0067] P3 = Group 3 accuracy

[0068] –Accuracy formula

[0069] P1 = Period * (N1 + (N1 / C1) + (N1 / (C2*C1)))

[0070] P2 = Period * (N2 + (N2 * C1) + (N2 / C2))

[0071] P3 = Period * (N3 + (N3 * C2 * C1) + (N3 * C2))

[0072] – Example accuracy calculation

[0073] Period = 2ns

[0074] N1 = 20

[0075] N2 = 30

[0076] N3=40

[0077] C 1=10

[0078] C2=5

[0079] ·P1=2ns*(20+(20 / 10)+(20 / (5*10)))=44.8ns

[0080] ·P2=2ns*(30+(30*10)+(30 / 5))=672ns

[0081] ·P3=2ns*(40+(40*5*10)+(40*5))=4480ns

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

[0083] Figure 4 is a diagram of an example method 400 for managing timer entry groups according to some embodiments. The method 400 may be performed by a timer manager, e.g. Figure 1 The example method 400 refers to three precision groups, but it should be understood that the scope of the embodiment can be scaled to an appropriate number of precision groups.

[0084] At act 402, the timer manager accesses a first plurality (N) of timer entries of a first group to determine whether some of the first plurality of timer entries are active and to determine the expiration of one or more of the first plurality of active timer entries. For example, act 402 may be illustrated by a loop of acts 302-306, where C1 corresponds to the first plurality, N. The access operation in method 400 may include performing a check on the timer entries within the group, such as by comparing the corresponding expiration values of the active timer entries with the current value of the counter.

[0085] Action 402 may further include performing appropriate action in response to determining that the timer entry has expired. In some examples, a timer entry expires if the central counter exceeds an expiration value that is less than half of the maximum value of the central counter, taking into account rollover of the counter. Additionally, for implementations that support both real-time (RT) and non-real-time (NRT) timer entries, a given timer entry may be considered unexpired if it is NRT and the NRT FIFO buffer is full, or if it is RT and the RT FIFO buffer is full, and the timer entry is not in the highest precision level group. Examples of FIFO buffers include Figure 1 FIFO buffers 102 and 104 that receive data from the timer hardware logic 110 and pass the data to the processor scheduler (e.g., Figure 5 The interface of the scheduler 507).

[0086] When a timer entry expires, the timer manager can perform appropriate expiration actions. In one example, the timer manager can push the values of the Function and Arg fields from the expired timer entry to the RTFIFO buffer or the NRTFIFO buffer as needed. If the entry is a periodic entry as determined by the Mode field, the timer manager can calculate a new expiration value based on the Offset and ExpiryValue fields and then write the new value to the ExpiryValue field. If the timer entry is a one-shot timer entry as determined by the Mode field, the timer manager can delete the timer entry by changing the Mode field to Idle.

[0087] At act 404, the timer manager accesses the first timer entry of the second set to determine whether the first timer entry is active and to determine expiration of the first timer entry. Figure 3 An example is shown in , where the timer manager moves from the loop of actions 302-306 to perform a check at action 308. If the check timer entry has expired, the timer manager may perform the appropriate expiration action, as described above.

[0088] At act 406, the timer manager accesses a second plurality (N) of timer entries in the first set to determine whether some of the second plurality of timer entries are active and to determine the expiration of any active entries in the second plurality of timer entries. Figure 3 An example is given where act 312 includes looping back to act 302 after checking a single entry of group 2. The second plurality of timer entries may or may not be the same individual timer entries as the first plurality of timer entries at act 402. For example, the number of checks performed in group 1 at acts 402 and 406 may be different than the number of active timer entries within group 1. As noted above, some embodiments may include checking the timer entry index index by index (e.g., by address), incrementing the timer entry index with each check, and looping back to the first timer entry once all active timer entries in the group have been checked. The number of active timer entries in a group may be greater, less than, or equal to the number of checks performed in the loop.

[0089] If a given timer entry in the second plurality of timer entries has expired, the timer manager may perform an appropriate expiration action.

[0090] At action 408, the timer manager accesses the second timer entry of the second set to determine the expiration of the second timer entry. Figure 3 An example is described where, after completing the inner loop of actions 302-306, a single timer entry of group 2 is checked. If the second timer entry has expired, the timer manager may perform the appropriate expiration action.

[0091] At action 410, the timer manager accesses the third plurality of timer entries of the first group to determine whether some of the third plurality of timer entries are active and to determine the expiration of any active entries in the third plurality of timer entries. If a given timer entry in the third plurality of timer entries has expired, the timer manager may perform appropriate expiration actions. Action 410 illustrates that the check operation may repeat the loop of actions 302-306 after performing a check on the group 2 entries.

[0092] At action 412, the timer manager accesses the third timer entry of the second group to determine the expiration of the third timer entry. If the third timer entry has expired, the timer manager may perform appropriate expiration actions. Action 412 illustrates that each time the loop of actions 302-306 is executed, it may progress to checking the group 2 timer entry.

[0093] Action 414 includes accessing a fourth timer entry of the third set to determine the expiration of the fourth timer entry. If the fourth timer entry has expired, the timer manager may perform an appropriate expiration action. An example of action 414 is described in Figure 3 , where the timer manager checks only a single timer entry for group 3 in response to having already checked C2 number of timer entries for group 2.

[0094] In the example of method 400 , the method may continue execution, such as by progressing to act 402 in response to act 414 having completed.

[0095] Figure 5 is a diagram of an example network accelerator 500 that may include a timer manager (e.g., Figure 1 The example network accelerator 500 may be implemented in a system on a chip (SoC), such as a Figure 6 The example is implemented within the SoC 600.

[0096] When implemented in a system such as the network accelerator 500 and the SoC 600, the timer manager 100 may provide multiple timer groups, each of which has a different level of precision. Figure 3 An example of a lower-precision operation facilitated by group 3) of [ 15 ] includes a Transmission Control Protocol (TCP) retransmission timer. For example, the network accelerator 500 may transmit a TCP packet and then initialize a timer entry with a conservative arrival time of an acknowledgment packet (e.g., on the order of seconds). If the network accelerator 500 determines that an acknowledgment packet has been received before determining that the timer entry has expired, the network accelerator 500 may cause the timer manager to delete the timer entry. However, if the network accelerator 500 determines that an acknowledgment packet has not been received after determining that the timer entry has expired, the network accelerator 500 may perform a TCP retransmission.

[0097] In an example of medium-precision operation, the network accelerator 500 may perform audio-video bridging (AVB). In example AVB operation, AVB packets are sent at regular intervals and in allocated time slots to guarantee a specific latency. 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 to 2 ms and a second periodic timer entry to 50 ms. The first periodic timer entry may include an Offset field corresponding to 2 ms, a Function field corresponding to packet transmission, and an Arg field pointing to the address of the Class A packet. Similarly, the second periodic timer entry may include an Offset field corresponding to 50 ms, a Function field corresponding to packet transmission operation, and an Arg field pointing to the address of the Class B packet.

[0098] In the example of high-precision operations, the timer manager can facilitate time synchronization for time-sensitive networking (TSN). High-precision operations can be on the order of nanoseconds. For example, network accelerator 500 may include a first port, and another network accelerator, perhaps in another SoC, may include a second port. Network accelerator 500 may use its timer manager to synchronize timestamps from the first port to the second port. Such operations may include receiving a timestamped packet from the other network accelerator at a first port of the first network accelerator and sending the timestamped packet from network accelerator 500 to the second port of the other network accelerator. The processor core of network accelerator 500 may perform this sending and receiving of timestamped packets to ultimately establish synchronization.

[0099] Some embodiments may provide advantages over other embodiments. For example, the timer managers discussed herein may provide multiple levels of accuracy by checking different groups using different check frequencies. In contrast, other systems may include a timer manager that checks all of its timer entries at the same frequency, thereby wasting some logic resources by providing a higher check frequency than would be appropriate for some lower-frequency operation. Figure 1 The timer manager can be implemented using hardware suitable for providing the desired number of groups and the desired level of precision for the groups, thereby allowing for more efficient use of logic. More efficient use of logic can result in a smaller number of transistors implementing the logic, thereby saving semiconductor area.

[0100] also, Figure 1The example timer manager 100 may include registers 123-127 to allow for configuration of groups and individual timer entries. Such registers may be accessed by an application processor core of the SoC 600 that is external to the network accelerator 500, and may also be accessed 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 configure groups and timer entries. The availability of registers 123-127 to the processor cores may allow for flexibility and efficiency in configuring groups and timer entries.

[0101] continue Figure 5 The network accelerator 500 includes a plurality of processor cores 508, which may include any suitable processor core, general purpose or otherwise, and have 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 noted above, the timer manager 100 may perform expiration actions, which include transmitting a function indication and arguments to the scheduler 507. The scheduler 507 may then pass the function indication and arguments to one of the processor cores 508. In addition, the processor core 508 may include functionality for configuring the registers 120. The processor core 508 may fetch instructions from the instruction memory 506 via the bus 593 or receive an instruction pointer from the direct memory access (DMA) interface 513.

[0102] The application processor core (e.g., in 610) can offload network functions to the network accelerator 500 so that the application processor core itself does not have to perform the functions. Configuration interface 503 allows the application processor core to communicate with any of the components of the network accelerator 500. For example, the application processor core can communicate via bus 591, and such communication can write to registers 120 and / or cause instructions to be transferred to one of the processor cores 508.

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

[0104] Packet switched interface (PSI) endpoints 504 and 516 can receive packets and transfer packets into and out of the network accelerator 500 via buses 592 and 594, respectively. Upon receiving a packet, the PSI endpoints 504, 516 can coordinate with the memory manager (MMS) 515 to cause space to be allocated within the data memory 511. Once space in the data memory 511 is allocated, the PSI endpoints 504, 516 can then store the packet in the data memory 511 within the allocated address range.

[0105] The network accelerator 500 includes two PSI endpoints 504, 516 for increasing bandwidth, where the PSI endpoint 504 is dedicated to Ethernet usage and the PSI endpoint 516 is dedicated to other packet protocols. However, various embodiments may be adapted to more or fewer PSI endpoints as needed.

[0106] In some examples, the application processor core can configure actions to be taken for particular packets by writing to a lookup table entry in the lookup table memory 512. When a packet is received and ready for processing, the processor core 508 can cause one of the lookup table engines 505 to perform a lookup table operation within the lookup table entry in the lookup table memory 512. The lookup table operation can result in subsequent actions, such as events sent by the lookup table engine 505 to the scheduler 507, where such events can result in actions by the processor core 508.

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

[0108] A larger system (eg, SOC 600 ) implementing network accelerator 500 may transmit interrupts to processor core 508 via interrupt interface 514 and bus 595 .

[0109] Priority manager 517 is implemented to prioritize some packets over other packets based on configuration data from the application processor core. For example, some packets may include data indicating priority, and priority manager 517 may perform priority functions such as enforcing an order in which data memory allocations are made for the packets based on their priority.

[0110] Various components are communicatively coupled within the network accelerator 500 via a data switch 509 .

[0111] Figure 6 is a diagram of an example SOC 600 according to some embodiments. The network accelerator 500 may be implemented on the SOC 600, but the scope of the embodiments may include the network accelerator 500 being implemented in any suitable system for offloading network functions from any suitable processor core.

[0112] In this example, Ethernet packets may be received by Ethernet packet switch 620. Packets of other protocols, such as a control area network (CAN), may be received by packet switch 625. However, the scope of the embodiment may include more packet switches or fewer packet switches to handle more or fewer communication protocols as needed.

[0113] Continuing with packet receive operations, 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 valid 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 channel 635.

[0114] As noted above, the network accelerator 500 can perform network functions on packets, which allows the network functions to be offloaded from the rest of the SOC 610. Examples of operations that the network accelerator 500 can perform include, but are not limited to, reformatting packets from one protocol to another (e.g., Ethernet to CAN or vice versa), dropping packets, forwarding packets to different endpoints, sending payload data from packets to components of the rest of the SOC 610, and so on. For outgoing packets, the network accelerator 500 can transfer such packets to the packet DMA 630 via one of the buses 592, 594, to the Ethernet packet switch 620 or the packet switch 625. The network accelerator 500 can also transfer payload data from the packets to the rest of the SOC 610 via the bus 593.

[0115] The rest of the SOC 610 can be configured as needed. For example, the rest of the SOC 610 can include one or more processor cores (eg, an application processor core, a digital signal processing core, etc.), system memory, a memory interface, or an accelerator.

[0116] The present disclosure is described with reference to the accompanying drawings. The figures are not drawn to scale and are provided solely to illustrate the present disclosure. Several aspects of the present disclosure are described below with reference to example applications for illustration. It should be understood that many specific details, relationships, and methods are set forth to provide an understanding of the present disclosure. The present disclosure is not limited by the illustrated ordering of actions or events, as some actions may occur in a different order and / or simultaneously with other actions or events. In addition, not all illustrated actions or events are required to implement the methods according to the present disclosure.

[0117] Unless otherwise indicated, corresponding numbers and symbols in the different figures generally refer to corresponding parts. The figures are not necessarily drawn to scale. In the drawings, similar reference numerals refer to similar elements throughout, and the various features are not necessarily drawn to scale. In the following discussion and claims, the terms "including," "includes," "having," "has," "with," or variations thereof are intended to be inclusive in a manner similar to the term "comprising," and should therefore be interpreted as meaning "including, but not limited to..." In addition, the terms "coupled," "couple," and / or "couples" are intended to include indirect or direct electrical or mechanical connections, or combinations thereof. For example, if a first device is coupled to or electrically coupled with a second device, the connection may be a direct electrical connection, or an indirect electrical connection via one or more intervening devices and / or connections. Elements electrically connected to intervening wires or other conductors are considered coupled. Terms such as "top," "bottom," "front," "rear," "above," "above," "below," and "below" may be used in this disclosure. These terms should not be understood as limiting the position or orientation of structures or elements, but are used to provide spatial relationships between structures or elements.

[0118] The term "semiconductor die" is used herein. A semiconductor device may 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 die, or a semiconductor die may be an integrated circuit having multiple semiconductor devices, such as multiple capacitors in an A / D converter. A semiconductor device may include passive devices such as resistors, inductors, filters, sensors, or active devices such as transistors. A semiconductor device may be an integrated circuit having hundreds or thousands of transistors coupled to form functional circuitry such as a microprocessor or memory device. A semiconductor device may also be referred to herein as a semiconductor device or an integrated circuit (IC) die.

[0119] The term "semiconductor package" is used herein. A semiconductor package has at least one semiconductor die electrically coupled to a terminal and has a package body that protects and covers the semiconductor die. In some arrangements, multiple semiconductor dies may be packaged 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 die or a controller die) may be packaged together to form a single packaged electronic device. Additional components such as passive components (e.g., capacitors, resistors, and inductors or coils) may be included in the packaged electronic device. The semiconductor die is mounted with a package substrate that provides conductive leads. A portion of the conductive leads forms a terminal for the packaged device. In a wire-bonded integrated circuit package, bonding wires couple the conductive leads of the package substrate to bonding pads on the semiconductor die. The semiconductor die may be mounted to the package substrate with the device side surface facing away from the substrate and the back side surface facing the die pads of the package substrate and mounted to the die pads. A semiconductor package may have a package body formed from a thermosetting epoxy molding compound during a molding process or by using an epoxy, plastic, or resin that is liquid at room temperature and subsequently cures. The package body provides a hermetic enclosure for the packaged device. The package body may be formed in a mold using an encapsulation process; however, portions of the leads of the package substrate are uncovered during encapsulation; these exposed lead portions form terminals for the semiconductor package. A semiconductor package may also be referred to as an "integrated circuit package," "microelectronic device package," or "semiconductor device package."

[0120] Although various examples of the present disclosure have been described above, it should be understood that the examples have been presented by way of example only and not limitation. Without departing from the spirit or scope of the present disclosure, numerous changes may be made to the disclosed examples according to the disclosure herein. Within the scope of the claims, modifications may be made in the described embodiments, and other embodiments are possible. Therefore, the breadth and scope of the present invention should not be limited by any of the examples described above. On the contrary, the scope of the present disclosure should be defined according to the appended claims and their equivalents.

Claims

1. A method comprising: determining a number of timer entries in a first set of timer entries; accessing a first subset of the first set of timer entries comprising the number of timer entries; determining whether any one of the first subset of the first set of timer entries corresponds to a timer expiration; as well as After said accessing of said first subset of said first set of timer entries: accessing a timer entry in a second set of timer entries; and determining whether the timer entry in the second set of timer entries corresponds to a timer expiration; and After said accessing of said timer entry in said second set of timer entries: accessing a second subset of the first set of timer entries comprising the number of timer entries; and A determination is made as to whether any one of the second subset of the first set of timer entries corresponds to a timer expiration.

2. The method according to claim 1, wherein: said number of timer entries being a first number of timer entries; and The method further comprises: determining a second number of timer entries in the second set of timer entries; and A subset of the second set of timer entries including the second number of timer entries is accessed between each access to the third set of timer entries.

3. The method according to claim 2, further comprising: An instruction is received from an application processor core specifying the first number of timer entries and the second number of timer entries.

4. The method according to claim 3, further comprising: Responsive to an instruction from an application processor core, the first number of timer entries and the second number of timer entries are reset.

5. The method according to claim 1, further comprising: The timer entries in the first set of timer entries are stored to a first corresponding address range within a memory, and the timer entries in the second set of timer entries are stored to a second corresponding address range within the memory.

6. The method of claim 1 , wherein determining whether a given timer entry in the first set of timer entries or the second set 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; as well as A determination is made based on the comparison whether the given timer entry corresponds to a timer expiration.

7. The method according to claim 6, further comprising: In response to determining that the given timer entry corresponds to a timer expiration, a function pointer is transferred to a processor scheduler, and function arguments are transferred to the processor scheduler.

8. The method according to claim 6, further comprising: In response to determining that the given timer entry corresponds to a timer expiration, and in response to determining that the given timer entry is identified as a periodic timer entry, the first value is modified.

9. The method according to claim 6, further comprising: In response to determining that the given timer entry corresponds to a timer expiration, based on whether the given timer entry is indicated as a real-time (RT) timer entry or a non-real-time (non-RT) timer entry, a function pointer is transferred to a processor scheduler using a first buffer or a second buffer and function arguments are transferred to the processor scheduler.

10. The method of claim 1, further comprising: receiving data from an application processor core via a memory management register (MMR), wherein the data indicates a plurality of values for a new timer entry; as well as The new timer entry is stored in memory in an address range associated with the first set of timer entries, wherein the new timer entry includes a value based on the data.

11. The method according to claim 1 , further comprising: receiving data from an application processor core via a memory management register (MMR), wherein the data indicates an index of an existing timer entry in the first set of timer entries to be deleted; A second value is stored in the existing timer entry, wherein the second value indicates that the existing timer entry is idle.

12. A network accelerator, comprising: Processor core; a processor scheduler communicatively coupled to the processor core; as well as a timer manager communicatively coupled to the processor scheduler, wherein the timer manager comprises: a memory configured to store a plurality of timer entries, the plurality of timer entries comprising a first set of timer entries and a second set of timer entries; a plurality of registers configured to store first settings for the first set of timer entries and to store second settings for the second set of timer entries; as well as Hardware logic is configured to determine, based on the first setting and the second setting, whether the first set of timer entries corresponds to timer expiration more frequently than the second set of timer entries, and is 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 in the first set 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 transmit a processor function pointer and a processor function argument of the first timer entry to the processor scheduler upon determining 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 determining that the first timer entry corresponds to a timer expiration.

16. A hardware timer manager comprising: a memory configured to store a plurality of timer entries; a plurality of registers configured to store an indication of a first level of precision for a first set of timer entries and to store an indication of a second level of precision for a second set of timer entries; as well as Hardware logic configured to determine whether the first set of timer entries corresponds to a timer expiration based on the first level of precision and to determine whether the second set of timer entries corresponds to a timer expiration based on the second level of precision, further wherein the first level of precision is different from the second level of precision.

17. The hardware timer manager of claim 16, wherein the indication of the first level of precision comprises a value defining a number of accesses to the first set of timer entries between each access to the second set of timer entries.

18. The hardware timer manager of claim 16, wherein the plurality of registers comprises a plurality of memory mapped registers (MMRs), wherein the MMRs are coupled to an application processor core, the application processor core being configured to write the indication of the first precision level and the indication of the second precision level.

19. The hardware timer manager of claim 16, wherein the hardware logic is further configured to: determining that a first timer entry in the first set of timer entries corresponds to a timer expiration; and In response to the first timer entry corresponding to expiration of a timer, a processor function pointer and processor function arguments of the first timer entry are transferred to a processor core.

20. The hardware timer manager of claim 19, wherein the processor function argument references 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