VERIFICATION OF I2C INTERFACE

1. VERIFICATION OF I2C INTERFACE • By • H. Mugil Vannan • Experts • Mr. Rahul Hakhoo, Section Manager, CMG-MCD • Mr. Umesh Srivastva, Project Leader USING SPECMAN ELITE

2. Verification Overview • Dynamic checking • Verification during simulation • run • Checks for protocol adherence • Not 100% coverage • Time consuming for large design • But necessary for generating • initial reference design for • equivalence checking • Static checking • Equivalence checking • Compare implementation • design against reference • design • Set compare points • 100% coverage • Reduction in verification • time • Example: FORMALITY • But, how to get the golden • reference design

3. Dynamic Verification-what Tools? • Vhdl test benches • Verification of small designs, obsolete • Assembly language patterns • Patterns loaded thro’ Serial Test Controller (JTAG pins) • Separate patterns to test different functionalities • Increase in test writing time • Specman Elite • Automated stimuli generation • Robust verificaion suites in short time

4. Specman Elite: Principles of Verification • Create tests that stimulate the DUT (Device Under Test) • Checking that DUT output corresponds to the input stimuli, according to the DUT Specifications • Analyzing test coverage to find areas that need more testing • Advantages • “Specification based approach” – Simpler test writing based on the knowledge of DUT specs alone • Lesser possibility that specs are incorrectly translated into checks • Better control of the test environment, ‘Specs level’ rather than ‘HDL level’

5. Specification Based Approach

6. I2C (Inter Integrated Circuit) Bus • Simple two wire bi-directional bus, for serial data transfer • Two lines- SCL and SDA for clock and data • Data transfer according to I2C protocol • No limitation on the number of devices that can be connected to the bus • The I2C protocol allows Multi-Master Slave functions • Devices using I2C bus must have an On-Chip I2C interface • The devices are connected to the I2C bus by means of a wire-AND connection

7. Wire-AND Connection

8. I2C Interface • Interface between micro controller and the serial I2C bus • Parallel bus  I2C protocol converter • I2C interface is software addressable • Each interface connected to the I2C bus has a unique software address assigned by the CPU • Supports two frequency operation modes, Normal (0-100 KHz), Fast (100-400 KHz) • Supports Multi-master slave functions • Can be configured in any of the four modes ( Master Tx, Master Rx, Slave Tx, Slave Rx)

9. I2C Interface Block Diagram

10. I2C Protocol • Data transfer is defined in phases. • START phase - Master generates a START condition, a high to low transition on SDA while SCL is high • Slave Addressing Phase – Master transmits the 7-bit slave address followed by the READ/WRITE bit • Data bit on SDA should remain stable during SCL high period • Data Transfer Phase – Depending on R/W bit, Master transmits or receives data from Slave • Stop Phase –Generated by Master to terminate communication, a low to high on SDA while SCL is high

11. I2C Protocol Contd. • START and STOP Condition • A Complete Data Transfer

12. Multi Master / Slave Attributes • Multi master /slave case – I2C interfaces are wire-ANDED • ‘Arbitration’ on SDA between master interfaces to decide the control of the I2C bus • Arbitration achieved by wire-ANDing, the first master to produce a ‘1’ on its data line loses arbitration • ‘Clock Synchronization’ on SCL to synchronize the different master clock frequencies to produce a single clock • Wire-ANDing of SCL also facilitates stretching of clock after the ACK pulse by Slave device

13. I2C Data Transfer Specifications

14. Specifications Contd.

15. I2C Test Configuration • I2C interface is verified in two test configurations • E-Interrupt Controller Model • E-I2C Driver model • Verified in all four Master / Slave modes • Frequency of operation – Normal, Fast • 7-bit and General Call Addressing Modes • Multi Master attributes – Arbitration, Clock Synchronization • Checks for error cases like misplaced Start or Stop • Verified at RTL and Gate Netlist level with back annotated delay information • Data checker module – to check integrity of data transmitted and received

16. E-Interrupt Controller Model

17. Interrupt Controller Attributes • Based on the ST7 I2C data transfer specifications • Imitates the behavior of the ST7 core with the I2C interface • The E-CPU sets up the device in any of the four operation modes and waits for interrupts to occur and services those interrupts • Recognizes normal interrupts and exceptions raised by the interface • The E-Interrupt Controller uses only port level signals to interact with the interface • Hence it is portable from RTL to Gate Netlist level • Incorporates Data Checker Module

18. E-I2C Driver Model

19. E-I2C Driver Attributes • E-I2C Driver is an e-module that behaves like the I2C interface • It is wire-ANDed with the real Interface ( RTL/Netlist) that is to be verified • E-I2C Driver can directly control the SDAOUT and SCLOUT lines • Can test slave features like clock stretching after acknowledge pulse • Bus errors like ‘misplaced START/STOP’ can be generated • Also portable from RTL to Netlist verification with back-annotated delay information (SDF file) • Incorporates Data Checker Module

20. Back Annotation, How It Is Done? • Process of using delay info in gate level simulation • Forms a feed back from BE to FE • SDF-Standard Delay Format • Contains cell interconnect delays extracted from layout • SDF file is netlist specific • Delay info added only during design elaboration step

21. Waveforms-Multi Master, ARLO Case

22. Bus Error, Misplaced Stop

23. Multi Master Slave, General Call