WO2024092192A1

WO2024092192A1 - Device control register including a register lock

Info

Publication number: WO2024092192A1
Application number: PCT/US2023/078014
Authority: WO
Inventors: Peter Korger
Original assignee: Kandou Labs SA; Kandou US Inc
Current assignee: Kandou Labs SA; Kandou US Inc
Priority date: 2022-10-27
Filing date: 2023-10-27
Publication date: 2024-05-02
Anticipated expiration: 2025-04-27

Abstract

A device control register is disclosed that stores a set of flags that set an access control level of an apparatus. The device control register includes a lock flag that controls access to the device control register itself, meaning that the device control register is self-referential as once locked the value of the lock flag cannot be changed until a cold reset is performed. The device control register can also include one or more interface flags that control bus leader access to a data bus of the apparatus and/or to functionality of the interface itself. The interface flag(s) is/are not accessible when the device control register is locked.

Description

DEVICE CONTROL REGISTER INCLUDING A REGISTER LOCK

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Application No. 63/381,265, filed October 27, 2022, entitled ‘DEVICE CONTROL REGISTER INCLUDING A REGISTER LOCK ', which is hereby incorporated herein by reference in its entirety for all purposes.

REFERENCES

[0002] The following references are herein incorporated by reference in their entirety for all purposes:

[0003] PCI Express Base Specification Revision 6.0.1, Version 1.0, September 13, 2022, accessible at pcisig[dot]com/specifications.

[0004] PCI Express Retimer Test Specification Revision 4.0. Version 1.0, June 10, 2022, accessible at pcisig[dot]com/specifications.

[0005] U.S. Application No. 13/895,206, filed May 15, 2013, which granted as U.S. Patent No. 9,288,082 on March 15, 2016, entitled “Circuits for Efficient Detection of Vector Signaling Codes for Chip-To-Chip Communication Using Sums of Differences"’, naming Roger Ulrich and Peter Hunt (referred to herein as [Ulrich]).

BACKGROUND

[0006] As signals propagate over wires, they tend to degrade - that is, the signal to noise ratio decreases. This attenuation of a signal is often measured in decibels (dB) and tends to increase with the length of the wire that the signal is transmitted over.

[0007] Many electronics standards define a maximum loss for signals transmitted between an upstream component and a downstream component. For example, the Peripheral Component Interconnect Express (PCIe) 5.0 standard gives a -36dB loss budget at 16GHz for transmission from an upstream component (ty pically a root complex or switch) to a downstream component (typically an endpoint or switch). Failure to comply with this loss budget results in non- compliance with the standard, which is undesirable. However, it can be difficult to meet a loss budget in practice, particularly in the case of longer wires and higher data rates.

[0008] To resolve this issue, a retimer can be used. A retimer is a component that is located in the signal path between the upstream component and the downstream component. The retimer breaks the link between the upstream component and downstream component into two entirely separate links. The retimer is configured to condition the signal it receives via an upstream pseudo-port before transmitting the conditioned signal out via a downstream pseudo-port. Typically, a retimer equalizes the incoming signal and recovers the clocking of the incoming signal, such that the output of the retimer is a high amplitude, low noise and low jitter signal. A retimer can thus significantly reduce the total losses between the upstream and downstream components, bringing a previously non-compliant link within specification.

BRIEF DESCRIPTION

[0009] As with many components, a retimer includes debugging capabilities that enable an authorised party (e.g. a manufacturer) to access a debugging mode of operation. In the debugging mode, access is provided at a deeper level than is provided during normal operation (a.k.a. mission mode). Specifically, access to registers or other components on the retimer during debugging mode can be granted in a manner that bypasses the retimer CPU. hence also bypassing any protections built in to the operation of the CPU that prevent register access that could enable the retimer to be compromised (e.g. hacked). An unauthorised party operating a retimer in debugging mode could snoop on traffic carried by the retimer, inject commands and/or data for nefarious purposes, and the like.

[0010] It is therefore desirable to provide a technique that enables a debugging mode of a retimer or other component to be accessed when it is appropriate to do so, but otherwise prevents debugging mode access. It is also desirable to provide an ability to customise an access level when in normal operating mode so as to be able to define what ‘normal access' means.

[0011] A device control register is disclosed that stores a set of flags that set an access control level of an apparatus. The device control register includes a lock flag that controls access to the device control register itself, meaning that the device control register is self-referential as once locked the value of the lock flag cannot be changed until a cold reset is performed. The device control register can also include one or more interface flags that control bus leader access to a data bus of the apparatus and/or to functionality of the interface itself. The interface flag(s) is/are not accessible when the device control register is locked. The apparatus can be a retimer, e.g. a PCIe retimer, a redriver, or another electronic component.

[0012] An embodiment provides an apparatus comprising: a device control register located on a die of the apparatus, configured to store a plurality of device security configuration data values for selectively enabling device functions, and including a register lock portion configured to store a multi-bit register lock flag; a data bus interface circuit configured to obtain the device security configuration data values from a data bus on the die and to provide the device security configuration data values to the device control register; and a write signal generation circuit having a security' verification logic gate connected to the register lock portion, and configured to selectively generate, in response to the multi-bit register lock flag, a write signal to cause the device control register to store the provided device security configuration data values.

[0013] An embodiment provides a method comprising: receiving device security configuration data, including a multi-bit register lock flag, via a data bus, for storage in a device control register of an integrated circuit die; and using a security verification logic gate connected to a register lock portion of the device control register to selectively enable writing the received device security configuration data to the device control register, the writing including writing the multi -bit register lock flag to the register lock portion.

[0014] In an embodiment a method is provided in which at least two device control register write operations are performed in a sequence of write operations. A first device control register write operation of the at least two device control register w rite operations is performed while a multibit register lock flag is in an unlocked state. A second device control register write operation of the at least two device control register write operations sets a multi -bit register lock flag to a locked state. The first and second device control register write operations each write to a device control register. The locked state prevents further write operations to the device control register from succeeding. The second device control register write operation occurs after the first device control register w rite operation.

[0015] The first device control register write operation can occur as part of a first boot process. The second device control register write operation can occur as part of a subsequent boot process. The subsequent boot process can take place after the first boot process. The subsequent boot process can allow access to a debugging mode. This enables a low security' mode in which the device control register is in an unlocked state to be accessible while first boot (setup) and debugging operations are carried out, e.g. by a manufacturer or other such party’ in a controlled environment. Once the setup and debugging has been completed, a high security mode can be activated by setting the multi-bit lock flag to a locked state, meaning that in the field it is difficult for an unauthorised party' to enter the low' security' state.

BRIEF DESCRIPTION OF FIGURES

[0016] FIG. 1 is a block diagram of a retimer suitable for implementing embodiments described herein.

[0017] FIG. 2 is a block diagram of a tile of a retimer suitable for implementing embodiments described herein. [0018] FIG. 3 is a schematic drawing of contents of a memory external to a retimer, which memory' can hold a data package for w riting to components of the retimer.

[0019] FIG. 4 is a block diagram of a two-tile retimer suitable for implementing embodiments described herein.

[0020] FIG. 5 is a block diagram of the follower tile of the tw o-tile retimer of FIG. 4.

[0021] FIG. 6 is a block diagram of a four-tile retimer suitable for implementing embodiments described herein.

[0022] FIG. 7 is a block diagram of select components of a tile of a retimer that shows a device control register of the retimer, according to an embodiment.

[0023] FIG. 8 is a block diagram of a device control register of a retimer, according to an embodiment.

[0024] FIG. 9 is a flow chart depicting a process for configuring the device control register of Fig.

8, according to an embodiment.

[0025] FIGs. 10A and 10B are block diagrams showing certain elements of the device control register of Fig. 8 in more detail, according to an embodiment.

[0026] FIG. 11 is a block diagram illustrating couplings between the device control register of Fig. 8 and other components of the retimer, according to an embodiment.

[0027] FIG. 12 is a table show ing a set of possible states for the device control register shown in various earlier figures, according to an embodiment.

[0028] FIG. 13 is a flow diagram showing a process for operating a retimer as described herein, according to an embodiment.

DETAILED DESCRIPTION

[0029] At times in this specification reference is made to the Peripheral Component Interconnect Express (PCIe) standard. This is to assist in the understanding of this disclosure by describing certain features in the context of a particular standard. However, it should be appreciated that, unless expressly stated otherwise, teaching herein has applicability outside of the PCIe standard.

[0030] The following disclosure focusses on a retimer as an example of a component that can make use of techniques disclosed herein. These techniques can however also be applied to other electronic components, e.g. a redriver.

[0031] Fig. 1 shows in schematic form a system 100 incorporating a retimer 110. Retimer 110 is coupled to an upstream component 105 that is typically a root complex or a switch. This coupling is via upstream pseudo-port 120a of retimer 110. Similarly, retimer 110 is coupled via downstream pseudo-port 120b to a downstream component 115, typically a switch or endpoint. In this disclosure, physical layer entities such as pseudo-ports may be alternatively referred to as PHYs.

[0032] It is thus apparent from Fig. 1 that retimer 110 functions to divide a link between upstream component 105 and downstream component 115 into two parts. Retimer 110 is configured to condition the signal received via upstream pseudo-port 120a and to provide a clean signal with low jitter and good signal to noise ratio as an output of downstream pseudo-port 120b. Retimer 110 is bi-directional, and thus is also capable of conditioning a signal received as an input to downstream pseudo-port 120b. In this case, the clean output signal would be sent out via upstream pseudo-port 120a.

[0033] Fig. 2 shows retimer 110 in schematic form in additional detail. For ease of understanding, some components of retimer 110 have been omitted.

[0034] Retimer 110 includes a CPU core 200, also referred to herein as a processor. CPU core 200 is configured to perform various tasks to support the function of retimer 110. One such task is the loading of firmware from external non-volatile memory to boot ROM 205 during a boot process. CPU core 200 acts in accordance with instructions stored in instruction RAM 210 and operates on data stored in data RAM 215. CPU core 200 is also coupled to interrupt request (IRQ) controller 220 to enable CPU core 200 to receive interrupt requests from other components of retimer 100 or from external components.

[0035] CPU core 200 is also coupled to Advanced Peripheral Bus (APB) interconnect 225. The APB interconnect 225 enables CPU core 200 to communicate with other components of retimer 110 that are coupled to this bus - reference is made to Fig. 2 in this connection. It will be appreciated that APB interconnection 225 can be replaced with an alternative bus, e.g. AHB, without departing from the scope of this disclosure.

[0036] APB interconnect 225 also enables other components of retimer 110 to communicate with instruction RAM 210 directly in a controlled manner (see ‘access restriction’ in Fig. 2). This ensures that only components that should be able to access instruction ram 210 can do so, and further that instructions that any such components place in instruction ram 210 are legitimate. This access restriction could be bypassed in a debugging mode and is thus an example of a security risk that needs to be mitigated.

[0037] Retimer 110 also includes a non-volatile read-only memory that could be a one-time programmable (OTP) memory 230 as shown in Fig. 2. Other forms of non-volatile ROM could alternatively be used. OTP memory 230 stores, among other things, a public key, or hash of a public key, that is usable by CPU core 200 to check that firmware is genuine as it is loaded by CPU core 200. [0038] Firmware is loaded from an external non-volatile memory. Here, ‘external’ refers to the memory' being located off-die, i.e. it is not part of the leader die 235 that CPU core 200 is part of. In the illustrated embodiment the external non-volatile memory is a SPI flash memory 240. CPU core 200 communicates with SPI flash 240 via an SPI bus, with the corresponding SPI leader 245 being connected to APB interconnect 225 to provide the complete communication channel between CPU core 200 and SPI flash 240. This configuration is provided as an example and is not the only possible configuration. For example, external non-volatile memory could instead be an EEPROM and in that case CPU core 200 could communicate with the EEPROM via an I²C bus (see I²C bus leader 250 in Fig. 2) that is coupled to APB interconnect 225. Further variations are possible, and it should be understood that any variation that enables CPU core 200 to communicate with external non-volatile memory' is within the scope of this disclosure.

[0039] It is noted that the PCIe standard as applicable to retimers requires an I²C bus to be present. However, it has been recognised that I²C is a relatively slow interface such that problems can arise when loading firmware from the external memory. Specifically, an I²C bus and EEPROM may make it difficult to meet certain timing requirements of the PCIe specification. For this reason, a SPI bus and SPI flash 240 can be used to significantly reduce firmware loading times by virtue of the fact that an SPI interface offers a higher data transfer rate than an I²C interface. Given this, it is contemplated that in some implementations the I²C bus could be omitted entirely.

[0040] Retimer 110 also includes timer 255, general purpose input/output pin(s) (GPIO) 260 and system management bus (SMBus) 265. These components are all coupled to APB interconnect 225 to facilitate communication with other components of retimer 110.

[0041] Timer 255 provides a programmable timing capability, e.g. to allow the performance of periodic tasks between which a low power state may be entered. GPIO 260 provides one or more general purpose pins that can be controlled by software to be used in some manner, e g. to extend the functionality of retimer 110 in some way. SMBus 265 provides a facility for communicating information (e.g. status, configuration, device name, type, etc.) about devices coupled to retimer 1 10 and also for transmitting commands to said devices. SMBus 265 operates on an I²C-ty pe interface, e.g. a Tw o-Wire Interface (TWI). One or more of timer 255, GPIO 260 and SMBus 265 could be omitted, or replaced with another component of similar functionality', without departing from the scope of this disclosure.

[0042] Retimer 110 further includes one or more physical layer components (PHYs) 270. These represent physical-layer components, e.g. a serializer/deserializer (SerDes). PHYs 270 are coupled to APB interconnect 225 to provide a communication path to CPU core 200, as well as any other component of retimer 110 also coupled to APB interconnect 225. One or more PHYs 270 may require CPU core 200 to initialise them, e.g. by providing firmware. This could be loaded by CPU core 200 from SPI flash 240, for example. More information on this is provided later.

[0043] Retimer 110 additionally includes a PCIe switch 275 that is coupled to APB interconnect 225. PCIe switch 275 implements PCIe switching functionality as defined by the relevant part of the PCIe standard. This enables retimer 110 to operate in a PCIe switching mode if desired. It will be appreciated that PCIe switch 275 can be omitted in the case where it is not necessary' for retimer 110 to provide a PCIe switching capability’.

[0044] Fig. 2 includes a placeholder ‘peripheral N’ 280 that is coupled to APB interconnect 225 to illustrate that retimer 110 is not limited to the specific set of peripherals illustrated in Fig. 2. Additional peripherals coupled to APB interconnect 225 may be added to retimer 110 as desired. Examples include: one or more PCIe Compute Express Links (CXLs), Physical Coding Sublayer (PCS) components, a packet inspecting component, a Joint Test Action Group (JTAG) interface, and/or a high speed die-to-die interface as described in [Ulrich],

[0045] Fig. 3 shoyvs one set of possible contents for SPI flash 240. Many variations are possible and it should thus be understood that Fig. 3 is provided with a view to assisting in the understanding of this disclosure rather than restricting its scope.

[0046] SPI flash 240 is split into two regions (a.k.a. partitions) - an active region and an inactive region. Each region corresponds to a set of addresses in SPI flash 240. These addresses do not necessarily need to be continuous - indeed, as illustrated in Fig. 3, they can be interposed between one another. An active region refers to a set of memory addresses that hold information that will be used by CPU core 200 on next boot whereas an inactive region refers to a set of memory addresses that hold information that will not be used by CPU core 200 on next boot. The purpose of this partitioning is to allow updated firmware to be stored in the inactive region yvithout disrupting the operation of the active region. This means that, in the event the updated firmware image is not usable (e.g. it is corrupt or invalid), the retimer can still boot from the existing firmware image stored in the active region.

[0047] The active and inactive statuses are set by one or more flags that are stored in header 300. Header 300 can store any other information that is deemed to be useful, such as the size of each memory region in bits, a starting address of each region, a date on which the SPI flash was last updated, and the like.

[0048] The active region includes an active firmware image 305. This is the firmware image that yvill be used by CPU core 200 the next time retimer 110 is booted. Active firmyvare image 305 includes a configuration file 310, PHY firmware 315 and an application 320. It yvill be appreciated that this is just one example and that active firmware image 305 could alternatively include different information, or additional information, to that shown in Fig. 3. [0049] Configuration file 310 stores information that is used by CPU core 200 during a boot process to configure retimer 110. For example, configuration file 310 could include one or more values that are to be respectively written to one or more registers of retimer 110 during the boot process. Protocol-specific information can be stored in configuration file 310, such as one or more PCIe vendor-defined message codes.

[0050] PHY firmware 315 is essentially a smaller firmware image within active firmware image 305. PHY firmware 315 is used to initialise PHYs 270, e.g. CPU core 200 provides PHY firmware 315 to each of PHYs 270 during a boot process. It will be appreciated that PHY firmware 315 can be omitted in the case where there are no PHYs requiring firmware on boot. When present, PHY firmware 315 provides a convenient and secure channel for updating the firmware of PHYs 270 because a new firmware image with updated PHY firmware can be loaded into SPI flash 240. [0051] Application 320 is an executable file that is run by CPU core 200 to enable it to boot correctly. During boot, application 320 is loaded by CPU core 200 and executed once loaded, assuming all security checks are passed successfully.

[0052] Active firmware image 305 also includes a second stage bootloader (not shown). The second stage bootloader is an application that handles loading of certain items such as a real-time operating system (RTOS), to assist application 320. The second stage bootloader can be omitted if not needed.

[0053] Inactive firmware image 325 is a copy of active firmware image 305. It also includes a configuration file, PHY firmware and an application as described above. As mentioned earlier, inactive firmware image 325 can differ from active firmware image 305 in aspects such as firmware version - e.g. the PHY firmware, configuration file and/or application in inactive firmware image 325 can be a different version than its counterpart in the active firmware image 305.

[0054] Thus far the discussion has been restricted to a single-tile configuration, in which the components of retimer 110 are located on a single die 235 (other than SPI flash 240 which is external to the die). Figs. 4 and 5 show a multi-tile configuration in which a second tile is introduced. The components of the second tile are located on a separate, second die 400. As shown in Fig. 5, the components of the second tile are largely identical to those of the first tile and have been given reference signs with identical suffixes to those of Fig. 2 to reflect this. Reference is thus made to the preceding discussion in this regard.

[0055] The first tile is referred to herein as the leader tile and the second tile is referred to herein as the follower tile. A distinction between the leader tile and follower tile is that the majority of the components on the follower tile are inactive. Specifically, the following components are inactive on the follower tile: CPU core 500, boot ROM 505, instruction RAM 510, data RAM 515, IRQ controller 520, OTP memory 530, SPI leader 545, 1²C leader 550, timer 555, GPIO 560, SMBus 565 and T2T SPI leader 575. These components are present as it is easier from a manufacturing perspective to produce identical tiles and designate one as leader and the other as follower. However, alternatively the above-mentioned components could be omitted. Further, during die testing, certain die defects that affect leader tile functions/ circuits might nonetheless be deemed acceptable for a die to act as a follower tile, thus increasing production yield percentages. [0056] It is also pointed out that there is no SPI flash (or other external memory) coupled to the follower tile. This is because only the leader tile CPU core 200 is active, hence there is no need to load firmware to inactive CPU core 500 of the follower tile.

[0057] The leader tile and follower tile communicate via a bus that spans both dies 235 and 400 (see Fig. 4). In the case of Figs. 4 and 5 this bus is a SPI bus, but alternative bus types could be used in place of an SPI bus if desired.

[0058] To facilitate communication, the leader tile includes a tile-to-tile (‘T2T’) SPI bus leader 285 that is coupled to a corresponding T2T SPI bus follower 575 on the follower tile via wires extending between the leader and follower tiles. These wires could be circuit traces, for example. Collectively, the T2T SPI leader 285 and T2T SPI follower 575 are referred to herein as the “T2T SPI bus’. T2T SPI leader 285 is coupled to APB interconnect 225 on the leader tile and T2T SPI follower 575 is coupled to APB interconnect 525 on the follower tile. This enables components on the leader tile to communicate with the T2T SPI bus (via APB interconnect 225) and similarly components on the follower tile to communicate with the T2T SPI bus (via APB interconnect 525). Thus, components on the leader tile can communicate with components on the follower tile - most notably, PHYs 570, PCIe switch 575 and other peripherals 580.

[0059] Remaining true to the principle of identical tiles, in Figs. 4 and 5 both the T2T SPI leader 570 and T2T SPI follower 575 are shown on the follower tile. However, it should be appreciated that only T2T SPI follower 575 is active on the follower tile of Fig. 5. Similarly, the leader tile includes both T2T SPI leader 285 and T2T SPI follower 290, with only the T2T SPI leader 285 being active. As noted above, alternative non-identical manufacture is possible in which only the T2T leader is present on the leader tile and only the T2T follower is present on the follower tile. [0060] The follower tile has its own set of PHYs 570, PCIe switch 575 and other peripherals 580. These are the same as the corresponding items shown on Fig. 2 and reference is thus made to the discussion above. PHYs 570, PCIe switch 575 and other peripherals 580 can be controlled by the CPU core 200 of the leader tile via the T2T SPI bus.

[0061] More than one bus can be present that spans both dies to provide multiple channels of communication between the dies. For example, a high speed SerDes-based die-to-die interface as described in [Ulrich] could additionally be present. The high speed die-to-die interface is a high bandwidth bus that enables relatively large volumes of data to be exchanged between the leader and follower tiles. Other bus types, e.g. Universal Chip Interconnect Express (UCIe), could additionally or alternatively be present. These alternative bus types can be used to enable writing to a device control register (see Fig. 7) that is located on a follower tile, instead of the T2T SPI bus. For example, on side of the high speed SerDes-based D2D interface described in [Ulrich], or one side of a UCIe interface, can be coupled to the APB interconnect (or equivalent bus) on a leader tile. The other side of the D2D interface of [Ulrich], or the other side of the UCIe interface, can be coupled to the APB interconnect (or equivalent bus) on a follower tile. A CPU core on the leader tile can then use the D2D interface / UCIe interface to communicate with the APB interconnect (or equivalent bus) on the follower tile, allowing the CPU core to write to the device control register on the follower tile.

[0062] It is possible to extend the two-tile configuration discussed above to further tiles. A four- tile configuration is show n in Fig. 6. In this configuration there is one leader tile and three follower tiles (tiles 1, 2 and 3). Each of the four tiles is on its own die - leader tile is on die 235, follower tile 1 is on die 400, follower tile 2 is on die 600 and follower tile 3 is on die 600’. Each follow er tile is the same as the follower tile shown in Figs. 4 and 5 and as discussed above. The leader tile is the same as discussed above. T2T SPI leader 285 on the leader tile is coupled to the respective T2T SPI follower on each follower tile - i.e. T2T follower 575, 675 and 675’. This enables CPU core 200 to control any component on any of the follow er tiles. Although not shown for clarity in Fig. 6, the leader tile and each follower tile has its own PHYs, PCIe switch and/or other peripherals of the type discussed above, which are all controllable by CPU core 200.

[0063] The leader tile and each follow er tile can have a respective device control register located on the respective tile. Each device control register can be set separately. CPU core 200 can set the device control register on the leader tile and also set each device control register on each respective follower tile.

[0064] In the general case, it is possible to extend to N tiles with one leader and N-l follower tiles coupled via an inter-tile bus like the T2T SPI bus described above.

[0065] Fig. 7 show s the leader tile discussed above in reduced form. In particular, components that are not directly relevant to the following discussion have been omitted in the interests of clarity.

[0066] In addition to the components shown in Fig. 2, the leader tile includes a device control register 700. Device control register 700 is configured to store a plurality of device security configuration data values for selectively enabling device functions, and including a register lock portion 800 configured to store a multi-bit register lock flag ‘LOCK’. Device control register 700 comprises a plurality of storage cells, with the number of storage cells being selected according to the total size of the register that is required. In one particular configuration, 20 storage cells are provided to give a total memory capacity of 20 bits. Additional storage cells that are unused (e.g. storing states corresponding to bits reserved for future use) can be present, particularly to match the size of the device control register to the width of the APB interconnect 225 or a sub-division thereof. In an alternative configuration, 24 storage cells are provided to provide a device control register with a total memory' capacity of 24 bits to match three of the four write lanes of a 32-bit APB interconnect 225 being activated by a write strobe signal. In yet another configuration. 32 storage cells are provided to provide a device control register with a total memory' capacity of 32 bits. In this case, the APB interconnect 225 can be 32 bits wide.

[0067] The storage cells are capable of storing bits, i.e. acting as a memoiy. In the following disclosure the storage cells are implemented as flip flops. However, this is not to be understood as limiting as any other component that is capable of storing data can be used in place of a flip flop, e.g. a latch circuit.

[0068] Device control register 700 is coupled to APB interconnect 225 via a data bus interface circuit to enable CPU core 200 and the various busses described in connection with Fig. 2 to communicate with device control register 700. Specifically, in this case device control register 700 is assigned an address in a vendor-defined region of an SMBus address space. Other addressing possibilities are also possible and within the scope of this disclosure.

[0069] The data bus interface circuit enables device control register 700 to receive device security' configuration data, including the multi -bit LOCK flag, via a data bus (e.g. APB interconnect 225). The received device security configuration data is for storage in device control register 700.

[0070] Receiving the device security configuration data can involve receiving the device security' data from a read-only memory (e.g. OTP memory 230) located on an integrated circuit die (e.g. leader die 235) via a data bus interface circuit (not shown) coupled to the read-only memory and coupled to the data bus (e.g. APB interconnect 225). This is typically performed in the field after configuration, i.e. receiving the device security data from the read-only memory can be part of a ‘normal use’ mode. As the memory' is read-only, modification of the security' state is relatively difficult during normal use mode.

[0071] It is alw ays possible to read device control register 700 irrespective of the current security' state, but write access is selectively allowed depending on the multi-bit LOCK flag value held in the device control register itself. This is explained in more detail below.

[0072] Fig. 8 show's device control register 700 in more detail. Device control register 700 comprises the multi-bit LOCK flag 800 having a plurality of lock state bits, a LEVEL flag 805 having a plurality’ of level state bits, and N INTERFACE flags 810a, ... , 81 On. each respectively having a plurality of interface state bits. N can be any positive integer greater than or equal to one, or zero in the case that no interface control is performed. Device control register 700 can be constructed from a set of flip flops coupled together, with the number of flip flops being selected based on the understanding that each flip flop can store one bit.

[0073] Each flag can take one of two values - an asserted value (‘HIGH’) in which a high security state is set and a de-asserted value (‘LOW’) in which a low security state is set. In the illustrated implementation, each flag is a multi-bit flag. The flag can be a 2 -bit flag, a 3 -bit flag, a 4-bit flag, and so on. The flag can be such that the asserted HIGH value is the opposite of the de-asserted LOW value, in the sense that the HIGH value has all bits ‘flipped’ (opposite valued) compared to the LOW value. All other values for the flag that are not the HIGH value or LOW value are illegal values and are treated as the asserted value if encountered, meaning that only one of the possible m² values for an m-bit flag corresponds to the de-asserted state.

[0074] It will be appreciated that having the de-asserted value with all bits flipped compared with the asserted value can assist with mitigation against power cycling attacks as, for such an attack to succeed, it would be necessary for all m bits to switch value simultaneously on a given power cycle attack attempt. This is a very unlikely outcome of a power cycling attack, hence the probability of such an attack being successful is low.

[0075] In the general m-bit flag case, the de-asserted value can be selected by performing a bitwise XOR operation with operands of the m bits of the flag in the locked state and a binary value having the same number of bits as the multi-bit register lock flag, where each bit of said binary⁷ value is 1. That is: de-asserted value (m bit) = asserted value (m bit) XOR m bit binary value, all bits of the binary value being 1. Here, m is greater than or equal to two.

[0076] Alternative values for the asserted and de-asserted values can be selected. The asserted and de-asserted values of the m-bit flag can generally be respective different combinations of interleaved 1 and 0 values, where each of the asserted and de-asserted values comprises a different mix of 1 and 0 values (i.e. neither the asserted value nor de-asserted value comprises all ones or all zeroes).

[0077] Device control register 700 also includes a clock line 815, a read line 820 and a write line 830. Clock line 815 supplies a clock signal elk to device control register 700 to enable the flip flops such that flip flop state transitions can occur. Read line 820 allows the values of the various flags of device control register 700 to be read. Write line 830 allows the values of the various flags of device control register 700 to be adjusted by writing to the register. Writing can only take place when clock line 815 carries a clock signal to the flip flops. In Fig. 8, read line 820 and write line 830 are shown carrying p bits, p is a positive non-zero integer, the value of which will depend on the number of flags in device control register 700. Values that p could take include 24 and 32, but this disclosure is not limited to these values. [0078] Clock line 815 is driven via a write signal generation circuit 825. Write signal generation circuit 825 includes a security verification logic gate 1005 (see also Fig. 10A) that receives an enable input such that it is only possible to write to device control register 700 when the LOCK flag 800 is de-asserted (i.e. set to a low' security state). That is, write signal generation circuit 825 is configured to selectively generate, in response to the multi-bit register lock flag LOCK, a write signal to cause the device control register to store the provided device security configuration data values. Further information on this is provided below in connection with Fig. 10A.

[0079] It is thus possible to use security verification logic gate 1005 to selectively enable writing received device security configuration data to the device control register that security verification logic gate 1005 is coupled to. Here, writing includes writing the multi -bit register lock flag to the register lock portion 800 of the device control register 700.

[0080] LEVEL flag 805 controls the security level. When asserted, a HIGH security level is set in which only CPU core 200 can write to device control register 700 (assuming LOCK is deasserted). When de-asserted, a LOW security level is set in which CPU core 200 and any bus leader can write to device control register 700 (assuming LOCK is de-asserted). The LOCK flag overrides the LEVEL flag, so in the case where LEVEL is set to LOW but LOCK is set to HIGH, writing to device control register 700 is not possible even for CPU core 200.

[0081] INTERFACE flag(s) 810a, ... , 810n, if present, each respectively correspond to an interface of the leader tile 235. The interface can be any type of component that allows communication between the leader tile and an external component. Referring to Fig. 2, the Two Wire Interface (‘TWF - an I²C-type interface) that SMBus 265 uses is one example of an interface. Another example of an interface is a Joint Test Action Group (JTAG) interface (not show n in Fig. 2). A further example of an interface is the T2T SPI interface that T2T SPI leader 285 is part of. This list is non-exhaustive and non-limiting on the scope of this disclosure. In one particular case, the INTERFACE flags comprise three flags: an I²C flag 810a that controls SMBus access privileges on APB interconnect 225, a T2T SPI flag 810b that controls T2T SPI follower 290 access privileged on APB interconnect 225, and a JTAG flag 810c that controls a JTAG interface’s functionality set that is available for use.

[0082] In general, an INTERFACE flag thus controls the level of permission that the corresponding interface has with respect to accessing other components of the retimer. The specifics will depend on the interface in question. The following table provides an example of this in the context of the three interface-flag example introduced in the preceding paragraph.

[0083] As can been seen from this table, gate 1 105 of the JTAG interface selectively allows access to a subset of a set of functions provided by the JTAG interface based on a value of the JTAG interface flag. The subset of the set of functions can be debugging functions, for example, such that gate 1105 selectively allows access to debugging functions of the JTAG interface based on the value of the JTAG interface flag. The debugging functions can include an IJTAG interface such that gate 1105 selectively allows access to the IJTAG interface based on the value of the JTAG interface flag.

[0084] LEVEL flag 805 can override one or more of the INTERFACE flag(s). That is, in this case, if LEVEL is set to HIGH the retimer behaves as if the overridable INTERFACE flag(s) is/are set to HIGH irrespective of their current value. In the case of the three interfaces discussed above, the LEVEL flag overrides the I²C and JTAG flags. Other configurations are possible.

[0085] The values of the LOCK flag 800, LEVEL flag 805 and INTERFACE flag(s) are set by CPU core 200 during a boot process. In normal operating mode, during boot the flags are set based on information stored in OTP memory 230. CPU core 200 is configured to write (or ‘bum’) OTP memory 230 following a first boot, meaning that retimer 110 can be shipped in a low security (debugging/configuration) mode (e.g. LOCK is de-asserted, LEVEL is set to LOW) and then switched to a high security mode (e.g. LOCK is asserted, LEVEL is set to HIGH) once configured correctly. As a given region of OTP memory 230 cannot be edited once written, the low security mode cannot be accessed after writing OTP memory 230 to high security mode unless updating of OTP memory 230 is enabled (see below for details).

[0086] It is possible to configure the device control register such that it can only be written to by an atomic write operation. This means that all flags in the device control register (i.e. all of the flip flops of the device control register) are written simultaneously in a single clock cycle, as opposed to writing one flag in one clock cycle and another flag in a different clock cycle. This can increase security' because it prevents a hacking attempt in which a gradual change of a particular flag is attempted, e.g. changing just one bit of a given multi-bit flag in a given clock cycle, then changing a different bit of the multi-bit flag in another clock cycle. [0087] This can be achieved by coupling a monitoring circuit (not shown) to the read line 820 of device control register 700. The monitoring circuit is a logic block that compares the current read value for each flag in the device control register 700 to the allowed values. In the case where the current read value does not match one of the allowed values, the monitoring circuit sets the illegally valued flag to HIGH. This check can be carried out on each clock cycle. Where a flag needs to be changed, this can be carried out on the next clock cycle following the cycle in which the flag was set to an illegal value. In this way, a flag can be prevented from holding an illegal value for more than one clock cycle.

[0088] Also shown in Fig. 8 is APB decoder 835. This is coupled to APB interconnect 225 and also to clock line 815, read line 820 and write line 830. APB decoder 835 is part of the data bus interface circuit that is configured to obtain device security configuration data values from a data bus on the die (e.g. APB interconnect 225) and to provide the device security configuration data values to the device control register 700. Specifically, APB decoder 835 functions to decode signals transmitted over APB interconnect 225 and to provide appropriate signals to device control register 700 via clock line 815, read line 820 and/or write line 830. One particular function of APB decoder 835 is to detect signals on APB interconnect 225 addressed to device control register 700 and to pick these signals up from APB interconnect 225. Other functions are also possible.

[0089] Fig. 9 show-s a flow' diagram of one possible process for configuring device control register 700. This process is provided to assist in the understanding of the invention and should not be construed as limiting the scope of this disclosure. The process of Fig. 9 can be performed by CPU core 200. or more generally speaking a processor of the retimer.

[0090] Device control register 700 can be configured such that on reset each of the flags except for the LOCK flag is set to a HIGH security level by default. The monitoring circuit described above can configure the device control register in this way following boot, or the flip flops (or equivalent memory cells) that form the device control register can be configured such that on reset they are set to a HIGH security level. This can be set for all dies of a multi-die module such that the entire die is in a maximum security state. This prevents an attacker from being able to access components on the or each die immediately following reset via the various interfaces, e.g. JTAG interface. The LOCK flag is set to a LOW security level on cold reset by default. The process of Fig. 9 is then followed after the reset to configure device control register 700, i.e. to adjust the values of the various flags from their defaults to values according to the current retimer settings.

[0091] In step 900 the processor determines whether a ‘cold’ reset has occurred. This can also be referred to as a ‘hard' reset. Irrespective of the terminology used, this refers to a reset that involves all power being removed from the retimer. This is contrasted with a warm reset where power is not fully removed during the reset process. [0092] In the case where the reset is not a cold reset, the process moves to step 905 in which the processor checks whether the LOCK flag is set to a HIGH value. In the case where the LOCK flag is set to the HIGH value, the process ends as writing to device control register 700 is not possible in this case.

[0093] In the case where the LOCK flag is not set to a HIGH value (i.e. the LOCK flag is set to a LOW value), the process moves to step 910 in which the flags of the device control register 700 are all set based on a value for each flag stored in a read-only memory’ such as OTP memory 230. Step 910 can thus include setting the value of the LOCK. LEVEL, I²C. JTAG and T2T SPI flags based on corresponding values stored in OTP memory 230. Once these flags are set, the process ends. The configuration stored in OTP memory’ 230 can be selected according to the intended usage environment of the retimer and/or according to customer requirements, for example.

[0094] In step 910, in the case where a value held in OTP memory 230 is an illegal value (i.e. neither HIGH nor LOW), the value of the corresponding flag is set to HIGH. This ensures that only the case in which the value in OTP memory’ 230 is LOW will result in a corresponding LOW flag being set. This makes it more difficult to successfully carry' out a power cycling attack.

[0095] OTP memory’ 230 can be divided into two logical partitions. When the flag values are written to OTP memory 230, each value can be written twice, once to each partition. In this configuration, reading OTP memory 230 involves reading each flag twice, once from each partition. An OR operation on the flag values is then performed and the result is taken as the value for the corresponding flag. This can improve security because an error in the OTP memory' write process that accidentally sets a flag to LOW is unlikely to occur for that flag in both partitions, meaning that in the other partition the probability is large that this flag is correctly written as HIGH. The resultant value after the OR operation in such a case is the correct value, HIGH, despite one partition holding a LOW value for that flag. Only in the case where both partitions hold the value LOW will the OTP memory read return a value LOW.

[0096] Reading of OTP memory 230 can be carried out via APB interconnect 225. OTP memory 230 is coupled to APB interconnect 225 via an interface circuit (not shown) that facilitates data transfer from OTP memory’ 230 to APB interconnect 225.

[0097] Returning to step 900, in the case where a cold reset has occurred, the process moves to step 915. In step 915, the LOCK flag is set to LOW and the I²C interface flag is set to either HIGH or LOW based on a signal level of a debugging pin SMBDEBUG. The SMBDEBUG pin can be implemented via a GPIO pin 260, for example. This provides a route for regaining access to the device control register 700 after LOCK flag has been set to HIGH, as by performing a cold reboot the LOCK flag is set to LOW to enable write access to device control register 700. Setting the I²C interface flag to LOW via the SMBDEBUG pin also gives SMBus access to components on the retimer, e.g. for firmware update purposes.

[0098] In step 920 the processor determines whether this boot is the first boot (i.e. the first time the retimer has been booted). This determination can be made by checking whether OTP memory 230 has any data written to it. In the case that no data has been written, it can be determined that this is a first boot scenario. If data has been written to OTP memory 230, it is not a first boot scenario. Other techniques for determining whether the boot is the first boot, such as checking a value of a first boot flag, are also possible and within the scope of this disclosure.

[0099] In the case where it is determined that it is not a first boot, the process moves to step 925. In step 925, the processor sets the JTAG flag to HIGH and the LEVEL flag to HIGH. This disables a debugging mode (via the JTAG interface) in all cases except a first boot case, which assists in preventing debugging mode from being entered after the retimer has been released from the control of an entity authorised to have debugging access (e.g. the manufacturer). Additionally, the input from the SMBDEBUG pin is effectively ignored in the case where it is not a first boot as, in the configuration show n, the LEVEL flag overrides the I²C flag. This provides additional security as it makes it more difficult to hack the retimer by attempting to enter debugging mode via the SMBDEBUG pin.

[0100] In the case where it is determined that it is a first boot, the process moves to step 930. In step 930, the processor sets the JTAG flag to LOW and the LEVEL flag to LOW. This enables a debugging mode, e.g. via the JTAG interface and/or SMBus interface.

[0101] Following whichever of step 925 and 930 is carried out, the process moves to step 935. In step 935, the processor determines whether the device control register 700 currently being configured is located on a leader tile or a follower tile. A tilelD register can be read to determine this, for example.

[0102] In the case where it is determined that the device control register currently being configured is located on a leader tile, the process moves to step 940 in which the processor sets the T2T SPI flag to HIGH. The value HIGH is set in the case of a leader tile because CPU core 200 is leader on APB interconnect 225 on a leader tile and so it is not necessary⁷ for the T2T SPI bus to also act as an APB leader. Setting the T2T SPI flag to HIGH in this situation thus makes it harder for a hacking attempt to succeed as the hacker cannot use the T2T SPI bus to gain bus leader access to the APB interconnect 225 on the leader tile.

[0103] In the case where it is determined that the device control register currently being configured is located on a follower tile, the process moves to step 945 in which the processor sets the T2T SPI flag to LOW. This enables the T2T bus follower on the follower tile to be leader on the local APB interconnect. The rationale here is that, in the case of a follower tile, the local CPU core (on the follower tile) is inactive. The T2T SPI follower being set as a leader on the local (follower tile) APB interconnect enables the leader tile CPU core 200 to access registers on the follower tile via the T2T SPI bus.

[0104] The process of Fig. 9 can be repeated for each tile in a multi-tile retimer to configure the respective device control register on each tile. It is possible to configure each device control register differently, although it is ty pically expected that all of the follower tiles in a given retimer will have the same configuration for their respective device control registers. The configuration of each follower tile can be performed by CPU core 200 via the T2T SPI bus.

[0105] More specifically, each tile in the multi-tile retimer can have a respective device control register like device control register 700. Each device control register can be configured by CPU core 200 to be in a particular security' state, the security state referring to the values of the various flags discussed above in connection with Fig. 8. The security state can be identical for all follower tiles, or may vary' from follower tile to follower tile. The security state of a leader tile can also be different to the security state of the follower tile(s), or the leader tile may have the same security state as one or more of the follow er tiles. The ability to set specific security' states for each tile in a multi-tile module can advantageously improve the overall security of such a module because this provides a defence in a scenario where a bad actor attempts to access the module via an interface on a fol lower tile.

[0106] Fig. 10A shows the LOCK flag 800 and write signal generation circuit 825 in more detail. LOCK flag 800 is shown in Fig. 10A as being stored by four flip flops, each holding one bit of the four-bit lock flag. For ease of understanding, the flip flops are ordered according to the bit position in the lock flag, with the leftmost flip flop in the figure corresponding to the most significant bit of the LOCK flag and the rightmost flip flop in the figure corresponding to the least significant bit of the LOCK flag.

[0107] Write signal generation circuit 825 includes an AND gate 1000 coupled to a read line of the flip flops storing LOCK flag 800, as well as an Integrated Clock Gating (ICG) cell 1005. ICG cell 1005 receives the enable signal enb that is output by AND gate 1000 and only provides a gated clock signal g clk as an output to clock line 815 in the case where the enable signal enb is high. This only occurs in the particular case of Fig. 10A when the LOCK flag is de-asserted.

[0108] Thus, clock signal g elk is only provided to device control register 700 when the LOCK flag is de-asserted as it is gated by write signal generation circuit 825. In all other cases, the clock line 815 of device control register 700 is gated off by yvrite signal generation circuit 825, preventing any w rite access because the flip flops of device control register 700 are not enabled for writing without receipt of clock signal g clk. [0109] The enable signal provided to ICG 1005 is generated by AND gate 1000. In this case, as the LOCK flag is four bits, AND gate 1000 correspondingly has four inputs, each input respectively coupled to a read output of one of the flip flops that collectively store the LOCK flag. In the case of Fig. 10 A, the inputs to AND gate 1000 have been configured correspondingly such that only an input of LOW (i.e. unlocked) will cause AND gate 1000 to output a high enable (enb) output. All other inputs will result in a low output of AND gate 1000. This particular structure is just one possibility’ for the lock state determination logic and has been provided to aid in the understanding of the invention. Alternative logic that performs the same function can be used in place of the logic shown in Fig. 10A.

[0110] In the general case, AND gate 1000 will have m inputs for a m-bit LOCK flag and the nature of each input (inverting or non-inverting) will depend on the binary value selected to correspond to the de-asserted state. Here, m is an integer greater than or equal to two.

[0111] It will be appreciated from Figs. 8 and 10 that the flip flops storing the LOCK flag itself are also gated off once the LOCK flag has been set to an asserted value. This prevents even the LOCK flag from being overwritten to once it has been asserted. Therefore, once the LOCK flag has been asserted, it is only possible to write to device control register 700 again following a cold reset (see Fig. 9, step 915).

[0112] A more detailed schematic diagram of w rite signal generation circuit 825 is shown in Fig. 10A.

[0113] AND gate 1000 has a set of inputs and an output. Each input of the set of inputs is coupled to a read output of a respective flip flop storing a bit of LOCK flag 800, as shown in Fig. 10A.

[0114] AND gate 1000 is configured to generate an enable signal at the output based on the set of inputs. Specifically, AND gate 1000 generates an enable signal enb having an enable signal value based on a value of LOCK flag 800. This is achieved in the illustrated case by having two inverting inputs respectively coupled to the read line of the flip flops storing the most significant bit and the third bit of the four-bit LOCK flag. AND gate 1000 also has two non-inverting inputs respectively coupled to the read line of the flip flops storing the second and fourth bit of the four- bit LOCK flag. This means that AND gate 1000 will only output a high enable signal when the input is the value corresponding to the LOW security state. Any other combination of inputs will result in a low enable signal as output from AND gate 1000, corresponding to the HIGH security state. It will be appreciated that the configuration of the lock state determination logic will vary according to the size of the LOCK flag in bits and also the particular value of the LOCK flag that indicates the LOW security' level.

[0115] ICG cell 1005 is shown in more detail in Fig. 10B. ICG cell 1005 comprises a flip flop

1010 and a two-input AND gate 1015. ICG cell 1005 selectively generates a gated clock output g clk based on the value of the enable signal enb and a clock signal elk. ICG cell 1005 has an input coupled to the output of AND gate 1000 to receive the enable signal generated by AND gate 1000. In the illustrated case, this input for the enable signal is a data line of a flip flop 1010. Flip flop 1010 also has a clock input coupled to a bus clock output, this being the signal elk provided by APB decoder 835 in this case. The clock input is inverted as shown in Fig. 10B.

[0116] Flip flop 1010 outputs a value Q that is based on elk and enb. Specifically, in the configuration shown in Fig. 10B the value Q is latched to the value of enb when elk is low. This means that when elk switches high, the value of enb is already an input to AND gate 1015. Flip flop 1010 thus ensures that the ‘live’ or ‘current’ value of enb is provided as input to AND gate 1015 at the moment when elk transitions from low to high, and that this value of enb is provided throughout the entire duty cycle of elk.

[0117] AND gate 1015 produces a gated clock g clk as an output, g clk is based on enb and elk. In the case where enb is low, g_clk is also low irrespective of elk, i.e. no clock signal is provided to device control register 700 so writing to this register is not possible. However, when enb is high, AND gate 1015 will act such that g clk follows elk. That is, g clk will be high when elk is high and g clk low when elk is low. Conceptually, this can be thought of as elk passing through write signal generation circuit 825 to clock the flip flops of device control register 700. In this way, the LOCK flag can control write access to device control register 700.

[0118] The construction of write signal generation circuit 825 that is shown in Figs. 8, 10A and 10B is one way of implementing the desired gating functionality. It will be appreciated that alternative logic can be constructed that achieve this gating functionality and further that such alternatives are also within the scope of this disclosure.

[0119] Fig. 11 is a schematic diagram of one way in which device control register 700 can be coupled to other components of the leader tile 235. Fig. 11 shows leader tile 235 but it will be appreciated that the same configuration can be applied to the or each follower tile of the retimer. The only difference between a leader and follower tile in this regard is the values held by the respective device control registers.

[0120] In the case of Fig. 11, device control register 700 includes LOCK flag 800, LEVEL flag 805 and three INTERFACE flags - I²C flag 810a, T2T SPI flag 810b and JTAG flag 810c. As noted above, this is purely to illustrate the working of the invention and alternative INTERFACE flag(s) can be additionally or alternatively present.

[0121] LOCK flag 800 is coupled to clock line 815 of device control register 700 via write signal generation circuit 825 as discussed above. Each of LEVEL flag 805, 1²C flag 810a, T2T SPI flag 810b and JTAG flag 810c is connected to arbiter 1100. Arbiter 1100 is in turn coupled to APB interconnect 225. [0122] A function of arbiter 1100 is to control bus leader access for APB interconnect 225. Arbiter 1100 uses the states of I²C flag 810a, T2T SPI flag 810b, JTAG flag 810c and optionally also LEVEL flag 805 to determine whether a corresponding interface is permitted to be a leader on APB interconnect 225.

[0123] That is, arbiter 1100 selectively controls bus leader access on the data bus (e.g. APB interconnect 225) for one or more interfaces (e.g. an I²C interface, a T2T SPI interface, and/or a JTAG interface) coupled to the data bus based on a value of respective ones of the one or more multi-bit interface lock flags (e.g. I²C flag 810a, T2T SPI flag 810b and/or JTAG flag 810c). A HIGH security state of a flag means that arbiter 1100 prevents bus leader access for the corresponding interface and a LOW security state of a flag means that arbiter 1100 allows bus leader access for the corresponding interface.

[0124] The LEVEL flag may override one or more of the interface lock flags such that it is the value of the LEVEL flag, not the overridden interface lock flag(s), that arbiter 1100 acts upon to determine whether to allow or deny bus leader access for the corresponding interface. That is, arbiter 1100 can selectively control bus leader access on the data bus for at least one of the interfaces based additionally on a value of the LEVEL flag that is part of the device security configuration data,

[0125] The read lines of the flip flops comprising the JTAG part of device control register 700 are also coupled to a gate 1105 to provide a JTAG enable signal ‘j-enb’. Gate 1105 is located between an external pad 1115 and JTAG interface 1110. Gate 1105 functions to gate off debugging functionality of the JTAG interface(s) (and internal JTAG, TJTAG’, if present) when JTAG flag 810c is HIGH. Examples of debugging functionality include any functionality that is capable of capturing payload data such as JTAG access to CPU core 200, as well as the IJTAG interface per se. Gate 1105 means that any attempt to use the JTAG interface for such debugging functions when JTAG flag 810c is HIGH will fail because the incoming signals will not get past gate 1105. This can result in an increase in security.

[0126] T2T SPI leader 285 and T2T SPI follower 290 enable communication between leader tile 235 and a follower tile (e.g 400, 600, 600’) to take place. That is, the T2T SPI interface allows for communicating between the leader die 235 and a follower die (e.g. 400, 600 and/or 600’) using bus leader 285 of the SPI interface located on the leader die 235 and a bus follower (e.g. 575, 675, 675’) located on the follower tile integrated circuit die. Arbiter 1100 selectively controls data bus leader access (e.g. APB interconnect 225 leader access) for bus leader 285 and bus follower 575, 675, 675'. Typically bus leader 285 is a follower only on the data bus because, on the leader tile, CPU core 200 is bus leader on the data bus. Typically the SPI bus follower on a follower tile (e.g. 575, 675, 675’) is a leader on the data bus because the CPU core on a follower tile is inactive. [0127] Fig. 12 shows some possible configurations for the flags based on the process of Fig. 9. The letter ‘X’ is used to represent a scenario in which a flag value is irrelevant because it is overridden by another flag. Some flag value combinations are excluded from this table because, while theoretically possible, they do not occur in practice when following the process of Fig. 9. The LOCK flag is not included in this table since it controls whether it is possible to write to device control register 700 rather than relating to interface permissions.

[0128] In the case of configurations relating to a follower tile, the local CPU core is inactive and so the local CPU core is not listed as a possible APB leader in those cases.

[0129] States 1 and 2 respectively correspond to a leader tile and follower tile in a high security ‘production’ mode, i.e. normal usage of the retimer by e.g. an end user. States 1 and 2 are the highest security states and would typically be used in combination (leader tile in state 1, follower tile(s) in state 2). In these states only the production mode functionality of the JTAG interface is enabled - e.g. scan mode and/or memory built-in self-test (MBIST) mode. Any IJTAG capabilities are disabled. Only the CPU core 200 can be ABP leader on a master tile, and only T2T SPI follower 575 can be APB leader on a slave tile. The leader tile and follower tile(s) can be configured such that a reset occurs before the production mode functionality of the JTAG interface is used, to prevent reading of internal register values and the like that have been set when in normal usage (retiming mode). Additionally or alternatively, the leader tile and follower tile(s) can be configured such that a reset occurs after exiting use of the production mode functionality of the JTAG interface, such that any changes made to the internal state of the tile are erased before resuming normal usage (retiming mode). This can further improve security.

[0130] State 3 is a first run debugging mode for a leader tile in which OTP memory 230 is empty, and state 4 is the same first run debugging mode for a follower tile. This state is used to write flag values to OTP memory 230 for use in the production mode states 1 and 2. In states 3 and 4, debugging is possible via the JTAG/IJTAG interface only. In these states the full debugging capabilities of the JTAG interface are enabled, including any IJTAG capabilities. States 3 and 4 would typically be used together to enable debugging of leader and follower tiles simultaneously. [0131] State 3 can be used to perform an in-field firmware update as JTAG interface 1110 can access the instruction RAM 210 in debugging mode (i.e. when JTAG flag 810c is LOW). This allows a software agent to be loaded into instruction RAM 210 via JTAG interface 1110. The software agent can co-ordinate the firmware update process in conjunction with external commands received via JTAG interface 1110. The updated firmware is stored on SPI Flash 240. [0132] States 5 and 6 are the same as states 3 and 4, with the exception that the I²C flag is set to LOW to allow SMBus 265 to be used as a debugging interface in addition to the JTAG/IJTAG interface. States 5 and 6 w ould typically be used together. [0133] States 3 to 6 are low security states and would typically only be enabled by a manufacturer or other such authorised party when performing retimer testing and programming. An example of programming that could be carried out is writing flag values to OTP memory 230.

[0134] A further state, 'OTP read’, is included in Fig. 12. This state corresponds to the values for each flag read from the OTP memory 230. In principle any combination of flag states can be set in the OTP memory 230 for subsequent use in production mode, hence the use of ‘?’ in Fig. 12. In many cases it is likely that the OTP read state will be state 1 for the leader tile and state 2 for the or each follower tile. i.e. the highest security state for the retimer. This disclosure is however not restricted to this and in principle the OTP read state can set the various flags to any combination of LOW and HIGH values that is desired. In practice two OTP read states will be defined, one for the leader tile and one for the or each follower tile. Further states, e g. one for each follower tile where multiple follower tiles are present, are also possible.

[0135] In some circumstances it can be desirable to perform an in-field update to the flag values stored in OTP memory 230, i.e. to change the state ‘OTP read’ in the field. This is possible in cases where OTP memory 230 is large enough to store more than one set of flags, possibly in duplicate if the logical partition technique discussed above is made use of. This is because an OTP memory is a write-once device, i.e. the bits already written to the OTP memory are fixed. In such a case an interface such as the JTAG interface can be used to load an application into instruction RAM 210 that causes CPU core 200 to write a new⁷ set of flags (possibly in duplicate in the manner described above) to OTP memory 230. A charge pump (not shown) can be included in the retimer to provide sufficient voltage for writing to the OTP memory 230. The new flag values can be written consecutively and to a memory address range that has a lowest address that is adjacent the highest address of the old flag values in OTP memory 230. In such a case, when reading from OTP memory 230 in step 910, CPU core 200 uses the flag values that are closest to an unwritten portion of OTP memory 230, proximity here being measured in terms of memory addresses. This technique means that the most recently written flag values are loaded by CPU core 200.

[0136] Fig. 13 shows a flow⁷ chart of a process that can be performed by the aforementioned retimer. Step 1300 comprises receiving device security configuration data, including a multi -bit register lock flag, via a data bus, for storage in a device control register of an integrated circuit die. The multi-bit register lock flag can be LOCK flag 800 as discussed above. The device security configuration data can be the collective values of all of the flags discussed above, e.g. LOCK, LEVEL, I²C, JTAG and T2T SPI. The data bus can be APB interconnect 225 on a leader tile or the equivalent local APB interconnect on a follower tile. The device control register can be device control register 700. The integrated circuit die can be the die of any leader or follower tile discussed above.

[0137] Step 1305 comprises using a security verification logic gate connected to a register lock portion of the device control register to selectively enable writing the received device security configuration data to the device control register, the writing including writing the multi -bit register lock flag to the register lock portion. The security verification logic gate can be security verification logic gate 1005. The register lock portion can be the flip flops of device control register 700 that store the bits of LOCK flag 800.

[0138] The process of Fig. 13 can provide gated access to the device control register such that it can only be written in a low security mode, e.g. a debug mode. Writing to any of the flip flops of the device control register is prevented in a high security mode when the LOCK flag is HIGH.

[0139] It will be apparent to a person skilled in the art having the benefit of the present disclosure that various modifications, extensions, substitutions and the like to the subject matter described herein are possible. Such changes are also within the scope of this disclosure. It is also noted that, where method steps are described, these steps can be performed in any order unless expressly stated otherwise.

[0140] The following clauses set out further embodiments of this disclosure, in addition to the embodiments described above.

[0141] Clause 1: An apparatus comprising: a device control register located on a die of the apparatus, configured to store a plurality of device security configuration data values for selectively enabling device functions, and including a register lock portion configured to store a multi -bit register lock flag; a data bus interface circuit configured to obtain the device security configuration data values from a data bus on the die and to provide the device security configuration data values to the device control register; and a write signal generation circuit having a security verification logic gate connected to the register lock portion, and configured to selectively generate, in response to the multi-bit register lock flag, a write signal to cause the device control register to store the provided device security configuration data values.

[0142] Clause 2: The apparatus of clause 1, wherein the plurality of device security configuration data values further includes an interface lock portion configured to store one or more multi-bit interface lock flags.

[0143] Clause 3: The apparatus of clause 2, further comprising: one or more interfaces coupled to the data bus; and an arbiter coupled to the data bus and to a first read line of a first set of storage cells of the device control register that store the one or more multi-bit interface lock flags, the arbiter configured to selectively control bus leader access on the data bus for the one or more interfaces based on a value of respective ones of the one or more multi-bit interface lock flags. [0144] Clause 4: The apparatus of clause 3, wherein the plurality of device security configuration data values further includes a security level portion configured to store a multi-bit security' level flag; and the arbiter is coupled to a second read line of a second set of storage cells of the device control register that store the multi-bit security level flag, the arbiter configured to selectively control bus leader access on the data bus for at least one of the one or more interfaces based additionally on a value of the multi-bit security' level flag.

[0145] Clause 5: The apparatus of clause 3 or clause 4, wherein the one or more interfaces comprise an I²C interface and a SPI interface and the respective ones of the one or more multi -bit interface lock flags respectively comprise a multi-bit I²C lock flag and a SPI lock flag.

[0146] Clause 6: The apparatus of clause 5, wherein the SPI interface includes a bus leader and a bus follower, the bus leader located on the die of the apparatus and the bus follower located on a second die of the apparatus, the SPI interface configured to enable communication between the die and the second die.

[0147] Clause 7: The apparatus of any one of clauses 2 to 6, wherein: the interface lock portion comprises a multi-bit JTAG interface flag stored by a set of storage cells of the device control register, the set of storage cells having a read line; and the one or more interfaces comprise a JTAG interface having a gate coupled to the read line, the gate configured to selectively allow access to a subset of a set of functions provided by the JTAG interface based on a value of the multi-bit JTAG interface flag.

[0148] Clause 8: The apparatus of any preceding clause, wherein the security verification logic gate comprises: an AND gate having a plurality of inputs connected to respective storage cells of the register lock portion of the device control register, the AND gate further comprising an enable output; and an integrated clock gating cell having an enable input coupled to the enable output and a clock input configured to receive a clock signal, and a gated clock output that is coupled to a clock line of the device control register, the integrated clock gating cell configured to selectively generate the gated clock output based on a value of the enable input.

[0149] Clause 9: The apparatus of any preceding clause, wherein the multi -bit register lock flag has a locked state and an unlocked state, and wherein the bits of the register lock flag in the unlocked state are equal in value to a bitwise XOR operation with operands of the bits of the register lock flag in the locked state and a binary value having the same number of bits as the multi-bit register lock flag, where each bit of said binary value is 1.

[0150] Clause 10: The apparatus of any preceding clause, further comprising: a read-only memory' located on the die and configured to store the plurality' of device security configuration data values; and a second data bus interface circuit coupled to the read-only memory and the data bus. and configured to transfer the device security' configuration data values from the read-only memory' to the data bus.

[0151] Clause 11: A method comprising: receiving device security configuration data, including a multi-bit write-enable security flag, via a data bus, for storage in a device control register of an integrated circuit die; and using a security verification logic gate connected to a register lock portion of the device control register to selectively enable writing the received device security' configuration data to the device control register, the writing including writing the multi-bit writeenable security flag to the register lock portion.

[0152] Clause 12: The method of clause 11, wherein the device security configuration data further includes an interface lock portion storing one or more multi-bit interface lock flags.

[0153] Clause 13: The method of clause 12, further comprising: selectively controlling, by an arbiter coupled to the data bus, bus leader access on the data bus for one or more interfaces coupled to the data bus based on a value of respective ones of the one or more multi-bit interface lock flags.

[0154] Clause 14: The method of clause 13, further comprising: selectively controlling, by the arbiter, bus leader access on the data bus for at least one of the one or more interfaces based additionally on a value of a multi-bit security level flag that is part of the device security configuration data.

[0155] Clause 15: The method of clause 13 or clause 14, wherein the one or more interfaces comprise an I²C interface and a SPI interface and the respective ones of the one or more multi-bit interface lock flags respectively comprise a multi-bit I²C lock flag and a SPI lock flag.

[0156] Clause 16: The method of clause 15, further comprising: communicating between the integrated circuit die and a follower tile integrated circuit die using a bus leader of the SPI interface located on the integrated circuit die and a bus follower of the SPI interface located on the follower tile integrated circuit die.

[0157] Clause 17: The method of any one of clauses 12 to 16, further comprising: selectively allowing, by a gate of a JTAG interface located on the integrated circuit die, access to a subset of a set of functions provided by the JTAG interface based on a value of a multi-bit JTAG interface flag of the one or more multi-bit interface lock flags.

[0158] Clause 18: The method of any one of clauses 11 to 17, further comprising, as part of the using the security' verification logic gate to selectively enable writing the received device security' configuration data to the device control register: generating, by an AND gate of the security' verification logic gate, an enable signal having an enable signal value based on a value of the multi-bit write-enable security flag; and selectively generating, by an integrated clock gating cell of the security verification logic gate, a gated clock output based on a value of the enable signal and a clock signal.

[0159] Clause 19: The method of any one of clauses 11 to 18, wherein the multi-bit register lock flag has a locked state and an unlocked state, and wherein the bits of the register lock flag in the unlocked state are equal in value to a bitwise XOR operation with operands of the bits of the register lock flag in the locked state and a binary value having the same number of bits as the multi-bit register lock flag, where each bit of said binary’ value is 1.

[0160] Clause 20. The method of any one of clauses 11 to 19, wherein the receiving device security' configuration data for storage in a device control register of an integrated circuit die further comprises: receiving the device security' data from a read-only memory' located on the integrated circuit die via a second data bus interface circuit coupled to the read-only memory and coupled to the data bus.

Claims

1 . An apparatus comprising: a device control register located on a die of the apparatus, configured to store a plurality of device security configuration data values for selectively enabling device functions, and including a register lock portion configured to store a multi-bit register lock flag; a data bus interface circuit configured to obtain the device security configuration data values from a data bus on the die and to provide the device security configuration data values to the device control register; and a write signal generation circuit having a security verification logic gate connected to the register lock portion, and configured to selectively generate, in response to the multi-bit register lock flag, a write signal to cause the device control register to store the provided device security configuration data values.

2. The apparatus of claim 1 , wherein the plurality of device security configuration data values further includes an interface lock portion configured to store one or more multi-bit interface lock flags.

3. The apparatus of claim 2, further comprising: one or more interfaces coupled to the data bus; and an arbiter coupled to the data bus and to a read line of a set of storage cells of the device control register that store the one or more multi-bit interface lock flags, the arbiter configured to selectively control bus leader access on the data bus for the one or more interfaces based on a value of respective ones of the one or more multi-bit interface lock flags.

4. The apparatus of claim 3, wherein the plurality of device security configuration data values further includes a security level portion configured to store a multi-bit security level flag; and the arbiter is coupled to a read line of a set of storage cells of the device control register that store the multi-bit security level flag, the arbiter configured to selectively control bus leader access on the data bus for at least one of the one or more interfaces based additionally on a value of the multi-bit security level flag.

5. The apparatus of claim 3, wherein the one or more interfaces comprise an I'C interface and a SPI interface and the respective ones of the one or more multi-bit interface lock flags respectively comprise a multi-bit I²C lock flag and a SPI lock flag.

6. The apparatus of claim 5. wherein the SPI interface includes a bus leader and a bus follower, the bus leader located on the die of the apparatus and the bus follower located on a second die of the apparatus, the SPI interface configured to enable communication between the die and the second die.

7. The apparatus of claim 2, wherein: the interface lock portion comprises a multi-bit JTAG interface flag stored by a set of storage cells of the device control register, the set of storage cells having a read line; and the one or more interfaces comprise a JTAG interface having a gate coupled to the read line, the gate configured to selectively allow access to a subset of a set of functions provided by the JTAG interface based on a value of the multi-bit JTAG interface flag.

8. The apparatus of claim 1, wherein the security verification logic gate comprises: an AND gate having a plurality' of inputs connected to respective storage cells of the register lock portion of the device control register, the AND gate further comprising an enable output; and an integrated clock gating cell having an enable input coupled to the enable output and a clock input configured to receive a clock signal, and a gated clock output that is coupled to a clock line of the device control register, the integrated clock gating cell configured to selectively generate the gated clock output based on a value of the enable input.

9. The apparatus of claim 1, wherein the multi-bit register lock flag has a locked state and an unlocked state, and wherein the bits of the register lock flag in the unlocked state are equal in value to a bitwise XOR operation with operands of the bits of the register lock flag in the locked state and a binary value having the same number of bits as the multi-bit register lock flag, where each bit of said binary value is 1.

10. The apparatus of claim 1, further comprising: a read-only memory located on the die and configured to store the plurality of device security configuration data values; and a second data bus interface circuit coupled to the read-only memory' and the data bus, and configured to transfer the device security' configuration data values from the read-only memory to the data bus.

11. A method comprising: receiving device security configuration data, including a multi-bit register lock flag, via a data bus, for storage in a device control register of an integrated circuit die; and using a security verification logic gate connected to a register lock portion of the device control register to selectively enable writing the received device security configuration data to the device control register, the writing including writing the multi-bit register lock flag to the register lock portion.

12. The method of claim 11, wherein the device security configuration data further includes an interface lock portion storing one or more multi-bit interface lock flags.

13. The method of claim 12, further comprising: selectively controlling, by an arbiter coupled to the data bus, bus leader access on the data bus for one or more interfaces coupled to the data bus based on a value of respective ones of the one or more multi-bit interface lock flags.

14. The method of claim 13, further comprising: selectively controlling, by the arbiter, bus leader access on the data bus for at least one of the one or more interfaces based additionally on a value of a multi-bit security⁷ level flag that is part of the device security configuration data.

15. The method of claim 13, wherein the one or more interfaces comprise an I²C interface and a SPI interface and the respective ones of the one or more multi-bit interface lock flags respectively comprise a multi-bit I²C lock flag and a SPI lock flag.

16. The method of claim 15, further comprising: communicating between the integrated circuit die and a follower tile integrated circuit die using a bus leader of the SPI interface located on the integrated circuit die and a bus follower of the SPI interface located on the follower tile integrated circuit die.

17. The method of claim 12, further comprising: selectively allowing, by a gate of a JTAG interface located on the integrated circuit die, access to a subset of a set of functions provided by the JTAG interface based on a value of a multibit JTAG interface flag of the one or more multi-bit interface lock flags.

18. The method of claim 11, further comprising, as part of the using the security verification logic gate to selectively enable writing the received device security' configuration data to the device control register: generating, by an AND gate of the security verification logic gate, an enable signal having an enable signal value based on a value of the multi-bit register lock flag; and selectively generating, by an integrated clock gating cell of the security verification logic gate, a gated clock output based on a value of the enable signal and a clock signal.

19. The method of claim 1 1, wherein the multi -bit register lock flag has a locked state and an unlocked state, and wherein the bits of the register lock flag in the unlocked state are equal in value to a bitwise XOR operation with operands of the bits of the register lock flag in the locked state and a binary value having the same number of bits as the multi-bit register lock flag, where each bit of said binary value is 1.

20. The method of claim 11, wherein the receiving device security configuration data for storage in a device control register of an integrated circuit die further comprises: receiving the device security data from a read-only memory located on the integrated circuit die via a data bus interface circuit coupled to the read-only memory and coupled to the data bus.