Assertion-Based Verification of I2C Module Using SystemVerilog

Abstract

In today’s semiconductor verification field, SystemVerilog Assertions (SVAs) are one of the most important methodologies for functional verification. A representative verification technique is Universal Verification Methodology (UVM)-based verification, which utilizes a SystemVerilog class library. On the other hand, Assertion-Based Verification (ABV) using SVA allows hardware designs to be verified without requiring knowledge of SystemVerilog’s Object-Oriented Programming (OOP) concepts or UVM. Its syntax is intuitive and concise, enabling rapid detection of RTL (Register Transfer Level) bugs during the design and verification phases. This methodology significantly enhances productivity by drastically reducing the time required for semiconductor development. This paper proposes an ABV verification environment using SVA that is reusable in other verification environments for verifying the main functions of the Inter-Integrated Circuit (I2C), one of the serial synchronous communication protocols. Finally, through the development of the RTL design and simulation of the core functionalities of I2C, the key characteristics of I2C were verified using ABV with SVA.

1. Introduction

Hardware verification is a crucial process used to ensure that a hardware design, implemented using a Hardware Description Language (HDL) such as Verilog-HDL or VHDL, functions as intended [1]. If a design bug is not detected during the verification phase but is instead discovered at the silicon stage, it can result in significant costs associated with design revisions. In addition to the financial burden, such errors inevitably cause disruptions in prototype production and supply chains. As the importance of verification continues to grow in the semiconductor development process, the increasing size and complexity of modern System-on-Chip (SoC) designs have made it nearly impossible to verify all functionalities using traditional Register Transfer Level (RTL)-based testbench verification techniques [2].

To address these challenges, new verification methodologies have been developed, and one of the most widely adopted approaches in the semiconductor industry today is the Universal Verification Methodology (UVM) [3,4,5,6]. UVM is a standardized verification methodology developed by the Accellera Systems Initiative to facilitate hardware design and verification within the semiconductor industry [7,8,9,10,11]. However, since UVM is implemented as a SystemVerilog-based class library, constructing testbenches and performing verification require an understanding of SystemVerilog’s OOP principles, class structures, and UVM-specific knowledge. Consequently, mastering this methodology demands a significant investment of time and effort.

In contrast, Assertion-Based Verification (ABV) using SystemVerilog Assertions (SVAs) offers a more intuitive and concise approach to hardware verification. Recently, Assertion-Based Verification (ABV) using SVA has gained increasing attention in both academia and industry due to its modularity and compatibility with both simulation and formal verification environments.

Banga et al. [12] proposed a method to encapsulate assertions in protocol-agnostic wrappers, improving portability and reusability across multiple IPs. Gupta and Saini [13] further demonstrated that SVA can effectively support formal verification of on-chip communication protocols, confirming the applicability of ABV to protocol-level correctness checking in both simulation and formal workflows.

A detailed methodology for generalizing assertion properties and enhancing their reusability is provided in Section 4.4.

These studies also highlight that ABV can be integrated with simulation- and formal-based flows to improve bug detection and timing property validation without requiring heavy testbench infrastructure. Although ABV is also based on SystemVerilog, it does not require prior knowledge of OOP, class concepts, or UVM. Instead, it enables straightforward verification of the target design’s functionalities and protocols in a more direct manner [7]. This makes ABV particularly effective for verifying serial synchronous communication protocols such as Inter-Integrated Circuit (I2C). Notably, SVA’s concurrent assertion mechanism significantly enhances verification efficiency. Furthermore, ABV provides high portability and reusability, making it applicable to various verification environments.

Previous research has introduced UVM-based verification implementations for digital logic and I2C module verification [14,15,16,17,18,19,20,21]. In this study, we propose a reusable ABV verification environment using SVA for verifying the key functionalities of the I2C protocol. Instead of utilizing a UVM-based verification framework, we design an I2C module using Verilog-HDL for low-speed serial communication and validate the design through an SVA-based ABV verification framework implemented using Cadence Xcelium 23.09. The proposed verification environment enables comprehensive verification of the core functionalities of the I2C protocol while also being adaptable to UVM verification environments, thereby enhancing the diversity and applicability of the verification process.

This paper is structured as follows. Section 2 introduces the architecture and operational principles of I2C, which serves as the primary subject of design and verification in this study. Section 3 presents the specifications, design, and RTL simulation results of the I2C module implemented in Verilog-HDL. Section 4 provides an overview of SVA and ABV, along with a detailed explanation of the ABV testbench architecture utilizing SVA for I2C verification. It also introduces assertion reuse and generalization techniques in Section 4.4 and compares ABV with UVM-based verification environments in Section 4.5. Section 5 discusses the experimental results of the proposed methodology in verifying key I2C functionalities. In particular, each assertion was generalized for reuse in both simulation and formal verification environments. All pass and fail cases were analyzed, and representative scenarios are visualized through timing diagrams. Finally, Section 6 presents the conclusions of this study.

2. Overview of the I2C Protocol

2.1. I2C Structure and Data Frame Configuration

Figure 1 illustrates I2C communication consisting of a single master and a single slave.

• Serial Clock Line (SCL): This is the clock line used by the master to synchronize communication with the slave.
• Serial Data Line (SDA): This is the data line used for transmission and reception between the master and the slave.

The master’s role is to transmit data to the slave using the SDA line. It sends a 7-bit master device identification (ID) field, an 8-bit slave address field, and a 1-bit Write/Read command field. During a Write operation, the master transmits an 8-bit data field to the slave. During a Read operation, the master sends a 1-bit negative acknowledgment (NACK) field to the slave as a response to the received data. If the data are received correctly, the NACK field is set to <1′b1>; otherwise, it is set to <1′b0>.

The slave’s role is to verify whether the received Device ID field and address field match its own information. As a response, the slave sends an acknowledgment (ACK) field (1 bit) to the master, where <1′b0> indicates a match and <1′b1> indicates a mismatch. During a Write operation, the slave receives the 8-bit data field from the master and responds with an ACK field. During a Read operation, the slave sends the requested data field to the master.

2.2. I2C Operation

Figure 2 illustrates a Write operation. The I2C START condition is initiated, and the master transmits the Device ID field and Write command field to the slave through the SDA signal line. The slave then responds by sending an ACK signal through the SDA signal line as a reception response signal field. After successfully receiving the ACK signal, the master transmits the slave address field via the SDA signal line and receives another ACK signal from the slave as a reception response signal field through the same line. Next, upon successfully receiving the ACK signal, the master transmits the data field to be sent through the SDA signal line to the slave. The slave responds with an ACK signal via the SDA signal line. Finally, the master issues the STOP condition to terminate the communication.

Figure 3 illustrates a Read operation. The I2C START condition is initiated, and the master transmits the Device ID field and Write command field to the slave through the SDA signal line. The slave then responds by sending an ACK signal via the SDA signal line as a reception response signal field. After successfully receiving the ACK signal, the master transmits the slave address field through the SDA signal line and receives another ACK signal from the slave as a reception response signal field. Next, upon successfully receiving the ACK signal, the master transmits the Device ID field and the Read command field via the SDA signal line. The slave then responds by sending an ACK signal through the SDA signal line as a reception response signal field. The slave prepares the requested data in the data field and transmits it to the master via the SDA signal line. After receiving the data, the master sends a NACK signal to the slave through the SDA signal line as a reception response signal field. Finally, the master issues the STOP condition to terminate the communication.

3. I2C Module Design

3.1. Design Specifications

Table 1. I2C design specification.

Items	Values
Device ID (Number of Bits)	7 bits
Address (Number of Bits)	8 bits
Command Bit	1 bit (<1′b0>: Write, <1′b1>: Read)
ACK (Number of Bits)	1 bit
NACK (Number of Bits)	1 bit
Clock Frequency	25 MHz
I2C SCL Frequency	100 KHz/400 kHz

presents the specifications for the I2C module design. The Device ID consists of 7 bits, while the Address is 8 bits. The Command field is 1 bit, where <1′b0> represents a Write operation, and <1′b1> represents a Read operation. The ACK and NACK fields are each 1 bit. The system main clock is set to 25 MHz by default but can be adjusted as needed. The I2C SCL frequency supports both 100 kHz and 400 kHz operation.

3.2. Design and RTL Simulation

The designed I2C module consists of [i2c_arbi], [i2c_tx], and [i2c_slave], as shown in Figure 4.

For the RTL simulation of the I2C module, the Device ID field is defined as <i2c_devid[6:0]> and set to <7′h78>. The Command field is represented by [i2c_rdwr]. The Slave Address field is defined as <i2c_addr[15:0]> and set to 8′hf. The Write data field is represented by <i2c_wrdata[15:0]>, with a value of 8′hff, while the Read data field is represented by <i2c_rddata[15:0]>.

Figure 5 illustrates the first waveform of the I2C Write/Read operation, with the following details:

• When <start_cnt> is incremented and reaches <start_cnt == 2>, <i2c_cnt> begins to increase. When <i2c_cnt == 4>, <i2c_rdwr = 0> (Write) and <iic_wdata = 8′hff> are input.
• When <i2c_cnt == 7>, <iic_req> becomes 1, indicating that the I2C Write operation is being requested.

Figure 6 presents the second waveform of the Write/Read operation, with the following details:

• When <iic_done == 1>, it indicates that the master’s Write operation to the slave has been successfully completed.
• As <i2c_cnt> is incremented again and reaches <i2c_cnt == 4>, <iic_rdwr = 1> (Read) is input.
• When <i2c_cnt == 7>, <iic_req> becomes 1, signaling that the I2C Read operation is being requested.

Figure 7 displays the third waveform of the Write/Read operation, highlighting the following aspects:

• When <iic_done == 1> appears for the second time, it indicates that the slave has transmitted the requested Read data to the master, and the master has successfully received and stored the Read data sent by the slave.
• Simultaneously, at the second occurrence of <iic_done == 1>, the values of <iic_wdata> and <iic_rdata> match at <16′hff>, confirming that the designed I2C module has correctly executed both Write and Read operations.

Figure 8 presents the complete waveform of the SCL and SDA signals for the I2C Write operation, while Figure 9 shows the complete waveform of the SCL and SDA signals for the I2C Read operation.

4. ABV Testbench Using I2C SVA

Section 4 explores the ABV testbench using SVA for verifying the I2C module designed in Section 3.

4.1. SVA Introduction

SVA is a language construct that allows defining constraints, checkers, and cover points for a designed hardware module [7]. It serves as a syntax for describing design specification rules in SystemVerilog format, which can be understood by simulation tools such as Xcelium 23.09 (Cadence Design Systems, San Jose, CA, USA) or VCS 23.03 (Synopsys Inc., Mountain View, CA, USA). Additionally, it functions as an embedded checker, which can be implemented within RTL code or inside a testbench. In verification, SVA is used to determine whether specific conditions or events required for the correct operation of RTL occur during simulation. SVA can notify the user using error or warning messages if certain conditions are not met or if a specified sequence does not complete successfully during simulation [7].

SVA consists of two types: Immediate assertions, which are combinational and check conditions at a single point in time, and concurrent assertions, which evaluate sequential conditions over time. Immediate assertions do not support sequences that involve time progression, as they operate only at a specific point in time. This limitation restricts their usage in some scenarios. In contrast, concurrent assertions synchronize with the clock and allow the definition of sequences that evolve over time, making them suitable for testing various conditions in a design.

In this paper, concurrent assertions are used to verify the key operations of the I2C protocol to ensure correct functionality.

4.2. ABV Introduction

ABV verification methodology utilizes SVA, which provides a structured and formalized approach to verifying the characteristics of a design. ABV is particularly advantageous for monitoring and checking interfaces, functionalities, and protocols. Additionally, ABV can be applied in other verification methodologies such as dynamic simulation, functional coverage, and static verification. However, when using SVA, certain considerations must be taken into account. SVA requires a testbench and stimulus vectors, and the generation of effective stimulus vectors along with proper utilization of SVA can help reduce unnecessary simulation overhead.

4.3. I2C ABV Testbench Architecture

Figure 10 illustrates the proposed I2C ABV testbench architecture. The components and their roles are as follows:

• [i2c_tb_top.sv]:
  The top-level testbench file, responsible for instantiating the DUT and importing the ABV infrastructure through [i2c_sva_bind.sv].
• [i2c_sva_bind.sv] (Figure 11):
  The central integration file that includes packages and modules required for property definition, evaluation, and binding.
• [i2c_sva_pkg.sv, i2c_sva_property_pkg.sv] (Figure 12):
  Contains all reusable SVA property templates for I2C protocol verification. These properties are written once and instantiated in downstream modules.
• [import i2c_sva_pkg::*]:
  Imports all named properties from the package, enabling modularity and avoiding repetitive code.
• [i2c_sva_check.sv] (Figure 13):
  Acts as a reusable assertion module that receives DUT signal names as parameters and maps them to corresponding assertion properties.

Compared to traditional UVM-based environments, which require layered drivers, monitors, and sequencers, this architecture leverages a simplified and direct method to attach assertion logic. It is lightweight, reusable, and easy to integrate, particularly for protocol-level verification tasks. Moreover, this architecture is not merely a wrapper for SVA but a structured testbench framework that supports modular property definition, interface-based abstraction, and bind-driven integration. These elements together enable a non-intrusive, protocol-adaptable, and simulation-friendly environment. By separating assertion logic from the DUT and encapsulating it in reusable modules, the framework enhances both maintainability and portability, which would be challenging to achieve with raw SVA usage alone.

• [i2c_sva_check_with_design.sv] (Figure 14):
  Connects the reusable assertion module to the actual DUT via signal mapping and bind, allowing non-intrusive verification without modifying RTL.

4.4. Assertion Reusability and Generalization Techniques

Recently, Assertion-Based Verification (ABV) using SVA has gained increasing attention in both academia and industry due to its modularity and compatibility with both simulation and formal verification environments. Banga et al. [12] proposed a method to encapsulate assertions in protocol-agnostic wrappers, improving portability and reusability across multiple IPs. Gupta and Saini [13] further demonstrated that SVA can effectively support formal verification of on-chip communication protocols, confirming the applicability of ABV to protocol-level correctness checking in both simulation and formal workflows.

To enhance the portability and reusability of assertion code in I2C verification environments, this section presents techniques that eliminate hard-coded signal dependencies and promote modular verification architecture. These generalization techniques are not only proposed as abstract concepts but are also fully applied to the I2C ABV testbench architecture described in Section 4.3.

While SystemVerilog Assertions (SVA) provide a concise and expressive way to capture protocol behavior, traditional implementations tend to use direct signal references (e.g., i2c_scl, i2c_sda), which limits reuse across different module interfaces. In contrast, the architecture and assertion code shown in this work incorporate structural generalization strategies including parameterization, interface-based encapsulation, and macro usage.

The following subsections demonstrate these approaches:

• Parameterization of Properties (Figure 15):
  Assertions can be encapsulated within parameterized modules that accept signal bindings as arguments. This enables a single assertion module to support multiple DUTs with varying signal names.
• Interface-Based Encapsulation (Figure 16):
  Signal groups are wrapped in SystemVerilog interface blocks, and assertion modules access signals through interface handles. This improves modularity and reduces dependency on signal naming.
• Macro-Based Reusability (Figure 17):
  SystemVerilog macros (define) allow assertion patterns to be reused inline. This is helpful for repeating standard protocol rules across modules.

These generalization mechanisms are fully reflected in both the assertion code and the overall testbench structure. As detailed in Section 4.3, the testbench was designed using modular packages (i2c_sva_pkg.sv), generic assertion modules (i2c_sva_check.sv), and bind integration (i2c_sva_check_with_design.sv) to ensure reusability and abstraction. By adopting this reusable architecture, the same assertion infrastructure can be efficiently applied to I2C or adapted to other serial protocols (e.g., SPI, UART) with minimal change. These techniques significantly improve the modularity and maintainability of the verification environment.

4.5. Comparison Between ABV and UVM-Based Verification

While both Assertion-Based Verification (ABV) using SystemVerilog Assertions (SVA) and Universal Verification Methodology (UVM) using object-oriented SystemVerilog (SV OOP) provide robust methods for functional verification, each has its strengths and is suitable for different project scales and verification objectives.

• Learning Curve: ABV using SVA requires less initial learning since it avoids class-based design and UVM-specific methodology. This makes it more accessible to verification engineers who are new to SystemVerilog or those working under tight schedules. UVM, by contrast, requires a solid understanding of class hierarchies and the UVM library structure.
• Code Complexity: ABV environments are typically simpler and more direct. Assertions can be embedded directly into the design or bind files. UVM testbenches, while structured and modular, often involve layered components such as sequences, drivers, monitors, agents, and environments, which can increase overhead and setup time.
• Reusability and Scalability: UVM excels in reusability, especially for large-scale SoC verification, due to its modularity and configurability. ABV, although less modular, is highly reusable within protocol-focused or block-level designs.
• Debugging and Traceability: ABV allows fine-grained, time-accurate checks with immediate pass/fail feedback at the signal level. UVM provides transaction-level tracing and sophisticated debug utilities such as scoreboards and functional coverage metrics.
• Simulation Speed and Resource Usage: ABV tends to produce faster simulations, especially in focused, low-level module testing, because of its lightweight nature. UVM’s layered structure may introduce more runtime overhead.

This study adopts ABV with SVA to emphasize lightweight, protocol-specific verification for I2C functionality, while acknowledging that UVM remains indispensable for full-system level and coverage-driven verification environments.

Figure 18 illustrates a typical I2C UVM VIP testbench architecture, which consists of multiple layered components required for UVM-based functional verification. To perform a simple test, the following UVM components must be instantiated and properly connected: uvm_test, uvm_env, uvm_agent, uvm_driver, uvm_sequencer, uvm_monitor, scoreboard, and coverage collectors. In addition, user-defined uvm_sequence classes are needed to generate transactions, and proper use of uvm_objection is required to control simulation flow and synchronization.

Communication between the UVM components and the DUT also requires an explicitly defined SystemVerilog interface, which must be properly bound to both the DUT and verification components.

The main strength of UVM lies in its modularity, configurability, and high reusability, especially for large-scale SoC verification projects. Its layered architecture supports transaction-level modeling, functional coverage collection, and advanced checking strategies through scoreboards and reference models.

However, for protocol-level or block-level verification tasks such as I2C functional checks, the overhead introduced by UVM’s infrastructure can be significant. Designing, configuring, and connecting all required components introduces additional complexity, increases testbench code size, and slows down initial development and simulation runtime. Simple tasks such as checking a START or STOP condition may require significant setup effort compared to an assertion-based testbench.

In contrast, the proposed ABV testbench architecture allows direct attachment of assertion logic with fewer components, reducing setup time while maintaining signal-level accuracy. This makes ABV more suitable for lightweight or focused verification scenarios.

Table 2. Comparison of ABV vs. UVM verification performance.

Metric	ABV(SVA)	UVM
Simulation Time (ms)	120	280
Testbench Code Size (lines)	350	3500
Assertion Coverage (%)	85%	92%
Setup Complexity (1–5)	2 (Simple)	4 (Complex)
Average Debug Time (s)	30 s	75 s

provides a quantitative comparison of simulation efficiency, code size, coverage, and debug complexity between ABV and UVM-based verification environments. It illustrates that ABV achieves faster simulation time and requires fewer lines of testbench code due to its minimalistic structure without layered components. While UVM provides slightly higher assertion coverage through its rich feature set and reusability, it comes with increased setup complexity and longer debug time due to the layered architecture and object-oriented infrastructure.

In summary, ABV with SVA provides a lightweight and fast alternative suitable for targeted or block-level verification, while UVM remains the preferred framework for comprehensive, reusable, and large-scale verification. The choice depends on the specific project requirements and resource constraints.

5. Simulation Results

Table 3. I2C key features.

No.	I2C Check Item
1	SCL Frequency Check
2	START Condition Check
3	STOP Condition Check
4	SCL Count Check
5	DEVICE ACK SDA Check
6	Slave Address ACK SDA Check
7	WData ACK and RData NACK SDA Check
8	Command (Write/Read) SDA Check

presents the key operations of the I2C protocol. The same input values used in the RTL simulation are applied to the I2C ABV. Figure 19 shows the code summarizing the parameters used in ABV.

5.1. SCL Frequency Check

The i2c_scl_period_check_formal property verifies whether the i2c_scl signal generated by the I2C master maintains the target frequency of 400 kHz (corresponding to a 2500 ns period). This assertion is evaluated synchronously with a 25 MHz reference clock (clk_25f, 40 ns period) and uses sequence-based delay notation to detect the time interval between two rising edges of i2c_scl. Instead of relying on the $realtime system function, the property checks whether the second rising edge occurs within 60 to 65 cycles after the first. This corresponds to a tolerance window of 2400 ns to 2600 ns, allowing minor deviations due to clock jitter or hardware implementation variations. The assertion is suitable for both simulation and formal verification environments, ensuring that the SCL signal satisfies the frequency requirement for reliable I2C communication.

Figure 20 presents the assertion code, and Figure 21 shows the waveform results based on its evaluation. Figure 22 illustrates both the PASS and FAIL scenarios for the I2C SCL frequency assertion. The timing diagram shows how the period of the i2c_scl signal is validated against the target frequency specification of 2500 ns ± 100 ns, corresponding to 60 to 65 cycles of the 25 MHz reference clock (clk_25f).

In the PASS case, the rising edge of i2c_scl occurs within the valid range—specifically between 60 and 65 clk_25f cycles after the previous rising edge—ensuring compliance with the expected I2C clock period. In contrast, the FAIL scenarios demonstrate violations where the i2c_scl rising edge occurs either too early (before 60 cycles) or too late (after 65 cycles), which results in an assertion failure. This assertion is compatible with both simulation and formal verification, allowing detection of timing deviations in the I2C clock signal.

5.2. START Condition Check

The start_cond_chk property verifies the detection of a valid START condition as defined by the I2C protocol. A START condition occurs when the SDA line transitions from HIGH to LOW while the SCL line remains HIGH. This assertion is evaluated synchronously with the 400 kHz reference clock (i2c_ref_clk) and triggers on the falling edge of SDA, at which point it checks whether SCL is HIGH. By observing the protocol-defined transition directly from the bus signals—without the need for additional control triggers—the assertion ensures autonomous and accurate validation of the START condition. This mechanism guarantees that I2C communication begins properly, conforming to the protocol’s timing requirements.

Figure 23 presents the assertion code that performs this check, and Figure 24 illustrates the corresponding simulation waveform results that validate its operation. Figure 25 illustrates the verification of the I2C START condition using an assertion. According to the I2C specification, a START condition is defined as a falling edge on the SDA line while the SCL line is held HIGH. The assertion uses an overlapping implication (|->) to ensure that the SCL signal is HIGH at the same clock cycle when SDA transitions from HIGH to LOW.

In the PASS scenario, the SDA falling edge occurs while SCL is HIGH, satisfying the condition. In the FAIL case, either the SCL is LOW during the SDA falling edge or the SCL becomes HIGH in a subsequent cycle, both of which violate the I2C START condition.

5.3. Write and Read STOP Condition Check

The properties w_stop_cond_chk and r_stop_cond_chk verify the correct detection of the I2C STOP condition at the end of Write and Read operations, respectively. For Write operations, the assertion is triggered by a START condition (a falling edge on SDA while SCL is HIGH), and monitors exactly WRITE_CYC rising edges on SCL. It then checks whether the STOP condition is met—defined as a rising edge on SDA while SCL remains HIGH. For Read operations, the assertion similarly starts with a START condition and counts READ_CYC rising edges on SCL. Since the master typically issues a NACK by holding SDA HIGH at the end of a Read, the STOP condition is confirmed by observing that both SDA and SCL are HIGH (without requiring a rising edge on SDA). These assertions ensure protocol-compliant termination behavior for I2C transactions under both Write and Read operations.

Figure 26 presents the assertion statements implementing this logic, and Figure 27 shows the corresponding simulation waveform results validating their correctness. Figure 28 illustrates a PASS scenario of the I2C STOP condition after WRITE and READ transactions. Following the detection of a START condition, the expected number of SCL rising edges (WRITE_CYC for Write, READ_CYC for Read) are observed. Then, if a STOP condition—defined as SDA rising while SCL is HIGH—occurs within the allowed slack cycles, the assertion passes. Figure 29 shows a FAIL scenario where SDA rises within the valid slack window, but the STOP condition is not met because SCL remains LOW. Figure 30 presents the opposite FAIL case to Figure 29, where SCL meets the expected condition (HIGH), but the assertion fails due to SDA remaining LOW.

5.4. SCL Clock Count Verification for Write and Read Operations

These assertions verify that a specific number of SCL rising edges are observed after the I2C START condition. The total count must fall within a valid range, defined as WRITE_CYC (or READ_CYC) plus a slack range of 0 to 3 cycles. This slack accounts for the STOP condition window, which allows the STOP condition to occur within up to 3 cycles after the expected data transmission. If the number of SCL edges falls outside this range, the assertion fails, indicating a protocol timing violation.

Figure 31 presents the assertion statement that verifies whether the number of SCL clock events during I2C Write and Read operations matches the expected count. Figure 32 illustrates the corresponding waveform results that validate the assertion behavior shown in Figure 31. Figure 33 illustrates two representative cases for the SCL count assertion: one satisfying the expected number of SCL rising edges within the allowed slack range (PASS), and the other either falling short of or exceeding the defined upper bound (FAIL). These scenarios validate the assertion’s effectiveness in verifying the correct timing of I2C transactions following a START condition.

5.5. Device Acknowledgment Check via SDA in Write and Read Operations

The w_device_ack_sda_cond_chk property verifies that, during a Write operation, the device under test correctly acknowledges the Device ID phase. This phase includes the 7-bit Device ID followed by a 1-bit Write indicator. After exactly DEVICE_CMD_FLOW_LEN SCL clock cycles, the assertion checks whether the device pulls the SDA line low to indicate a valid ACK response.

The r_device_ack_sda_cond_chk property validates two ACK responses during a Read operation. The first ACK occurs after the initial Device ID phase with the Write bit, used to configure the internal register address. The second ACK is expected after a repeated START condition, where the Device ID is retransmitted with the Read bit. These properties ensure that the Device ID is properly acknowledged in both Write and Read sequences, maintaining protocol compliance.

Figure 34 presents the assertion statement that checks for correct ACK responses following Device ID transmissions in Write and Read phases. Figure 35 illustrates the corresponding simulation waveforms demonstrating this behavior. The assertion W_DEVICE_ACK_SDA_COND_C can be classified into four cases. Among these, this paper illustrates only the representative PASS and FAIL scenarios in Figure 36.

• PASS (Case 1): After the START condition, the signal i2c_scl == 1 is observed exactly DEVICE_CMD_FLOW_LEN times, followed by i2c_sda == 0, indicating a valid ACK response.
• FAIL (Case 2): After the required number of SCL HIGH pulses, i2c_sda remains HIGH (1), indicating no ACK response.

Other scenarios are described in text only without visual illustration:

• FAIL (Case 3): The number of SCL HIGH pulses is either less than or greater than the expected DEVICE_CMD_FLOW_LEN, failing the ACK timing requirement.
• FAIL (Case 4): Although i2c_sda transitions LOW, the SCL count does not align with the specified condition, making the ACK invalid.

The assertion R_DEVICE_ACK_SDA_COND_C can be classified into five cases. Among these, this paper illustrates only the representative PASS (Case 1), FAIL (Case 2), and FAIL (Case 3) scenarios in Figure 37. The remaining cases—FAIL (Case 4) and FAIL (Case 5)—are described textually without visual illustration. They reflect edge scenarios involving unexpected behavior in ACK positioning or occurrence.

• PASS (Case 1): Both the first and second ACKs occur correctly at the expected timing after their respective SCL pulse sequences.
• FAIL (Case 2): The first ACK occurs correctly, but the second ACK does not occur.
• FAIL (Case 3): The first ACK does not occur after the initial SCL pulses. As a result, the assertion fails immediately and the second ACK is not evaluated. In this case, since the first ACK response is missing, the second ACK condition is not checked at all.
• FAIL (Case 4): The first ACK occurs, but the second ACK is either too early or too late, violating the expected timing window.
• FAIL (Case 5): Neither the first nor the second ACK occurs.

5.6. Slave Address ACK Check for Write and Read Operations

The slv_addr_ack_sda_cond_chk property verifies that, after the slave address phase in both Write and Read operations, the device correctly acknowledges by pulling the SDA line low. Triggered by the START condition, the assertion counts DEVICE_CMD_FLOW_LEN + ADDR_CMD_FLOW_LEN SCL rising edges, covering the initial Device ID phase and the slave address transmission. It then checks for an ACK by confirming that SDA is driven low on the next cycle. This assertion ensures that the transmitted slave address has been properly received and acknowledged before proceeding with internal register access or data transfer. Figure 38 shows the assertion code for detecting slave address acknowledgment, and Figure 39 illustrates the waveform behavior of this check. The assertion SLV_ADDR_ACK_SDA_COND_C can be classified into four cases. Among these, the representative PASS (Case 1) and FAIL (Case 2) scenarios are illustrated in Figure 40.

• Case 1 (PASS): After the START condition, exactly DEVICE_CMD_FLOW_LEN + ADDR_CMD_FLOW_LEN SCL HIGH pulses occur, and immediately after that, an ACK response (i2c_sda == 0) is correctly detected.
• Case 2 (FAIL): While the SCL HIGH pulse count is correct, the ACK response does not occur (i2c_sda remains HIGH), leading to a failure.

The remaining Case 3 and Case 4 represent situations where either the number of SCL HIGH pulses is less than or greater than expected, or an ACK (i2c_sda == 0) does occur but not at the expected timing. These cases do not satisfy the assertion’s condition and are also evaluated as FAIL, but they are only described in text in this paper without visual illustrations.

5.7. Data ACK/NACK Phase Verification in Write and Read Operations

The properties w_data_ack_sda_cond_chk and r_data_ack_sda_cond_chk verify the ACK/NACK behavior following the data transmission phase in I2C Write and Read operations, respectively. For Write operations, the assertion is triggered by the START condition and monitors WRITE_CYC SCL clock pulses. It checks that the slave device pulls the SDA line low after the last data bit to indicate a valid ACK response. For Read operations, the assertion similarly counts READ_CYC SCL pulses and confirms that the master issues a NACK by keeping SDA high after the final data bit.

These assertions ensure protocol-compliant signaling of data phase completion in both directions of communication. Figure 41 shows the assertion code, and Figure 42 illustrates simulation waveforms demonstrating correct ACK/NACK behavior. The assertion W_DATA_ACK_SDA_COND_C can be classified into four outcome cases. Among these, the representative PASS (Case 1) and FAIL (Case 2) scenarios are illustrated in Figure 43.

• Case 1 represents the situation where, after the START condition, SDA initially falls, SCL stays HIGH exactly WRITE_CYC times, and SDA goes LOW again immediately after—indicating a proper ACK response.
• Case 2 occurs when the number of SCL HIGH pulses is correct, but SDA does not go LOW, meaning no ACK was issued.

The remaining FAIL cases (Case 3 and Case 4) are as follows:

• Case 3: Although SDA falls, the number of SCL HIGH pulses is either less than or greater than WRITE_CYC, violating the expected ACK timing.
• Case 4: While the SCL HIGH count is correct, the LOW transition of SDA happens too early or too late, making it fail to meet the ACK positioning condition.

Cases 3 and 4 are only described in the text and are not illustrated in the figure. The assertion R_DATA_ACK_SDA_COND_C can also be categorized into four cases. Among these, PASS (Case 1) and FAIL (Case 2) scenarios are illustrated in Figure 44.

• Case 1 occurs when, after the START condition, SDA initially falls, SCL is HIGH exactly READ_CYC times, and then SDA remains HIGH—indicating a correct NACK response from the master.
• Case 2 happens when the number of SCL HIGH pulses is correct, but SDA goes LOW instead of staying HIGH, resulting in an invalid ACK.

The remaining FAIL cases (Case 3 and Case 4) are:

• Case 3: SDA falls, but the number of SCL HIGH pulses is not equal to READ_CYC, making ACK/NACK determination unreliable.
• Case 4: SDA stays HIGH, but the timing of the response is too early or too late to satisfy the NACK positioning requirement.

Cases 3 and 4 are described in text only and not illustrated in the figure.

5.8. Command Phase SDA Status Verification in Write and Read Operations

The w_cmd_sda_cond_chk and r_cmd_sda_cond_chk properties validate the correctness of the command direction bits during I2C transactions. In Write operations, the assertion ensures that the command bit transmitted after DEVICE_CMD_FLOW_LEN-1 clock cycles is ‘0’, indicating a Write operation. In Read operations, the assertion checks two phases:

• First, after DEVICE_CMD_FLOW_LEN-1 clock cycles (Write phase), SDA must be ‘0’.
• Then, after ADDR_CMD_FLOW_LEN + SR_LEN + DEVICE_CMD_FLOW_LEN-1 clock cycles (Read phase), SDA must be ‘1’ to indicate a Read operation.

These checks ensure that the master issues the correct command direction bits during both Write and Read access phases. Figure 45 shows the assertion structure, and Figure 46 presents waveform results demonstrating this protocol behavior. The W_CMD_SDA_COND_C assertion can be categorized into four evaluation cases. This paper illustrates Case 1 (PASS), where SDA is LOW at the expected command bit position, and Case 2 (FAIL), where SDA remains HIGH, failing to acknowledge. These are shown in Figure 47. The remaining Cases 3 and 4 include scenarios where SDA is LOW but the SCL pulse count does not match the expected position, or where SDA falls early or late compared to the expected timing. These are also evaluated as FAIL and are discussed in text only. The R_CMD_SDA_COND_C assertion also consists of four possible evaluation cases. This paper illustrates Case 1 (PASS), where SDA is LOW at the Write-phase command bit and HIGH at the Read-phase command bit, and Case 2 (FAIL), where SDA remains LOW during the Read-phase bit. These scenarios are presented in Figure 48. The remaining Cases 3 and 4 represent situations with correct SDA values but incorrect timing or SCL pulse counts, and are described in text only.

6. Conclusions

In this study, we introduced a practical methodology for building an Assertion-Based Verification (ABV) testbench using SystemVerilog Assertions (SVA) for I2C module validation. Despite its formal nature, the ABV methodology remains intuitive, allowing engineers to detect RTL-level functional bugs rapidly and effectively without requiring in-depth knowledge of Object-Oriented Programming or UVM concepts. This lightweight approach leads to reduced setup overhead and faster turnaround time during early verification phases.

Our results show that SVA-based ABV is particularly effective for verifying synchronous communication protocols such as I2C, ensuring behavioral correctness through time-accurate, clock-based concurrent assertions. In addition, the testbench structure’s modularity, enabled by package encapsulation, parameterization, and bind mechanisms, facilitates easy reuse and adaptation to similar protocol environments.

While the ABV methodology excels in focused, protocol-level testing, we acknowledge its limitations in randomized scenario generation and large-scale reuse. Thus, we envision future integration of ABV with UVM environments to combine the protocol awareness of assertions with the configurability and automation of UVM. Such a hybrid verification flow will be essential for achieving scalable, reusable, and comprehensive design verification across different abstraction levels.