Deadlock / livelock detection

Abstract

A method to generate a hardware design for an electronic device wherein a digital hardware design under test (DUT) for the electronic device is received in a test environment, the digital hardware DUT having an input with a connected buffer; receiving assertions relating to the digital hardware DUT and the buffer; inputting watched data into the buffer; using a state machine to verify the assertions; detecting a deadlock or livelock in the digital hardware DUT in dependence on the verification; and in response to detecting a deadlock or livelock in the digital hardware, providing an output indicative of a deadlock or livelock state detected in the digital hardware DUT. The method may be used in simulation verification or formal verification, e.g. dynamic simulation, particularly for system-on-chip (SoC) designs where computing elements are connected by a fabric or a bus. The DUT may be a high-level language description of a component of a SoC. The buffer may be part of the DUT or a test bench and the watched data may be symbolic data. Assertions may be provided in SystemVerilog Assertions (SVA), Property Specification Language (PSL) or Open Verification Language (OVL). The state machines may be finite state machines (FSM).

Description

Field of the invention The present invention relates to a method and system of generating a hardware design for an electronic device. In particular, the method and system can be used to detect deadlock or livelock in order to allow a design to be refined. Background to the invention It is important to verify that hardware designs (e.g. system-on-chip (SoC) designs) meet their required specification before the design is implemented. It is known to verify hardware designs using simulation verification or formal verification. As part of the verification process, it is investigated whether a deadlock or livelock can exist in the hardware design. A deadlock state refers to a state that cannot be transitioned out of at any point. A livelock state refers to a state that can be transitioned out of, but that the design will not make progress by functioning as intended once the state is transitioned out of. The deadlock or livelock state may, for example, occur as a result of multiple contenders competing for resource utilization, hazard avoidance, performance boost or fine-tuning area. In many hardware designs, it is necessary that no deadlock or livelock states exist in the design. If a deadlock or livelock is found, the design is refined to remove the issue, and reverified, prior to logic synthesis, physical design and then manufacture of a semiconductor. In conventional simulation verification, all the states in the hardware design are analysed by providing individual input vectors and tracking the behaviour of the design from beginning to end. Therefore, detection of deadlock or livelock states in this way can take large amounts of time and resources to complete. In addition, since the simulation runs through to completion, deadlock / livelock states are not identified until the end of the simulation which makes it difficult to identify the source of the deadlock / livelock. It is known to use formal verification to detect deadlocks / livelocks in a hardware design as disclosed in GB2526052. This document discloses a method and system which determines whether a hardware design can enter a deadlock state by detecting, through verification of assertions for key control signals, whether any of the key control signals can enter a deadlock state. Formal verification can be conducted using model checkers, such as SAT solvers. Model checkers can provide counter-examples and can run automatically, however as the number of states in hardware designs increase, model checkers can take large amounts of time and resources to complete. In order to offset some of the issues faced when using model checkers on large numbers of states, a methodology was presented in the presentation by R. Aneja, A. Darbari, N. Mhaske and P. Bjesse “Tackling the Complexity Problem in Control and Datapath Designs with Formal Verification” at Design and Verification Conference and Exhibition United States in 2019. The presentation slides are available online at: https: / / dvcon-proceedinqs.org / wp-content / uploads / tackling-the-complexity-problem-in-control-and-datapath-designs-with-formal-verification-presentation.pdf. In this document, watched data is arbitrary but fixed between the sampling in and sampling out by using a Sstable operator in SystemVerilog Assertions (standard IEEE 1800) as an assume property defined as follows, where wd is data that is to be watched: assume property (@(posedge elk) ##1 $stable(wd)); The Sstable operator in an assume property means that the value of the watched data is assumed to not change between sampling in and sampling out events. However, the inventors have found that $stable cannot integrate with simulation verification methods due to the $stable operator imposing an invariability of symbolic transactions overtime. It is desirable to provide a method and system which can be used in both formal and simulation verification. It is in this context that the present inventions have been devised. Summary of the invention In accordance with an aspect of the present invention, there is provided a method to generate a hardware design for an electronic device. It may be that the method comprises, in a processor, receiving (e.g. in a test environment) a digital hardware design under test (DUT) for the electronic device. It may be that the digital hardware DUT comprises an input. It may be that the method comprises connecting a buffer to the input. It may be that the method comprises receiving one or more assertions relating to the digital hardware DUT and the buffer. It may be that the method comprises inputting watched data into the buffer. It may be that the method comprises using one or more state machines to verify the one or more assertions. It may be that the one or more assertions are verified in dependence on the behaviour of the watched data in the buffer. It may be that the method comprises detecting a deadlock or livelock in the digital hardware DUT. It may be that the detection of a deadlock or livelock in the digital hardware DUT is in dependence on the verification. It may be that the method comprises, in response to detecting a deadlock or livelock in the digital hardware, providing an output indicative of a deadlock or livelock state detected in the digital hardware DUT. The method may be a method for detecting a deadlock or livelock in a hardware design for an electronic device. In accordance with an aspect of the present invention, there is provided a system to generate a hardware design for an electronic device. It may be that the system comprises a digital hardware design under test (DUT). It may be that the digital hardware DUT comprises an input. It may be that the system comprises a test bench. It may be that the test bench comprises a buffer. It may be that the system comprises one or more state machines. It may be that the one or more state machines are used to verify one or more assertions relating to the digital hardware DUT and the buffer. It may be that the system comprises an assertion unit. It may be that the assertion unit is in communication with the one or more state machines. It may be that the assertion unit is configured to receive the one or more assertions relating to the digital hardware DUT and the buffer. It may be that the test bench is configured to connect the buffer to the input. It may be that the test bench is configured to input watched data into the buffer. It may be that the test bench is configured to verify one or more assertions relating to the digital hardware DUT and the buffer. It may be that the verification is in dependence on the behaviour of the watched data in the buffer. It may be that the test bench is configured to detect a deadlock or livelock in the digital hardware DUT in dependence on the verification. It may be that the test bench is configured to, in response to detecting a deadlock or livelock in the digital hardware, provide an output indicative of a deadlock or livelock state detected in the digital hardware DUT. The system may be a system for detecting a deadlock or livelock in a hardware design for an electronic device. Advantageously, the above method and system can be used for formal verification and simulation verification, e.g. dynamic simulation. Dynamic simulation refers to simulating the behaviour of the design over time. In dynamic simulation, the Sstable operator cannot be used. This is because dynamic simulation relies on the variability of symbolic transactions over time and so the dynamic simulation will not work if the Sstable operator is used to fix the transaction in all reachable states. As such, it is not possible to transfer test benches using the Sstable operator into dynamic simulation tools. Advantageously, by using a buffer, the test bench and method can be used in both from formal verification and dynamic simulation verification tools. The buffer provides the functionality of keeping the watched data constant through the digital hardware DUT without using the Sstable operator, because the watched data is stored in the buffer. However, the buffer can be used in the test bench for dynamic simulation because the buffer is variable in all reachable states, but the watched data is protected inside the buffer and remains constant. Therefore, the variability of symbolic transactions over time is still achieved, as is necessary for dynamic simulation. The test bench and method can be transferred from a formal verification tool to a dynamic simulation verification tool. This is beneficial as it improves ease of use when switching between formal verification and dynamic simulation verification tools because the formal test bench can be reused as the dynamic simulation test bench. Advantageously, by tracking the state of the watched data in the buffer, the correctness of the digital hardware DUT can be verified. Using the claimed invention in formal verification is a more environmentally friendly type of verification compared to the existing technologies used for verification of digital hardware DUTs. Simulation-based verification has a large power consumption for exhaustive checking of complex semiconductors. In contrast, in formal verification since all states are checked without providing individual stimuli as in simulation-based verification, formal verification uses fewer computing resources than simulation-based verification because it can be performed more quickly and with less computing power. As a result, this invention uses less energy and is more energy efficient compared to existing technologies for verifying digital hardware DUTs using simulation-based verification techniques. It may be that the method comprises tracking a single symbolic data chosen by an arbitrary point of sampling (e.g. in time). It may be that the test bench is configured to track a single symbolic data chosen by an arbitrary point of sampling (e.g. in time). Therefore, using temporal abstraction (using a non-deterministic time point), data abstraction is achieved (e.g. by choosing an arbitrary data value to track all data values). Typically, the assertions relate to the progress of the watched data through the DUT (for example, output of the watched data from the DUT) and refer to the watched data stored in the buffer. For example, the assertions may relate to the buffer rather than to the input. Advantageously, deadlocks and livelocks are detected when watched data is stuck in the design. This is because the assertion fails the verification because the watched data does not appear on an output of the DUT when it should do. It may be that the digital hardware DUT is a high-level language description of a System on Chip (SoC). Advantageously, the method and system described herein are particularly helpful for detecting deadlocks in SoCs, where it is essential that deadlock and livelock states do not exist in the hardware design. Typically, a SoC comprises one or more computing elements on a single chip connected by a network-on-chip (i.e. point-to-point connections between any processing element (e.g., CPU, or GPU) and memory (RAM), or peripherals such as USB, HDMI, ethernet etc.). The SoC may comprise one or more computing elements on a single chip connected by a fabric, one or more computing elements on a single chip connected by a bus. Typically, the one or more computing elements comprise at least one of: a central processing unit (CPU), a digital signal processor (DSP), a graphics processing unit (GPU), one or more multimedia encoder / decoders, direct memory access (DMA), network interface card (NIC) and one or more data storage modules. It will be appreciated that this list is not exhaustive and other computer elements will be envisaged. Typically, the digital hardware DUT is a component of a system. It may be that the digital hardware DUT is a high-level language description of a component of a System on Chip (SoC). It may be that the digital hardware DUT is a component of a pipelined process. Advantageously, the application of the system and method to a component of a pipelined process is particularly useful because deadlock or livelock states in such a component affects the following components of the pipelined process. Therefore, it is beneficial to be able to determine whether there are any states in which a deadlock or livelock exists before the hardware design is built. Typically, a pipelined process comprises a number of components connected in series. Typically, the test environment is a test bench which forms the verification environment for the digital hardware DUT. Typically, the input is configured to receive input data and transfer the data to the digital hardware DUT. It may be that the process of the input receiving input data and transferring the data to the digital hardware DUT is a transaction. It may be that the input comprises an input bus. It may be that the input comprises a plurality of wires. The input may comprise one or more wires at any place, or places, within a SoC. The data may be a data record. Typically, the buffer is a data buffer. Typically, the buffer stores inputted data as it progresses through the digital hardware DUT. The digital hardware DUT may comprise the buffer. The test bench may comprise the buffer. The buffer is typically connected to the input such that data entering the input, to be inserted into the digital hardware DUT, may be inputted into (e.g. added to or inserted into) the buffer. Typically, the watched data is data that is tracked through the digital hardware DUT by the test bench. It may be that the watched data is selected (e.g. at random) by the test bench. It may be that the watched data is selected (e.g. at random) by the verification tool.. It may be that the watched data is data that is internal to the design. It may be that the watched data is symbolic data. Typically, symbolic data enters the input and is inputted into the buffer and remains as symbolic data in the buffer It may be that the watched data is semi-symbolic. That is, the watched data may comprise data that is partially indicative of one or more bits used in the hardware design. The watched data may be abstracted data in that it represents a place holder for multibit data processed in the digital hardware DUT. The watched data may be abstracted in time. It may be that the method comprises inputting the watched data into the buffer in dependence on a free variable. It may be that the test bench is configured to input the watched data into the buffer in dependence on a free variable. Advantageously, the method and system are able to verify the digital hardware DUT using multiple occurrences of the watched data being entered in the input. This is particularly beneficial because using multiple occurrences of the watched data allows for completeness of the verification in that all possible input data values on the input and all possible inter-leavings of time can be observed. Typically, the free variable is used to drive the input of the watched data into the buffer. The free variable may be controlled by the test bench to be ‘high’ or ‘low’. When the free variable is ‘high’ and the watched data enters the input, the watched data may be inputted into the buffer. When the free variable is ‘low’ and the watched data enters the input, the watched data may not be inputted into the buffer. In this way, the free variable drives the input of the watched data into the buffer. It may be that the free variable comprises an undriven wire. Advantageously, using an undriven wire is an effective way of implementing a free variable in SystemVerilog for formal verification. Typically, an assertion is an output property that needs to be verified (e.g. by the formal checker tool). The one or more assertions typically comprise a number of statements relating to properties of the hardware design. Typically, an assertion comprises a statement of something that must be proven to hold for all reachable states in the hardware design. It may be that the one or more assertions are provided in an assertion computer programming language, such as SystemVerilog Assertions (SVA). However, other types of assertion computer programming language will be envisaged , such as, but not limited to, Property Specification Language (PSL) and Open Verification Language (OVL). Typically, the one or more state machines may be one or more finite state machines (FSM). They may, for example, be implemented by an electronic circuit, such as a microprocessor in communication with a solid-state memory and executing a program. Typically, the one or more state machines each comprises a model that represents possible states of a hardware design. The one or more state machines can transition in and out of states. When the one or more state machines are unable to transition out of a state to make expected progress through the design, a deadlock or livelock state is reached. As previously mentioned, a deadlock state refers to a state that cannot be transitioned out of at any point and a livelock state refers to a state that can be transitioned out of, but the design will not make progress by functioning as intended once the state is transitioned out of. In this way, the one or more state machines verify whether the one or more assertions hold for every reachable state in the digital hardware DUT. If a deadlock or livelock state exists in the one or more state machines, the assertion fails. If a deadlock or livelock state does not exist in the one or more state machines, the assertion passes. It may be that the one or more assertions are verified in dependence on the behaviour of the buffer. It may be that the verification is in dependence on the behaviour of the buffer. The method may comprise monitoring the behaviour of the watched data in the buffer. The test bench may be configured to monitor the behaviour of the watched data in the buffer. The method may comprise tracking progress of the watched data in the buffer through the digital hardware DUT. The test bench may be configured to track progress of the watched data in the buffer through the digital hardware DUT. It may be that verification of the one or more assertions takes into account the behaviour of the watched data in the buffer. The test bench may be configured to verify the one or more assertions by taking into account the behaviour of the watched data in the buffer. Typically, the behaviour of the watched data in the buffer refers to how the watched data in the buffer progresses through the digital hardware DUT. In some embodiments, the watched data in the buffer may be modified by the DUT as it passes through the DUT, for example it may become encrypted or decrypted. In some embodiments, the watched data in the buffer is not modified as it passes from an input to an output of the DUT. Typically, the behaviour of the watched data in the buffer refers to an output of the digital hardware DUT in relation to the buffer. Typically, the behaviour of the watched data in the buffer refers to a correlation between the watched data on the input and the watched data on the output. Typically, the behaviour of the watched data in the buffer refers to the expected output of the digital hardware DUT of the watched data in the buffer (e.g. compared to the actual input of the digital hardware DUT of the watched data in the buffer). Typically, the behaviour of the watched data in the buffer may comprise a timing of a transaction relating to the watched data in the buffer (e.g. relative to a timing of the watched data on the input). Typically, the behaviour of the watched data in the buffer data may comprise a value of the watched data (e.g. relative to a value of the watched data on the input). It may be that the digital hardware DUT comprises an output. It may be that the output comprises an output bus. It may be that the output comprises a plurality of wires. The method may comprise connecting the buffer to the output. It may be that the test bench is configured to connect the buffer to the output. Typically, based on the behaviour of the watched data in the buffer, the one or more assertions are verified. Typically, if the behaviour of the watched data in the buffer indicates that there exists a reachable state in the digital hardware DUT that does not fulfil the requirements of an assertion, the verification of that assertion fails. Typically, if the behaviour of the watched data in the buffer indicates that there is no state that exists in the digital hardware DUT that fails to fulfil the requirements of an assertion, the verification of that assertion passes. It may be that the assertion unit is distributed within the system between the test bench and outside of the test bench. It may be that the assertion unit is a component of the test bench (e.g. entirely within the test bench). It may be that the assertion unit is a component of the system outside of the test bench (e.g. entirely outside of the test bench). Typically, depending on the result of the verification of the one or more assertions are verified (i.e. fail or pass), a deadlock or livelock may be detected in the digital hardware DUT. Typically, if the verification of an assertion fails, the method may comprise determining whether a deadlock state exists in the digital hardware DUT. Typically, if the verification of an assertion fails, the method may comprise determining whether a livelock state exists in the digital hardware DUT. Typically, if the verification of an assertion fails, the test bench may be configured to determine whether a deadlock state exists in the digital hardware DUT. Typically, if the verification of an assertion fails, the test bench may be configured to determine whether a livelock state exists in the digital hardware DUT. It may be that the output indicative of a deadlock or livelock state comprises a visual indication of the existence of a deadlock or livelock state in the digital hardware DUT. It may be that the visual indication of the existence of a deadlock or livelock state in the digital hardware DUT comprises a symbol and / or message. It may be that the method step of using one or more state machines to verify the one or more assertions in dependence on the behaviour of the watched data in the buffer comprises updating one or more registers (e.g. of the test environment). It may be that the test bench comprises one or more registers. It may be that the test bench is configured to update the one or more registers. Advantageously, the one or more registers can be used to store data relating to the transactions of the digital hardware DUT. This is beneficial because the behaviour of the watched data in the buffer can be monitored using the registers. Typically, the registers are configured to perform a read to the register in dependence on a transaction occurring in the digital hardware DUT. Typically, the registers may be used to store data for monitoring the behaviour of the watched data in the buffer. It may be that the one or more registers comprises a first register configured to register that the watched data entered the digital hardware DUT (e..g register that the watched data appeared on the input and is inputted into the buffer). It may be that the one or more registers comprises a second register configured to register that the watched data exited the digital hardware DUT (e.g. register that the watched data appeared on the output). It may be that at least one of the one or more registers functions as a counter. Advantageously, a register, when implemented as a counter can keep track of expected behaviour of the watched data in the buffer. In particular, the counter can be used to determine when the watched data should exit the digital hardware DUT. Typically, a register functions as a counter when it increments and / or decrements based on a transaction occurring in the digital hardware DUT. It may be that the counter is configured to increment when the first register has a particular value. It may be that the counter is configured to decrement when the second register has a particular value. It may be that the method step of using one or more state machines to verify the one or more assertions in dependence on the behaviour of the watched data in the buffer comprises determining expected behaviour of the watched data in the buffer. It may be that the method step of using one or more state machines to verify the one or more assertions in dependence on the behaviour of the watched data in the buffer comprises detecting actual behaviour of the watched data in the buffer. It may be that the method step of using one or more state machines to verify the one or more assertions in dependence on the behaviour of the watched data in the buffer comprises comparing an expected behaviour of the watched data in the buffer to actual behaviour of the watched data in the buffer. It may be that the method step of using one or more state machines to verify the one or more assertions in dependence on the behaviour of the watched data in the buffer comprises verifying the one or more assertions in dependence on the comparison of behaviour of the watched data in the buffer. It may be that the system comprises a comparison unit. It may be that the comparison unit is in communication with the one or more state machines. It may be that the comparison unit compares expected behaviour of the watched data in the buffer and detected behaviour of the watched data in the buffer. It may be that the test bench is configured to determine the expected behaviour of the watched data in the buffer. It may be that the test bench is configured to detect the actual behaviour of the watched data in the buffer. It may be that the test bench is configured to compare the expected behaviour of the watched data in the buffer to the actual behaviour of the watched data in the buffer. It may be that the test bench is configured to verify the one or more assertions in dependence on the comparison of behaviour of the watched data in the buffer. Advantageously, the comparison of expected and actual behaviour of the watched data in the buffer provides an efficient way of verifying the one or more assertions. This is because the watched data in the buffer is expected to have certain behaviour for a given assertion. If the actual behaviour of the watched data in the buffer is the same as the expected behaviour of the watched data in the buffer, then the assertion holds for all reachable states in the hardware design. However, if the actual behaviour of the watched data in the buffer is different to the expected behaviour of the watched data in the buffer, then the assertion does not hold for all reachable states in the hardware design. It may be that the comparison unit is distributed within the system between the test bench and outside of the test bench. It may be that the comparison unit is a component of the test bench (e.g. entirely within the test bench). It may be that the comparison unit is a component of the system outside of the test bench (e.g. entirely outside of the test bench). Typically, the expected behaviour of the watched data in the buffer refers to how the watched data in the buffer progresses through the digital hardware DUT for a given assertion. Typically, the expected behaviour of the watched data in the buffer refers to the expected output of the digital hardware DUT for a given input of watched data. Typically, the expected behaviour of the watched data in the buffer may comprise an expected timing of a transaction relating to the watched data in the buffer (e.g. relative to a timing of the watched data being inputted into the buffer on the input). Typically, the expected behaviour of the watched data in the buffer may comprise an expected value of the watched data (e.g. relative to a value of the watched data on the input). Typically, the actual behaviour of the watched data in the buffer refers to the observed output of the digital hardware DUT for a given input to the buffer. Typically, the actual behaviour of the watched data in the buffer may comprise an observed timing of a transaction relating to the watched data in the buffer (e.g. relative to a timing of the watched data being inputted into the buffer on the input). Typically, the actual behaviour of the watched data in the buffer may comprise an observed value of the watched data (e.g. relative to a value of the watched data on the input). Typically, the comparison between the expected and actual behaviour of the watched data in the buffer comprises determining whether the actual and expected behaviour of the watched data in the buffer is the same. If the expected and the actual behaviour of the watched data in the buffer are the same, the assertion may pass verification. If the expected and the actual behaviour of the watched data in the buffer are different, the assertion may fail verification. It may be that the method comprises receiving one or more assumptions relating to the digital hardware DUT. It may be that the method comprises receiving one or more assumptions relating to the buffer. It may be that the method comprises applying the one or more assumptions to the one or more state machines. It may be that the system comprises an assumption unit. It may be that the assumption unit is in communication with the one or more state machines. It may be that the assumption unit is configured to receive one or more assumptions relating to the digital hardware DUT. It may be that the assumption unit is configured to receive one or more assumptions relating to the buffer. It may be that the test bench is configured to apply the one or more assumptions to the one or more state machines. Advantageously, assumptions can be used to restrict the digital hardware DUT to comply with specifications of the hardware design. That is, the assumptions can be used to place limitations on the digital hardware DUT without requiring that the limitations are verified (i.e. tested to hold in all reachable states of the hardware design). In addition, the assumptions can be used to reduce the number of reachable states available to the one or more state machines when performing verification. This is particularly advantageous as reducing the number of states across which the assertion must be proven to hold reduces the amount of time and computing power necessary to perform the verification and ultimately detect whether any deadlock or livelock states exist in the hardware design. It may be that the assumption unit is distributed within the system between the test bench and outside of the test bench. It may be that the assumption unit is a component of the test bench (e.g. entirely within the test bench). It may be that the assumption unit is a component of the system outside of the test bench (e.g. entirely outside of the test bench). It may be that the one or more assumptions are part of the digital hardware DUT. Typically, an assumption is a property of the hardware design that is assumed to hold for all reachable states of the design. An assumption is not a property that is tested whether it holds true for all reachable states of the hardware design. The one or more assumptions typically comprise a number of statements relating to properties of the hardware design. Typically, an assumption comprises a statement of something that holds for all reachable states of the design, without requiring proof (i.e. it is assumed to be true). It may be that the one or more assumptions are provided in an assertion computer programming language, such as SystemVerilog Assertions (SVA). However, other types of assertion computer programming language will be envisaged. Typically, the term “unit” when used in relation to at least one of the assertion unit, assumption unit and comparison unit may refer to an electronic circuit, or at least a portion of an electronic circuit. It may be that the electronic circuit is formed of circuitry, for example transistors and / or other hardware elements. The circuitry may be implemented to form one or more of: registers, flip flops, latches, logical operators, and mathematical operators. It may be that the method comprises providing an output indicative of a source (e.g. in the digital hardware DUT) of the deadlock or livelock state detected in the digital hardware DUT. It may be that the test bench is configured to provide an output indicative of a source, in the digital hardware DUT, of the deadlock or livelock state detected in the digital hardware DUT. Advantageously, the visual output indicative of a source of the deadlock or livelock state detected in the digital hardware DUT allows the user to quickly identify the source of bugs and errors in the digital hardware DUT. It may be that the visual indication comprises a portion of a wave form presented in a different way to the rest of the waveform, e.g. shown in a different colour, outlined or marked differently. The user is typically able to identify said visual indication and investigate the source of the bug or error which causes the deadlock or livelock at the point in the design in which the bug or error exists. The user can therefore modify the hardware design to resolve and fix bugs or errors in the design in a much quick manner than if the user were required to individually work through each transaction or cycle in the design to identify the source of the dealock or livelock. It may be that the method comprises carrying out formal verification of the one or more assertions. It may be that carrying out formal verification comprises using a formal verification tool to search an entire reachable state space of the digital hardware DUT to determine whether there is a state in which any of the one or more assertions relating to the digital hardware DUT is not valid. It may be that the system is configured to perform formal verification of the one or more assertions. It may be that the system is such that the test bench is configured to use a formal verification tool. It may be that the formal verification tool searches an entire reachable state space of the digital hardware DUT. It may be that the formal verification tool searches an entire reachable state space of the digital hardware to determine whether there is a state in which any of the one or more assertions relating to the digital hardware DUT is not valid. Advantageously, the method and system can be used for formal verification, which is quicker than simulation verification because it does not involve providing an individual input vector for each state. Typically, formal verification uses a formal verification tool, such as Jasper (Jasper is a trade mark of Cadence Design Systems, Inc.), JasperGold (JasperGold is a trade mark of Cadence Design Systems, Inc.), VC Formal (VC Formal is a trade mark from Synopsys, Inc.), Questa PropCheck (Questa PropCheck is a trade mark from Siemens AG), Questa OneSpin Static Formal (Questa OneSpin Static Formal is a trade mark from Siemens AG) and SymbiYosys (SymbiYosys from YosysHQ GmbH). Typically, the formal verification tool comprises one or more SAT solvers, which are Boolean satisfiability problem solvers. Typically, formal verification is implemented by tracking the order of symbolic transactions, which are encoded using Boolean symbols rather than using individual Os and 1s to track every individual state of the transaction. Before the model checking is started conceptually, the one or more assertions may be logically negated before they are combined with register translation level (RTL), constraints and the model in the testbench to result in a Boolean formula. The Boolean formulas are unfolded for every time point during model checking and so they are sent to SAT solvers to compute if there is a satisfying assignment of Boolean values to variables (signals in the RTL, test bench and constraints) in this formula. Since the assertion was negated, when the SAT solver finds a satisfying assignment, this is actually indicative of a bug being present in the hardware design. It may be that, after carrying out formal verification, then the method comprises carrying out simulation verification of the one or more assertions relating to the digital hardware DUT. It may be that carrying out simulation verification comprises applying stimuli to the digital hardware DUT. It may be that carrying out simulation verification comprises detecting, using the one or more state machines, the state of one or more data signals in response to the stimuli. It may be that carrying out simulation verification comprises evaluating the one or more assertions for each of the one or more data signals to detect whether any of the one or more data signals have entered a deadlock or livelock state. It may be that the system is configured to perform simulation verification of the one or more assertions relating to the digital hardware DUT, after performing formal verification. It may be that the system is such that the test bench is configured to apply stimuli to the digital hardware DUT. It may be that the test bench is configured to detect, using the one or more state machines, the state of the one or more data signals in response to the stimuli. It may be that the test bench is configured to evaluate the one or more assertions for each of the one or more data signals to detect whether any of the one or more data signals have entered a deadlock or livelock state. Advantageously, the simulation verification may be performed after the formal verification using the same method and system. This is beneficial because these allows for assumptions used in formal verification to be validated. The assumptions used in formal verification may become assertions in simulation verification by default. If these assertions were to fail for an input test sequence in simulation, this can indicate that the input assumption used in formal verification was not valid. This in turn means the assumptions used in formal verification must be reviewed and formal verification may have to be re-run to check all the assertions under the modified assumption. Typically, the stimuli comprise an individual input vector for each state. Typically, the state for each stimulus is detected. Typically, after the input vector is tracked from beginning to end, any deadlock or livelock in the design will cause the states related to these transactions not to update as expected in the global scoreboard. When the simulation is complete, it may be that the global scoreboard is used to evaluate the assertions for each data signal. Based on the evaluation, it is possible to detect a deadlock or livelock in the hardware design. According to an aspect of the present invention, there is provided a computer readable storage medium having encoded thereon computer readable program code configured to perform the method described above. Although the embodiments of the invention described with reference to the drawings comprise methods performed by a system, such as a computing device, the invention also extends to program instructions, particularly program instructions on or in a carrier, adapted for carrying out the processes of the invention or for causing a computer to perform as the computer apparatus of the invention. Programs may be in the form of source code, object code, a code intermediate source, such as in partially compiled form, or any other form suitable for use in the implementation of the processes according to the invention. The carrier may be any entity or device capable of carrying the program instructions. For example, the carrier may comprise a storage medium, such as a ROM, for example a CD ROM or a semiconductor ROM, or a magnetic recording medium, for example a floppy disc or hard disc. Further, the carrier may be a transmissible carrier such as an electrical or optical signal which may be conveyed via electrical or optical cable or by radio or other means. When a program is embodied in a signal which may be conveyed directly by cable, the carrier may be constituted by such cable or other device or means. Description of the Drawings An example embodiment of the present invention will now be illustrated with reference to the following Figures in which: Figure 1 is a schematic of a system according to an embodiment of the invention; Figures 2 to 9 are flowcharts of a method according to an embodiment of the invention; Figure 10 is a schematic of a computing device according to an embodiment of the invention; and Figure 11 is an example waveform of a verification tool using a method according to an embodiment of the invention, where the x-axis depicts clock cycles. Detailed Description of an Example Embodiment Figure 1 is a schematic of a system 100 according to an embodiment of the invention. The system 100 can be used in both formal verification and simulation verification techniques. The system 100 comprises a digital hardware design under test (DUT) 110, described in a hardware description language, and including an input bus 112, functioning as the input. In other examples, the input may not be limited to an input bus but may comprise wires from a number of different places within the SoC. In this example, the DUT 110 is a First-Input-First-Output (FIFO) which forms part of a pipelined process and is a component of a System on Chip. The system 100 also comprises a test bench 120, also described in a hardware description language, which includes a buffer 122. The buffer 122 is configured to store data received on the input bus 112 of the DUT 110. Data is transferred between the input bus 112 and the buffer 122 by communication bus 105. The system 100 also includes a plurality of state machines 130 which are used to verity assertions across all of the reachable states of the digital hardware DUT 110. The assertions are received by the assertion unit 140. The assertions relate to the digital hardware DUT 110 and the buffer 122 and are statements of properties that are to be tested to hold true for all states of the design (at a particular clock cycle or eventually at some clock cycle). The assertion unit 140 is shown as part of the test bench 120 in this example, however it will be appreciated that the assertion unit 140 could be entirely outside of the test bench 120 or distributed between the test bench 120 and the outside of the test bench 120. The test bench 120 connects the buffer 122 to the input bus 112 and inputs watched data that appears on the input bus 112 into the buffer 122. The test bench 120 verifies the assertions depending on the behaviour of the buffer 122. Based on the verification, the test bench 120 detects a deadlock or livelock in the digital hardware DUT 110 and provides an output to an external computing device 190 which indicates that a deadlock or livelock state has been detected in the digital hardware DUT 110 and also provides an output of the source of the deadlock or livelock. The external computing device 190 communicates with the communication bus 105 of the system but in some examples, the system 100 may have a communication module to communicate with the external computing device 190. The test bench 120 also includes a first register 124, a second register 126 and a third register 128 which functions as a counter. The registers 124, 126 and the counter 128 are updated as will be discussed later. The system 100 includes a comparison unit 150 which is in communication with the state machines 130 and the test bench 120 through communication bus 105. The comparison unit 150 compares expected behaviour of the watched data in the buffer 122 to actual behaviour of the watched data in the buffer 122 as will be discussed later. The comparison module 150 verifies the assertions depending on the outcome of the comparison. The comparison unit 150 is shown as part of the system 100 outside of the test bench 120 in this example, however it will be appreciated that the comparison unit 150 could be entirely within the test bench 120 or distributed between the test bench 120 and outside of the test bench 120. The system 100 includes an assumption unit 160 which is in communication with the state machines 130 and the test bench 120 through communication bus 105. The assumption unit 160 receives assumptions relating to the digital hardware DLIT 110 and the buffer 122. The assumption unit 160 provides the assumptions to the test bench 120 and the assumptions are applied to the DUT 110. The assumption unit 160 is shown as part of the system 100 outside of the test bench 120 in this example, however it will be appreciated that the assumption unit 160 could be entirely within the test bench 120 or distributed between the test bench 120 and outside of the test bench 120. The system 100 can be used to perform formal verification of the assertions using a formal verification tool to search an entire reachable state space of the digital hardware DUT 110 and then performing simulation verification of the assertions relating to the digital hardware DUT 110. Figure 2 is a flowchart of a method 200 according to an embodiment of the invention. The method 200 will be exemplified by application of the method 200 to a First-Input-First-Output (FIFO) design. As will be understood, it is a requirement of a FIFO that data is output from the FIFO in the same order that it entered the FIFO. In block 205, the DUT is loaded into the test environment. The DUT may be preconfigured and stored in a memory accessible to the test environment. In block 210, the input bus ‘dataj’ of the DUT is connected to the buffer ‘wd’ of the test bench. In block 215, the assertion to be verified is received. This assertion states that when the ready_to_sample_out register is ‘high’, the data on the output bus, data_o in the next clock cycle will be the watched data in the buffer. assert property (@(posedge elk) ready_to_sample_out |=> (data_o == wd)); It will be appreciated that this example method uses the positive edge of the clock signal (“@(posedge elk)”), however other examples could use the negative edge of the clock signal (“@(negedge_clk)”), or any other event in the design or testbench. The method also includes, in this example, method 600. Figure 6 is a flowchart of a method 600 according to an embodiment of the invention. In particular, the method 600 comprises receiving 605 assumptions and applying 610 the assumptions to the state machines. The two assertions used in this example are: 1) assume property (@(posedge elk) empty_o |-> IpopJ); 2) assume property (@(posedge elk) full_o |-> IpushJ || popj); Assumption 1 means that if FIFO is empty then there must not be a pop in the same clock cycle, where a pop is a read out of the FIFO. Assumption 2 means that if the FIFO is full then either there is no push, or if you do have a push, then there is also a pop in the same cycle. The method also includes, in this example, method 400. Figure 4 is a flowchart of a method 400 according to an embodiment of the invention. In method 400 two registers are set up in the test bench and are updated as will be discussed below. reg sampledjn; reg sampled_out; There are also conditions for setting the registers which are defined as wire ready_to_sample_in; wire ready_to_sample_out; Another register is provided as a counter as part of method 400 and set up to increment and decrement using the following code: assign incr = push_i &&Isampledjn; assign deer = popj &&!sampled_out; reg [DEPTH_BITS:0] data_count; sampledjn indicates that the watched data has entered in the FIFO. sampled_out indicates that watched data has exited the FIFO. data_count is used to count values ahead of watched data in the FIFO. Therefore, when there is a push and the sampledjn register is low (i.e. the watched data has not been sampled in), there is an increment because the watched data is not input into the buffer yet. Once the watched data has entered the FIFO (via the buffer 122), the counter stops incrementing. When there is a pop and the sampled_out register is low (i.e. the watched data has not been sampled out), there is a decrement in the counter. The register data_count is the counter to determine how many items of data are ahead of the watched data in the FIFO. Once the watched data has exited the FIFO, the counter reads zero. In block 220, the watched data is inputted into the FIFO, for example using the code below: logic [DATA_WIDTH-1:0] wd; always @(posedge elk) begin if (ready_to_samplejn) wd <= data J; end The block 225 involves using the state machines to verify the assertion. In this example blocks 220 and 225 also includes method 300. Figure 3 is a flowchart of a method 300 according to an embodiment of the invention. The watched data is written into the FIFO when the undriven wire, functioning as a free variable, sampling_point is high. The following line sets an undriven wire using “sampling_point” which allows random selection of data in the input interface as the watched data. logic sampling_point; Therefore, when: i) the sampling_point is high; ii) the increment is high (meaning that there is a push); and iii) the sampledjn register is low (meaning the chosen watched data has not already entered the FIFO), then ready_to_sample_in is set as high as the data in the input bus will be inserted into the buffer as watched data in the next clock cycle. When: i) the data_count is 1 (meaning that all data ahead of the watched data has exited the FIFO and the next data in the order of input into the FIFO is the watched data); ii) the sampledjn register is high (meaning that the watched data entered the FIFO); iii) the decrement is high (meaning that there is a pop); and iv) the sampled_out register is low (meaning that the watched data has not already exited the FIFO) then the ready_to_sample_out is set as high and the watched data is output in the next clock cycle. This is implemented in this example using the following code: assign readyJo_sampleJn = sampling_point &&incr &&!sampled_in; assign readyJo_sample_out = (data_count==‘d1) &&sampledjn &&deer &&!sampled_out always @(posedge elk or negedge resetn) if (Iresetn) begin sampledjn <= 1’bO; sampled_out <= 1’bO; end else begin sampledjn <= sampledjn || ready_to_samplejn; sampled_out <= sampled_out || ready_to_sample_out; end In this example, the assertion is verified by the method 500 depicted in Figure 5. In particular, the method 500 comprises determining 505 expected behaviour of the watched data in the buffer and detecting 510 actual behaviour of the watched data in the buffer. The expected and actual behaviours of the watched data in the buffer are compared in block 515. Finally, the assertion is verified 520 depending on the comparison. For example, the expected behaviour may be that the watched data in the buffer wd will appear on data_o at a given clock cycle ‘n’ as the counter reaches 1 in the clock cycle ‘n-1’ and the ready_to_sample_out register is ‘high’. However, the actual behaviour may be that the watched data in the buffer wd never appears on data_o. Therefore, the assertion that, for every reachable state in the design, when the ready_to_sample_out register is ‘high’, the data on the output bus, data_o in the next clock cycle is the watched data in the buffer, does not hold true. Therefore, in block 230, a deadlock is detected because the watched data is never read out of the FIFIO. Subsequently, an output is provided 235 which indicates to the user that there is a deadlock state in the design. In addition, the method 700 is performed as part of this block 235. The method 700 is shown in the flowchart of Figure 7. In method 700, an output of the source of the deadlock in the design is also provided, which is a flag of which clock cycle the bug is found. The method 200 may be employed in the method 800 which is shown in the flowchart of Figure 8. The method 800 comprises carrying out 805 formal verification using 810 a formal verification tool to search every reachable state space. By searching every reachable state space, it is determined 815 whether there is a state in the assertion relating to the digital hardware DUT is not valid. The method 200 may be employed in a simulation verification method 900, which is depicted in the flowchart of Figure 9. The method 900 comprises carrying out 905 simulation verification by applying 910 stimuli, in the form of individual input vectors, to the digital hardware DUT. The method 900 then comprises detecting 915, using the one or more state machines, the state of one or more data signals in response to the stimuli. Finally, the method 900 comprises evaluating 920 the assertion for each data signal to detect whether any of the data signals have entered a deadlock or livelock state. If all verification steps are successfully complete, the design may be synthesized and used to create a semiconductor topology for manufacture. However, if a deadlock or livelock is found, the design is instead reviewed, revised and verified again in the same way. Figure 10 is a schematic of an exemplary computing-based device 1000, and in which embodiments of the systems and methods described above for generating a hardware design for an electronic device. The computing device 1000 includes one or more processors 1002 and a storage media 1008. The components of the computing device 1000, such as the one or more processors 1002 and the storage media 1008 communicate with one another via a system bus 1003. The one or more processors 1002 (e.g. central processing units (CPUs), graphics processing units (GFU5 or VPU5), digital signal processors (DSPs), microprocessors) execute computer executable instructions to control the operation of the computing device 1000. The storage media 1008 comprises a non-volatile storage medium, such as read only memory (ROM) 1004 and a volatile storage medium, such as a random access memory (RAM) 1006. The computing device 1000 may be operable as part of a network connection to one or more remote computers, such as a remote computer 1588, by a local area network (LAN) or wide area network (WAN). The computing device may communicate through the network via communications module 1010. The computing-based device 1000 also includes an I / O controller which controls input device 1014 and output device 1016. The output device 1016 is a display screen which is connected to the system bus 1003. The display screen 1016 provides the output indicative of the deadlock or livelock detection. The input device 1014 receives a user input indicative of commands and information entered into the computing device 1000, for example a keyboard and / or mouse. In some cases the output device 1016 and the input device 1014 maybe a single component, e.g. a touchscreen. The computing device 1000 components may be distributed across a network in some examples. Figure 11 is an example waveform of a verification tool using a method according to an embodiment of the invention, where the x-axis depicts clock cycles. This waveform represents a FIFO as the digital hardware DUT. At clock cycle 5-6, the tool chooses to save the data on the input, dataj, as the watched data in the wd register (functioning as the buffer), while it is written into the FIFO, as seen in the data[5] register inside the FIFO. In this example, there is a signal called ‘read’ that needs to be high in order for the data to be read out. When the counter reaches 1, and we expect to see the watched data on the output (data_o) upon a pop, the data is not seen and hence the assertion fails. Upon further investigation, we find that the reason for this is a deadlock within the read signal logic i.e., when the read goes low it cannot become high ever again. Throughout the description and claims of this specification, the words “comprise” and “contain” and variations of them mean “including but not limited to”, and they are not intended to and do not exclude other components, integers, or steps. Throughout the description and claims of this specification, the singular encompasses the plural unless the context otherwise requires. In particular, where the indefinite article is used, the specification is to be understood as contemplating plurality as well as singularity, unless the context requires otherwise. Features, integers, characteristics, or groups described in conjunction with a particular aspect, embodiment, or example of the invention are to be understood to be applicable to any other aspect, embodiment or example described herein unless incompatible therewith. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and / or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and / or steps are mutually exclusive. The invention is not restricted to the details of any foregoing embodiments. The invention extends to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed.

Claims

aims1. A method to generate a hardware design for an electronic device, the method comprising, in a processor:receiving, in a test environment, a digital hardware design under test (DUT) for the electronic device, the digital hardware DUT having an input;connecting a buffer to the input;receiving one or more assertions relating to the digital hardware DUT and the buffer;inputting watched data into the buffer, wherein the watched data is symbolic or semi-symbolic data;using one or more state machines to verify the one or more assertions in dependence on the behaviour of the watched data in the buffer;detecting a deadlock or livelock in the digital hardware DUT in dependence on the verification; andin response to detecting a deadlock or livelock in the digital hardware, providing an output indicative of a deadlock or livelock state detected in the digital hardware DUT.

2. The method of claim 1, comprising inputting the watched data into the buffer in dependence on a free variable.

3. The method of claim 2, wherein the free variable comprises an undriven wire.

4. The method of any preceding claim, wherein the digital hardware DUT is acomponent of a pipelined process.

5. The method of any preceding claim, wherein using one or more state machines to verify the one or more assertions in dependence on the behaviour of the watched data in the buffer comprises updating one or more registers of the test environment.

6. The method of claim 5, wherein at least one of the one or more registers functions as a counter.

7. The method of any preceding claim, wherein using one or more state machinesto verify the one or more assertions in dependence on the behaviour of the watched data in the buffer comprises:determining expected behaviour of the watched data in the buffer; detecting actual behaviour of the watched data in the buffer;comparing an expected behaviour of the watched data in the buffer to actual behaviour of the watched data in the buffer; andverifying the one or more assertions in dependence on the comparison of behaviour of the watched data in the buffer.

8. The method of any of preceding claim, comprising receiving one or more assumptions relating to the digital hardware DUT and the buffer and applying the one or more assumptions to the one or more state machines.

9. The method of any preceding claim, wherein the digital hardware DUT is a high level language description of a System on Chip.

10. The method of any preceding claim, comprising providing an output indicative of a source, in the digital hardware DUT, of the deadlock or livelock state detected in the digital hardware DUT.

11. The method of any preceding claim, comprising carrying out formal verification of the one or more assertions using a formal verification tool to search an entire reachable state space of the digital hardware DUT to determine whether there is a state in which any of the one or more assertions relating to the digital hardware DUT is not valid.

12. The method of claim 11, comprising, after carrying out formal verification, then carrying out simulation verification of the one or more assertions relating to the digital hardware DUT by:applying stimuli to the digital hardware DUT;detecting, using the one or more state machines, the state of one or more data signals in response to the stimuli; andevaluating the one or more assertions for each of the one or more data signals to detect whether any of the one or more data signals have entered a deadlock or livelock state.

13. A computer readable storage medium having encoded thereon computer readable program code configured to perform the method of any of claims 1 to 12.

14. A system to generate a hardware design for an electronic device, the system comprising:a digital hardware design under test (DUT) comprising an input;a test bench comprising a buffer,one or more state machines used to verify one or more assertions relating to the digital hardware DUT and the buffer; andan assertion unit in communication with the one or more state machines, the assertion unit configured to receive the one or more assertions relating to the digital hardware DUT and the buffer,wherein the test bench is configured to:connect the buffer to the input,input watched data into the buffer, wherein the watched data is symbolic or semi-symbolic data,verify one or more assertions relating to the digital hardware DUT and the buffer in dependence on the behaviour of the watched data in the buffer,detect a deadlock or livelock in the digital hardware DUT in dependence on the verification, andin response to detecting a deadlock or livelock in the digital hardware, providing an output indicative of a deadlock or livelock state detected in the digital hardware DUT.

15. The system of claim 14, wherein the test bench is configured to input the watched data into the buffer in dependence on a free variable.

16. The system of claim 15, wherein the free variable comprises an undriven wire.28 03 2517. The system of any of claims 14 to 16, wherein the digital hardware DUT is a component of a pipelined process.

18. The system of any of claims 14 to 17, wherein the test bench comprises one or more registers and the test bench is configured to update the one or more registers.

19. The system of claim 18, wherein at least one of the one or more registers function as a counter.

20. The system of any of claims 14 to 19, comprising a comparison unit in communication with the one or more state machines, the comparison unit to compare expected behaviour of the watched data in the buffer and detected behaviour of the watched data in the buffer;wherein the test bench is configured to:determine the expected behaviour of the watched data in the buffer; detect the actual behaviour of the watched data in the buffer;compare the expected behaviour of the watched data in the buffer to the actual behaviour of the watched data in the buffer; andverify the one or more assertions in dependence on the comparison of behaviour of the watched data in the buffer.

21. The system of any of claims 14 to 20, comprising an assumption unit in communication with the one or more state machines, the assumption unit configured to receive one or more assumptions relating to the digital hardware DUT and the buffer, and wherein the test bench configured to apply the one or more assumptions to the one or more state machines.

22. The system of any of claims 14 to 21, wherein the digital hardware DUT is a high level language description of a System on Chip.

23. The system of any of claims 14 to 22, wherein the test bench is configured to provide an output indicative of a source, in the digital hardware DUT, of the deadlock or livelock state detected in the digital hardware DUT.28 03 251 24. The system of any of claims 14 to 23, wherein the system is configured to perform2 formal verification of the one or more assertions such that the test bench is3 configured to use a formal verification tool to search an entire reachable state4 space of the digital hardware DUT to determine whether there is a state in which5 any of the one or more assertions relating to the digital hardware DUT is not6 valid.78 25. The system of claim 24, wherein the system is configured to perform simulation9 verification of the one or more assertions relating to the digital hardware DUT, 10 after performing formal verification, such that the test bench is configured to:11 apply stimuli to the digital hardware DUT;12 detect, using the one or more state machines, the state of the one or13 more data signals in response to the stimuli; and14 evaluate the one or more assertions for each of the one or more data15 signals to detect whether any of the one or more data signals have entered a16 deadlock or livelock state.1718Application No: GB2406257.2Examiner: Paul JefferiesClaims searched: 1-25Date of search: 19 June 2024Patents Act 1977: Search Report under Section 17Documents considered to be relevant:Category Relevant to claims Identity of document and passage or figure of particular relevance X 1, 14 at least US 10108767 Bl (PURRI et al.) col.2 lis.42-47, col.6 li.4 to col.7 lis.59, col. 13 lis.58-65 and figs. 1, 3D X 1, 14 at least US 10628622 Bl (SIVARAMAN et al.) col.8, lis.34-55 and figs.6, 15 X 1, 14 at least US 2023 / 0032302 Al (LAVAGNO et al.) paras.0013, 0099-0100 and fig. 1; note FIFO 5 X 1, 14 at least US 2024 / 0046015 Al (TIBREWALA) paras.0059, 0097-0102 and fig.l A - US 2009 / 0241074 Al (TANIMOTO) paras.0099-0100 and fig.l, FIFO 5 A - JP 2010067270 A (TOSHIBA CORP) paras.0028-0029 and fig.2Categories:X Document indicating lack of novelty or inventive step A Document indicating technological background and / or state of the art. Y Document indicating lack of inventive step if P Document published on or after the declared priority date but combined with one or more other documents of same category. before the filing date of this invention. & Member of the same patent family E Patent document published on or after, but with priority date earlier than, the filing date of this application.Field of Search:International Classification:Subclass Subgroup Valid From G06F 0030 / 33 01 / 01 / 2020 G06F 0030 / 3308 01 / 01 / 2020 G06F 0030 / 3323 01 / 01 / 2020 G06F 0030 / 3308 01 / 01 / 2020Application No: GB2406257.2Examiner:Paul JefferiesClaims searched: 1-25Date of search: 20 December 2024Patents Act 1977: Search Report under Section 17Documents considered to be relevant:Category Relevant to claims Identity of document and passage or figure of particular relevance X 1-25 US 8381148 Bl (LOH et al.) figs.2, 4 and cols. 1-3, 9-12 A - GB 2526052 A (IMAGINATION TECH LTD) A - EP 4307158 A2 (IMAGINATION TECH LTD)Categories:X Document indicating lack of novelty or inventive step A Document indicating technological background and / or state of the art. Y Document indicating lack of inventive step if P Document published on or after the declared priority date but combined with one or more other documents of same category. before the filing date of this invention. & Member of the same patent family E Patent document published on or after, but with priority date earlier than, the filing date of this application.Field of Search:International Classification:Subclass Subgroup Valid From G06F 0030 / 33 01 / 01 / 2020 G06F 0030 / 3308 01 / 01 / 2020 G06F 0030 / 3323 01 / 01 / 2020 G06F 0030 / 3308 01 / 01 / 2020

Images