Home

I C Verification Suite - Repositório Aberto da Universidade do Porto

1. FSM State Pc Bus State Next Valid State S IDLE SDA 1 SCL 1 START COND START COND SDA 0 SCL 1 S_LOW S_LOW SDA 0 SCL 0 S_Z_ON S_HIGH S_ON_Z S_ACK SDA 0 SCL 1 S_LOW S_ON_Z S_ON_Z SDA 1 SCL 0 S_LOW S_HIGH S_LOW_C S_HIGH SDA 1 SCL 1 S LOW S Z ON S LOW C SDA 0 SCL 0 S ON Z S Z ON S HIGH S Z ON SDA 0 SCL 1 S LOW STOP COND S ON Z STOP COND SDA 1 SCL 1 START COND END n d S IDLE Table 4 2 States and next valid states of the Verify Specs FSM After the Verify Specs FSM being configured this task is ready to start monitoring the C bus It starts in the S DLE state waiting for a transition on the bus At this state the only transition valid is the transition from 1 to 0 of the SDA line Otherwise it is an invalid transition and the FSM switch to the END state to stops the current verification process When the SDA line is pulled down means that some device start performing a START condi tion At this point the FSM saves the current simulation time transits to START COND state and waits that the device ends the START condition by pulling down the SCL line When the SCL line is pulled down a START condition has just occur and the Verify Specs FSM verify the hold time of the START condition calculating the time gap between the transition from 1 to 0 of the SDA signal with the transition from 1 to 0 of the SCL signal Then compares the calculated time gap with the time defined in the specific
2. THD DAT minimal time FAIL with 0 00us TSU DAT with 5 00us TLOW with 5 00us T HIGH with 5 00us F SCL with 100 000000 kHz THD DAT minimal time FAIL with 0 00us F SCL with 100 000000 kHz TLOW with 5 00us T HIGH with 5 00us F SCL with 100 000000 kHz TLOW with 5 00us Final Verification Report detailed version OK OK OK OK OK OK OK OK OK OK OK FAIL 373 00us 343 343 348 353 353 358 363 363 368 373 373 00us T HIGH with 5 00us 00us F SCL with 100 000000 kHz 00us TLOW with 5 00us 00us T HIGH with 5 00us 00us F SCL with 100 000000 kHz 00us TLOW with 5 00us 00us T HIGH with 5 00us 00us F SCL with 100 000000 kHz 00us T LOW with 5 00us 00us T HIGH with 5 00us 00us F SCL with 100 000000 kHz OK 378 00us T SU DAT with 5 00us OK 378 00us T LOW with 5 00us OK 383 00us T HIGH with 5 00us OK 383 00us F SCL with 100 000000 kHz OK 388 00us TLOW with 5 00us FAIL 393 00us OK 393 00us T HIGH with 5 00us OK 393 00us F SCL with 100 000000 kHz OK 398 00us T LOW with 5 00us OK 402 00us T SU STO with 4 00us OK 388 00us Data Received match the data transmitted I2C Data transfer T HD DAT minimal time FAIL with 0 00us T HD DAT minimal time FAIL with 0 00us 101 10000001 skok KOK KK KKK RK okokokookokokokokookokokookokokokok KKK
3. skok KKK KKK okookokokok okokokookokokokokookokokookokokokok E E DR E E E k RR k kk kk k k k K k Kk kk RK k Kk Kk k Kk Kk k k k K k K k K K K K K kokokokokok ok K K K K k K k K K K K K K KK KKK K K K kokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokok K SRR ROKK KK KK K KK okokokokokokokokokokokokokokok WRITE MODE FK 2K 2 K KK K KK FK KK FK FKK FK FKK FK FKK FK FKK FK K K K K K K k kokokokokokokokokokokokokokokoko K K K K K RR KK K K K K K kokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokok K 3K KKK KKK KKK OK OR KOK EE EEE EEE EE E KK RR E K E K k k k k k k k KKK k k k Kk kkk kk Kk k kk K k K k K K k K k KK KKK OK KK EE EEE KKK KOK KK RR DR DRE RE KK RK E K E K E K k k k k K KKK kk k Kk Kk k kk Kk k kk Kk K k K K k K k E k OH OH KK KK k k Kk KK k KK K K K K FG KKK Kk KK k K k K K K Kk KK k KK K K kokokokokokokokokokokokokokokokokokokokokokokoko ko Communication nr DOES SE SE SE OH E k k k k k k kk Kk k k k K k K K K Kk K FRC K K k Kk k k k Kk K Kk KK K K k K FG KK KK KK k K k K K K Kk K Kk KK k K skok okokokokokookokokookookokokok okokokookokokokokookokokookokokokok E E DR E KKK E K k k k k k k k k K k k k kk kk k Kk Kk k Kk Kk k k k K k K k K K K K K FAK CR GI E EEEE EE SE EE E EE E E AR E E E AK k K K k k kkk k k Kk k kk k KK kkk K K K Kk K K K KK 2k KOK k k k k k ok k k k k kkk kkk 1 Transfer Byte nr l K K ok ke K KK KK K KK K KK OK KK K K ROK KK EEEIEE EEE EEEE EEEE oko sek KK KKK RR E E E E E K k k kK k
4. 3 SDA signal 3 1 Data hold time 3 1 1 Minimal time 3 1 2 Maximum time 3 2 Data set up time 3 3 Data valid time 4 Address Data integrity 4 1 Invalid slave address 4 2 Data from master to slave 4 3 Data from slave to master 5 Invalid transfer 5 1 Illegal format 5 2 Invalid ACK NACK 5 3 Invalid State 3 2 Communication Status Messages 37 3 2 Communication Status Messages 3 2 1 Hold time specification for START and repeated START condition The hold time specification for START and repeated START is defined as the time elapsing from the falling edge of the SDA signal to the falling edge of the SCL signal section 2 1 Fig ure 3 1 represents how the hold time for START and repeated START specification are measured After this period the master device start generating the SCL pulses Table 3 1 has the specification time for the hold time of START and repeated START conditions for Standard Sm Fast Fm Fast plus Fm and High speed Hs mode bus speed mode In High Speed mode the normal START condition does not exists The value in table 3 1 is the specification time for the repeated START hold time only Figure 3 1 START condition 1 Sm Fm Fm Hs mode Symbol Parameter Min Max Min Max Min Max Min Max Du Hold time re T HD STA peated START 4 0 0 6 0 26 0 16 us condition Table 3 1 Hold time specifications for START and repeated START condi
5. C bus communication protocol being in constant improvement all devices sup port previous versions of this communication standard 1 Fast mode Fm In this mode the devices are able to transfer data up to 400 kbit s The minimum reguirement 1s that they has to synchronize at this speed However after that they can reduce the speed transfer prolonging the LOW period of the SCL signal The protocol communication for this speed mode is exactly the same as in the Standard mode C bus specification as well as the transfer format the logic levels and the maximum capacitance load for both SDA and SCL lines All devices capable to communicate in Fast mode speed are also capable to performing trans fers at Standard mode These devices are also compatible with devices that only can communicate in Standard mode However Standard mode devices can not communicate in a O to 400 kbit s PC bus system and thus should not be integrated in a Fast mode C bus system 2 Fast mode Plus Fm Devices operating in Fast mode Plus are able to transfer data at higher bit rate 1 Mbit s The total bus capacitance are also higher than in the Standard and Fast modes These devices remain fully compatible with Fast and standard modes for bidirectional communication in a mixed speed bus system In this speed mode the protocol communication is the same as in the Standard and Fast mode C bus specification as well as the transfer format and the logic l
6. Table 3 4 STOP condition time specifications 3 2 5 Bus free time The bus free time is defined as the time between a STOP and a START condition whenever the bus is free This two conditions can only occur spaced by a minimum time called bus free time This specification is defined as the elapsed time between raising edge of the SDA line when performing the STOP condition and the falling edge of the same line when performing the START condition as shown in figure 3 6 The minimum time for this specification for all bus speed modes are described in table 3 5 SDA Figure 3 6 Bus free time between a STOP and a START 1 Sm Fm Fm Hs mode Symbol Parameter Min Max Min Max Min Max Min Max Unt Bus free time between a T BUF STOP and a START condi 4 7 1 3 0 5 us tion Table 3 5 STOP condition time specifications 3 3 SCL signal 4 3 3 SCL signal 3 3 1 SCL LOW period The SCL LOW period is defined as the time while SCL line is in a LOW state from the falling edge until the raising edge of SCL signal The minimum time in which the signal can be 0 is defined in table 3 6 The C bus specification protocol don t specify any value for the maximum time but the SCL operating freguency will decrease with the increase of this value Figure 3 7 shows how the SCL LOW period is measured 70 SDA 30 tLow Figure 3 7 LOW period of SCL signal 1 Symbol P
7. llfscL Figure 3 9 SCL clock frequency 1 3 4 SDA signal 43 Symbol Parameter DUE 2m Em Hsmode Unit y Min Max Min Max Min Max Min Max F_SCL SCL clock frequency 0 100 0 400 0 1000 0 3400 kHz Table 3 8 Operating frequency for SCL Clock 3 4 SDA signal 3 4 1 Data hold time The data hold time is defined as the time elapsed from the falling edge of the SCL signal to the change of the SDA state from 0 to 1 or from 1 to 0 Applies to data in transmission and to the ACK signal Figure 3 10 shows how the data hold time is defined and in table 3 9 are the maximum and the minimum hold times allowed for all bus speeds For the minimum hold time the device must internally provide a hold time to bridge the undefined region of the falling edge of SCL signal If the device operates in Sm Fm or Fm it should provide a data hold time of at least 300ns However if it operates in Hs mode the data hold time is defined by the threshold of the input circuit for the SCL signal A low threshold will minimizes the hold time The maximum hold time allowed operating at Sm Fm or Fm could be the value found in table 3 9 This maximum hold time should be met if the SCL line is not stretched otherwise the data must be valid by the set up time before it releases the SCL line 70 SDA 30 tHD DAT Figure 3 10 Data hold time during a transfer 1 Symbol Paran
8. 8 In a WRITE operation the master device will send 8 bits to the slave addressed and waits for the slave ACK After that if there are no more data to transfer the master device stops the communication by sending a STOP condition see figure 2 10 On the other hand if there s still data to be transferred the master device will send the reminder bits However if a master still 2 1 PC Inter Integrated Circuit 11 wishes communicate on the bus it has to perform a repeated START condition and address the desirable device without the need of sending a STOP condition before the repeated START con dition From this point the master initiates a new transfer that could be a WRITE or READ format For the READ operation the master will receive the data sent from the addressed slave Every 8 bits received the master device produces an ACK signalling the slave that the data was received successfully and that it can send another 8 bits When all the data gets transferred the master produces a Not Acknowledge NACK signal to inform the slave that all the data was transferred and then produces a STOP condition The master starts reading the data promptly after sending the first byte Figure 2 11 shows how a master reads data from a slave device 1 s SLAVE ADDRESS A DATA DATA data transferred read n bytes acknowledge Figure 2 11 Example of a READ operation 8 In the 72C bus there are different ways to transfer data A m
9. Open Verification Methodology OVM and non standard verification environment The SmartDV s verification IP is compliant with 2 1 and also 3 0 of the C bus specifications protocol 22 2 3 Other Verification platforms 27 Master BFM Figure 2 20 SmartDV VIP topology 22 MASTER BFM To operate as a master the user first has to configure each master with different parameters Then the master starts the transfer performing the functions previously set in the testbench read write general call The data read from the slave is placed in RX Byte FIFO see figure 2 20 Figure 2 21 shows the topology of a master BFM config cmd frame frame mE rdata sda out ck clkGen stats _ Sstats scl_out glitch scl_in Figure 2 21 Master BFM topology 22 This master also arbitrates the bus to determine which master will complete the transmission in order to ensure data integrity The arbitration is performed using the SDA and the SCL lines 28 State of the Art and the master reaction can be configured to act in different ways if the bus is busy This arbitra tion follow the rules described in the IC bus specification manual Another feature of the master BFM is the error injection This is made by forcing it to abort the data transfer at the specified bit position or send an ACK on the last byte written SLAVE BFM Operating as a slave the initial process is the
10. T HD DAT T SU DAT dk dk Gb dk dk db db pa Hold time for START and reSTART condition Set up time for repeated START condition Data valide ACK time Set up time for STOP condition Bus free time between a STOP and a START Minimal time for Low period of SCL Minimal time for Hight period of SCL Minimal data hold time Minimal time for data set up 93 94 PC Verification Suite Configuration File T VD DAT F Minimal time for valid data ASA Slave address DMS Data sent from Master to Slave DSM Data sent from Slave to Master F SCL Clock Frequency KK K ck ok K ok ok OK ok K OK K OK OK K OK K CE OK K CE K CE OK K CE K CE OK K CE K CE OK CE CE K CE OK CE CE K CE K K CE K CE OK K OK K OK OK K OK K OK K OK OK K OK K KK K ck ok K ok ok OK ok K OK K OK OK K OK K CE OK K CE K CE K K CE K CE K K CE K CE OK CE CE K CE OK K CE K CE OK K CE K K OK K CE K ok OK K OK K OK K OK OK K OK OK J Appendix C Final Verification Report compact version Listing C 1 Interface declaration skok okokokok KK KKK KK KK k Kk KK k KK k K FG KKK KK KK k K k KK k Kk K Kk KK k K I2C Verification Suite Report EEEE K OH K KK KK kk K K K Kk KK k KK K K FG OH K K Kk KK k K k K K K Kk K Kk KK K K skok KKK KKK skok okokok okokokookokokokokookokokookokokokok E E E E E E E RK k k k kk k k k K k Kk kk RK k Kk Kk k kk Kk k k k K k K k K K K K K k
11. is necessary to instantiate more than one device in the bus and the platform should be able to verify if is the correct device that acknowledges the address transmitted and also be able to verify in case of general call address if the data transmitted was the same data received by all the devices connected to the C bus After verifying all the specifications described in the chapter 3 is appropriate to have a report with the result of the simulation For that the C verification suite has to produce a report with the results of the simulation allowing the user to see how the circuit behaved during the simulation 51 52 The PC Verification Suite 4 2 Structure Adopted In order to meet all the requirements previously described the C verification suite is com prised by 5 main blocks They are the master slave bus functional model BFM the data gen erator the scoreboard the bus analyzer and the report generator The master slave bus functional model performs data transfers with the devices under verification DUV with the data generated by the data generator The scoreboard and the bus analyzer are those which verify the specifica tions described above the data integrity and the 72C bus specification protocol respectively Finally the report generator block generates a report after the verification process with all the events that occurred during this process Figure 4 1 shows how these modules fit into the adopted structure De
12. is used to see if all devices have received the transmitted byte 4 2 7 Scoreboard The verification of a I2C device as explained in chapter 3 consists in verify the C bus spec ification protocol and the integrity of the data transferred to ensure that a device can perform data transfers without losing data or perform wrong data transfers To verify if the integrity of the data transferred the PC Verification Suite has a class called Scoreboard that compares the bytes transferred in two steps In the first one the Scoreboard compares the byte generated with the byte transferred in the C bus and in the second step it compares the byte transferred in the C bus with the byte received When the data generator provides the data for the verification platform performs a transmis sion the data generator class also put the same byte into a mailbox This allow the scoreboard to have the same byte that which was sent to the master slave BFM class to be transmitted After all the bits transmitted the Scoreboard class starts the data integrity verification process It compares 4 2 Structure Adopted 67 the byte transferred in the bus provided by the bus analyzer module as will be explained later on with the byte provided by the data generator If the verification fails an error is reported However if the data integrity is verified the Scoreboard follows to the next step which verifies the integrity of the byte transferred in the bus wit
13. 00us 45 00us 45 30us 50 00us 50 00us 55 00us 55 00us 60 00us 65 00us 65 00us 70 00us 75 00us 75 00us 75 30us 80 00us 80 00us 85 00us 85 00us 90 00us 95 00us 95 00us 100 00us 105 00us 105 00us 110 00us 110 00us 115 00us 115 00us 115 30us 120 00us 120 00us 125 00us 125 00us 125 30us 130 00us 130 00us 135 00us 135 00us 140 00us 145 00us 145 00us 150 00us 155 00us FSCL with 100 000000 kHz TLOW with 5 00us T HIGH with 5 00us FSCL with 100 000000 kHz TLOW with 5 00us T HIGH with 5 00us FSCL with 100 000000 kHz THD DAT with 0 30us TSU DAT with 4 70us TLOW with 5 00us T HIGH with 5 00us FSCL with 100 000000 kHz TLOW with 5 00us T HIGH with 5 00us FSCL with 100 000000 kHz TLOW with 5 00us T HIGH with 5 00us FSCL with 100 000000 kHz THD DAT with 0 30us TSU DAT with 4 70us TLOW with 5 00us T HIGH with 5 00us FSCL with 100 000000 kHz TLOW with 5 00us T HIGH with 5 00us FSCL with 100 000000 kHz TLOW with 5 00us T HIGH with 5 00us FSCL with 100 000000 kHz THD DAT minimal time FAIL with 0 00us TSU DAT with 5 00us TLOW with 5 00us T HIGH with 5 00us FSCL with 100 000000 kHz T HD DAT with 0 30us TSU DAT with 4 70us TLOW with 5 00us T HIGH with 5 00us E SCL with 100 000000 kHz T HD DAT with 0 30us TSU DAT with 4 70us TLOW with 5 00us T HIGH with 5 00us F SCL with 100 000000 kHz TLOW with 5 00us T HIGH with 5 00u
14. 2 When a process tries to write data into a mailbox and this is full the process blocks until a value is removed from the mailbox A process also blocks if it tries to get data from an empty mailbox until another process put a value into the mailbox SystemVerilog defines the mailboxes as ob jects Conseguently they has to be instantiated by calling the new function which also provides an optional size argument to limit the number of entries of the mailbox If no size is defined or if is defined as being O the mailbox is defined as unrestricted supporting an unlimited number of entries 4 2 Structure Adopted 59 Passing information to a mailbox is quite simple for a thread To write data into the mailbox a thread uses the put task and to remove if uses the ger task The put task blocks if the mailbox is full and the get task if it is empty Besides the put and ger tasks mailboxes supports other tasks such as 28 try put This task try to place a value in the mailbox Unlike the put this task does not block if the mailbox is full try get This task try to remove a message Unlike the get task the try get does not block if the mailbox is empty x num This task is used when a thread need want to know how messages are in the mailbox This returns the number of messages in the mailbox x peek The peek retrieves a message from the mailbox like the ger but without remov ing
15. 4 3 Example of a bi directional communication PAD To allow the communications between all blocks represented in figure 4 1 are used Interfaces construct from System Verilog This is a new construct added in System Verilog with the aim of enabling communication between blocks and also to facilitate the design re use Interfaces are hierarchical structures that can contain other interfaces 26 SYSTEM VERILOG INTERFACES In Verilog language the modules are connected together through module ports To connect different modules in a large design this method become annoying and excessive Despite pro viding a simple and intuitive way to connect different modules in a design in large and complex designs Verilog s module ports has some disadvantages For instance the port declarations must be duplicated in multiple modules Communication protocols must also be duplicated in several modules and there is no guarantee that all declarations are compatible in different modules Fi nally a change in the design specifications can lead to changes in different modules SystemVerilog brings a new port type to Verilog the Interface This allows the designer to group several ports together representing them as a single port and declare the interface in a sin gle location Each module that uses signals declared in one interface has a single port of interface 4 2 Structure Adopted 55 type insted of many ports with many signals like in the Veril
16. ADDRESS GA ACK DATA ACK DATA SCL eS EE 9 1 8 9 s P START STOP Condition Condition Figure 2 3 A complete data transfer on the PC bus 8 8 State of the Art e Start and Stop conditions Any transfer begins with a START S condition and ends with a STOP P condition When SCL line remains HIGH during a transition from HIGH to LOW in SDA line occurs a START condition is defined In the event of a transition from LOW to HIGH in SDA line while SCL line remains HIGH a STOP condition is performed Figure 2 4 shows how the START condition is performed and figure 2 5 represents a STOP condition 1 SDA sDA SCL SCL S P START STOP Condition Condition Figure 2 4 START Condition 8 Figure 2 5 STOP Condition 8 The master device despite being responsible for generating the SCL signal is also the one who always generates the START and STOP conditions After a STOP condition occurs the bus become free and other data transfers may occur How ever if a repeated START condition is generated instead of a STOP condition the bus remains busy and other devices who want to start a transfer have to wait until the bus becomes free The START and the repeated START conditions are functionally the same e Acknowledge ACK and not Acknowledge NACK The Acknowledge ACK or the Not Acknowledge NACK occur each time that 8 bits are transmitted The ACK is used to signal the transmitter that the byte transferred
17. Acknowledge Advanced Telecom Computing Architecture Advanced Verification Methodology Bus Functional Model Compliance Management System Direct Programming Interface Device Under Test Device Under Verification Electronic design automation Electrically Erasable Programmable Read Only Memory Finite State Machine Fast mode Fast Mode Plus First In First Out Hardware Verification and Description Language High speed Mode Inter Integrated circuit Institute of Electrical and Electronics Engineers Intellectual Property Integrated Circuit Intelligent Platform Management Interface Low Significant Bit Most Significant Bit Not Acknowledge Next eXPerience Object Oriented Programing Open Verification Methodology Power Management Bus Reference Verification Methodology Register Transfer Level Serial CLock Serial DAta Standard Mode System Management Bus Software und System Entwicklung Transaction Level Modelling Universal Verification Component XV XVI Abbreviations Chapter 1 Introduction In today s world microelectronic circuits are getting more and more complex in size and spe cially in functionality over the times One of the first persons to identify this trend was Gordon Moore co founder of the Intel Corporation He claimed in an article published in 1965 that a doubling in transistor density happens every 18 months Later on this became known as The Moore Law This empirical observation applies t
18. However it can happen that the slave does not performs the ACK signal after even though the data 48 Verification of PC Devices has been transmitted well or if something goes wrong the slave does not report it with the NACK performing an ACK signal to the master device To avoid this potential errors the Invalid ACK NACK specification checks if at 9 h SCL pulse the ACK signal should be or not be performed by the slave device Another failure can occur when the master device is receiving data from the slave and do not perform the NACK when all data gets transferred or if the master generates a NACK before the slave transmits all the bytes Both these situations are detectable in ACK NACK specification 3 6 3 Invalid state This verification is used to detect illegal transitions on the 72C bus These transitions can occur e When a master device starts performing the START condition and insted of putting the SCL line in a low state releases the SDA line e If during a data transfer the SDA signal changes in the HIGH period of the SCL line e After the master has transferred all the data and after received the ACK signal from the slave does not performs the STOP condition and still generates the SCL clock pulse e After read all the data from a slave and after performs a the NACK the master keep gener ating the SCL clock pulses instead of performing the STOP condition 3 7 Summary 49 3 7 Summary In this chapter are descri
19. OK RR KR k k k k k k kK k k KKK RR k Kk Kk k Kk Kk k k k K k Kk K K K K K FR K K K K K KKK K k K k KK K Kk KK k K K K k K K K EEEE E K KKK kk K k K K k Kk K Kk Kk KKK K K K FO k k Kk kkk kkk kkk kkk Final Result xxokokokokokokokokokokokokokokokookokokokokokokokokokokok k EEK K K K KR KK k k K k KK K Kk KK KKK K K K K EEEE E OH k DD k kk K k k K k Kk KK k KK k K k K K K K K 3K KK OK KOK KR RR DR EEEE KKK EE RR DR E E KK RR E K k k k k k k k k k KKK kk k Kk kkk kk Kk k k k Kk Kk K K k K k KK Kk KK Kk KK Kk KK KK KK KK KK KK KK KK KK KK KK KK KK KK KK KK KK KK KK KK Total errors Verification FAIL Total Errors in Write Mode I2C data transferred errors I2C Specification Standard errors KKK KK Kk k KKK KKK KKK KKK KKK KKK KKK KKK KKK KK KKK 102 Final Verification Report detailed version ok KK ok KK kokokokok Total Errors in Read Mode 5 set kokokokok KKK kokokokok I2C data transferred errors 0 gt kokokokok DEE EES I2C Specification Standard errors 5 DEE EES ok KK PEPEE PEPEE ok KK ok KK ok KK x Total simulation time 402 00us xxx kkk k xokekokek EH oko okokokokokok GRIGG GIGI GC IG GI ICI I I GI SII IC sk ac ak a ak ak ak skok CC KK KKK EEEE KK RRR RK KKK RR E K E K RK KKK k Kk Kk K kk kk k k k k k K k KK K K K K K o ok ok ok okook oko ok kok ok ok k okokokokokokokokok
20. a restart condition in order to get a new transmission Figure 2 4 shows the ACK and the NACK signals during a data transfer on the 7 C bus e Byte Format In C bus protocol the data is transferred in SDA line Are transferred 8 bits one byte each time and there is no limit on the number of bytes 8 bits each time to transfer After each byte transferred a ACK or NACK has to occur in order to inform the transmitter that the eight trans mitted bits were received correctly in case of an ACK or that something went wrong in the case of a NACK Figure 2 4 shows a data transfer on the C bus 1 1 FE 3 acknowledgement acknowledgement signal from slave signal from receiver SCL sorgr 1 2 ____ 7 8 9 1 2 3to8 9 srorP ACK t ACK EM START or STOP or repeated START byte complete clock line held LOW repeated START condition interrupt within slave while interrupts are serviced condition Figure 2 8 Example of a data transfer on the C bus 1 The 8 bits are transferred from the most significant bit MSB to the less significant bit LSB If the slave after acknowledged the received byte cannot receive or transmit another byte because 10 State of the Art is performing second task for example it can hold the communication by putting the SCL line in a LOW state forcing the master device to wait until it finishes and become free to receive or transmit more bytes e Data transfer To start a tra
21. addition to the above this platform presents some important features such as e Supports IC bus specification protocol v2 1 and v3 0 e Supports all speed protocol operations e Two operating modes master and slave e Detection and testbench notification of all time and protocol errors e Possibility to address slaves with 7 or 10 bits Expected results can be compared with read data e Bus accurate timing e Error generation and injection in the slave or master devices Supports counting events occurred in the bus Implemented in Unencrypted Open Vera and System Verilog Supports Reference Verification Methodology RVM Advanced Verification Methodology AVM Verification Methodology Manual VMM 30 State of the Art Non standard verification environment Full I2C master and slave functionality Possibility to test different bus traffic for Read Write General Call and CBUS Supports complex seguence of 7 10 bit with repeated start command seguences Supports master slave arbitration and clock synchronization Callbacks in master slave and monitor for user processing of data Error injection such us master abort in middle of transaction ACK in the last byte during a read phase master ignores NACK from slave in write phase slave performs random NACK s e Notifies the testbench if Wrong transaction occurs PC specification time is violated PC spceificati
22. besides describing the data transfers errors and the C specification protocol errors also describes the general call errors Figurel 5 5 represents the individual report for this type of verification Once again the global report is always the same as described above Figure 5 5 Single report for general call verification After verifying the slave device the C Verification Suite creates a folder named with the local date and current time Inside this folder the platform creates another folder named with the address of the slave verified which contains the verification report of that device as well as the pa rameters used to produce the stimulus of that verification If more than one device is verified the verification platform creates as many folders as the devices tested in the same verification process Figure 5 6 represents the structure of the files created by the verification platform DO 6 2010 06 27 2010 06 27 08h27m41s 08h48m41s 12c_ i testparamete verification rs sv i o i global_ 1 08 verification Figure 5 6 Structure of the report files After the verification process ends the user should check the verification report created as explained above This report contains all the violations and errors occurred during the verification 84 Verification of PC Slave Devices process If the user choose the report type as a detailed report the verification reports besides containing the detected
23. choose between all the specifications described in chapter 3 which are T HD STA Hold time for START and re START condition T SU STA Set up time for repeated START condition T VD ACK Data valid ACK time T SU STO Set up for STOP condition T BUF Bus free time between a STOP and START conditions T LOW Minimal time for LOW period of SCL signal x T HIGH Minimal time for HIGH period of SCL signal T HD DAT Minimal and Maximum data hold time T SU DAT Minimal time for data set up x T VD DAT Minimal time for valid data A S A Device address integrity D M S Data from master to slave integrity D S M Data from slave to master integrity x F SCL Invalid SCL frequency x ST LOW This parameter is for the user define the low period of the SCL clock when the PC Verification Suite performs the signal clock with master BFM x ST HIGH This parameter is for the user define the high period of the SCL clock when the C Verification Suite performs the signal clock with master BFM After the user configures all the parameters of the verification platform the config class con figure all the classes in the environment class and also the bus analyzer module to complies with the configuration parameters defined by the user The C Verification Suite allow the user to configure several verifications to the same device or to others This is very useful because if the user wants to run se
24. errors and violations also contain all the events occurred on the C during the data transferred In appendix C is represented a verification report in compact version and in appendix D is another report of the same verification but in detailed version Appendix E and F are the reports of the general call verification in compact and detail version respectively 5 4 Summary In this chapter are represented two of many possible verifications that the developed C ver ification platform can perform The verifications performed here verify all the C bus specifica tions the general call address and also perform data integrity checks see chapter 3 It is also explained all the possible reports that the C Verification Suite provides as well as structure of folders where those verification reports are saved Compact and detailed verification reports are represented in appendix C and D respectively during a complete verifiation and also in appendix E and F during a general call verification Chapter 6 Conclusion In this chapter is made a critical analysis of the work done so far Are also given some suggestions for future improvements 6 1 Conclusion The PC Verification Suite structurally was well specified and developed It proves that is possible to develop a verification platform using SystemVerilog standard Hardware Verification and Description Language HVDL The developed verification platform meets all the objective
25. it from the mailbox If the mailbox is empty the peek task blocks until a new message is placed in the mailbox try_peek This task try to retrieve a message from the mailbox However if the mailbox is empty it does not block unlike the peek As stated before the environment class comprises not only methods but also classes used to execute and control the verification process These classes are represented in figure 4 1 in the envi ronment field and they are the data generator the master slave BFM the receiver the scoreboard the report generator and the config class The data generator will produce data to be sent by the master slave BFM when performing data transfers The receiver is used to receive the data from the devices under verification to be compared with the data transmitted in the J C and with the data generated in the data generator This comparison is done in the scoreboard class The final report with all the events occurred in the bus during the simulation is generated by the report generator The config class configure all the classes in the environment class and the bus analyzer to met all the parameters specified by the user Next subsection will describe each one of these classes and also the bus analyzer explaining how they work and how were implemented 4 2 3 Config The C Verification Suite offers a set of configuration parameters that allow the user to con figure the verification process Thes
26. k KKK k k k Kk Kk k kk Kk k kk K k Kk K K K K K I2C Specification Standard OK 15 00us T HD STA with 4 00us OK 20 00us TLOW with 5 00us OK 25 00us T HIGH with 5 00us OK 25 00us F SCL with 100 000000 kHz 105 106 OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK FAIL 105 00us OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK 30 00us 35 00us 35 00us 40 00us 45 00us 45 00us 50 00us 55 00us 55 00us 60 00us 65 00us 65 00us 70 00us 75 00us 75 00us 80 00us 85 00us 85 00us 90 00us 95 00us 95 00us 100 00us 105 00us 105 00us 110 00us 110 00us 115 00us 115 00us 115 30us 120 00us 120 00us 125 00us 125 00us 125 30us 130 00us 130 00us 135 00us 135 00us 140 00us 145 00us 145 00us 150 00us 155 00us 155 00us 160 00us 165 00us 165 00us 170 00us TLOW with 5 00us T_HIGH with 5 00us F SCL with 100 000000 T LOW with 5 00us T HIGH with 5 00us F SCL with 100 000000 TLOW with 5 00us T HIGH with 5 00us F SCL with 100 000000 T LOW with 5 00us T HIGH with 5 00us F SCL with 100 000000 TLOW with 5 00us T HIGH with 5 00us F SCL with 100 000000 T LOW with 5 00us T HIGH with 5 00us F SCL with 100 000000 TLOW with 5 00us T HIGH w
27. k kk kk RK k Kk Kk k kk Kk k k k K k K k K K K K k skok KKK KKK RK RR KKK KOR KK KKK KK RR E K k k k k k k K k k k kk kk k Kk Kk k kk Kk k k k K k Kk K K K K kK FOG IK GR Ck ak a ok kkkkkkkkkkkkkkkkkkkkkkkkk Communication nr FORK K k KKK KK KK K Kk KK K K K K FG OH K K Kk KK k K k K K K Kk K Kk KK K K DOES SE SE k k k k k k kkk Kk k k k K k K K K KK K FR KK K k KK k K k K K k Kk K Kk KK k K skok oko okokokokokokookookokokok okokokookokokokokookokokookookokokok okokokookokokokokookookokookok E E k k k kK k k k k kk k Kk kkk kk Kk k kk Kk Kk K K k K k skok KKK KKK OK KR okokokookokokokokookokokookokokokok E E E DR E RK E E E E K k k k k k k k k k k kk kk k Kk kkk kk Kk k k k K k K k K K k K k RR k k k k k k k k kkk kkk 1 Transfer Byte nr l KK K OK K k KK KK K KK K KK OK KK K K skok OK KKK ROKK okookokokok CK KKK OR ROK E E DR E ORK KR RK k k k k k k k kK k k k kk kk k Kk Kk k kk Kk k k k K k K k K K K K K I2C Specification Standard OK 208 70us OK 212 70us T_BUF with 4 70us T_HD_STA with 4 00us 100 OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK FAIL 217 222 222 227 232 232 237 242 242 243 247 247 252 252 257 262 262 267 242 272 273 27 Z 282 282 283 287 287 292 292 2
28. protocol standard mode fast mode fast mode plus and high speed mode INPUT METHOD This method defines how the data is generated it could be generated randomly by the platform or could be seguential from 0 to 255 several times The verifica tion platform also provides the option of read the data from a file instead of generating the data N COMM The user defines the number of communications to perform to the DUT N BYTES The user defines the number of bytes to transfer for each communication to the DUT REPORT TYPE This parameter is for the user to choose between a detailed report which log all events occurred in the bus or a compact report which only report the errors occurred during the simulation DISPLAY REPORT This parameter print the final report in the command line STOP ON ERROR This parameter is used to stop the verification process immediately 1f an error occur VERIFICATION TYPE This parameter is for the user to define the type of verification that he wants the platform to perform The C Verification Suite could performs 4 types of verifications which are Verification of the IC bus specification protocol and data integrity Verification of the 72C bus specification protocol only Verification of data integrity only 4 2 Structure Adopted 61 Specifications defined by the user The user is allowed to choose which specifications want to verify He can
29. represented a complete data transfer This type of data transfer formats is usually used to control a serial memory The first byte is to write the internal location of the memory where the bytes will be After the repeated START condition the slaves start writting the data to the memory 1 e Data Validity As stated earlier the data is transmitted in the SDA line To ensure that all devices connected to the bus are able to read the data properly transferred in the SDA line the SDA line has to be stable during the HIGH period of SCL line The data SDA line only is allowed to change when SCL line in on LOW state Figure 2 3 shows how the SDA line is read by the devices ass data line change stable of data data valid allowed Figure 2 13 Data valid 8 For each pulse of the SCL signal generated by the master one bit of data is transferred on the SDA line 1 e I C bus speeds In the early days the C bus was only able to communicate at 100 kbit s However since its appearance that the 72C bus communication protocol has been constantly improving One of those improvements was the speed of the operations where the user instead of having one speed mode for transfer has now 4 speed modes which are 1 e Standard mode Sm up to 100kbit s e Fast mode Fm up to 400kbit s 2 1 PC Inter Integrated Circuit 13 e Fast mode Plus Fm up to 1Mbit s e High speed mode HS mode up to 3 4Mbit s Despite the
30. same as in the master operation Starts with the configuration of all slaves Next each slave will monitor the bus to determine if it has been selected to start a data transfer It always respond to a transfer if it has been selected Figure 2 22 shows the topology of the slave BFM If the transfer resguested was to read data the slave will respond by sending data which can be fed through its TX Byte FIFO However if the reguested transfer was to write the slave will receive the data transmitted by the master and passes it to the RX Byte FIFO see figure 2 20 frame frame ee fifo scl out glitch scl in wdata filter BFM Ser sda out rdata glitch r filter sda in a stats S stats Figure 2 22 Slave BFM topology 22 Like in the master BFM the slave can be configured to respond incorrectly to transfers re quests by sending an acknowledge ACK or not acknowledge NACK The slave BFM allow callbacks from the user for read and write command processing MONITOR This component will monitor the C bus looking not only for protocol errors but also for timing errors Its topology is shown in figure 2 23 2 3 Other Verification platforms 29 config config E EE Monitor BFM SCL SDA ES stats Figure 2 23 Monitor topology 22 The monitor also keeps track of all the access on the bus This information can be read after or even during the verification FEATURES In
31. the data can be handled by those devices However the devices that cannot handle with those bytes must perform a NACK signal to ignore them 2 1 2 Advantages and limitations of I2C bus The C bus was developed in a way to provide a correct and fast communication between different ICs on a circuit board of a Television or Radio However owing to his success the J 2C bus guickly grew beyond the limits of Television and Radio and can now be found in almost every computer motherboards and other embedded devices It also allow the communication between multiple circuit boards in eguipments with or without using a shield cable depending on the dis tance and speed of data transfer 1 9 The C bus bring a lot of advantages to the inter chip communications Some of them are as follows e Only two bus lines are required e Each slave device connected has its own unique address e Can choose between a 7 or 10 bit addressing addresses with 10 bits allow more devices on the same bus but it is less popular e No strict baud rate specified since the clock is driven directly by the master e Multi master support with up to 8 masters in a single bus system e Protocol can be emulated by microcontrollers without integrated I2C peripheral device e Low cost e Supports up to 3 4 Mbits sec transfer speeds e ICs can be added or removed from system with out effecting any other circuit on the bus 2 1 PC Inter Integrated Circuit 15 Integr
32. the mailbox by the data generator and compares it with the data transmitted in the bus If data integrity is verified the scoreboard will then verify if each device has received the correct byte To perform this the scoreboard begins by detecting how many bytes were placed in the mailbox by the receiver class Next starts by picking up bytes from the mailbox and compares them with the byte transmitted in the C bus If any of bytes picked up from the mailbox differs from the byte transferred the data integrity verification fails This verification also fails if the number of bytes presented in the mailbox differs from the number of devices connected to the PC bus The number of devices connected to the bus has to be specified by the user when configuring 68 The PC Verification Suite the verification process This failure means that some device ignored the general call address or did not received correctly the byte sent 4 2 8 Bus Analyzer The main goal of the C Verification Suite is to ensure that C devices can accomplish the tasks for which they were designed successfully The verification process of the PC Verification Suite consists in verify the C bus specification protocol and also the integrity of the data trans ferred To verify the data integrity during the transfers performed the verification platform uses the scoreboard class explained above subsection 4 2 7 For the C bus specification protocol this platform incorporate
33. 2 0 7 Version 3 0 was released in 2007 and added Fast mode plus operating speed and a device ID mechanism This is the most recent standard 1 Nowadays being a world standard the C bus is implemented in over than 1000 different integrated circuits ICs and manufactured by more than 50 companies Like in the past the C bus still being used to control radios and Tv s but nowadays is also used in other different control architectures such us System Management Bus SMBus Power Management Bus PMBus In telligent Platform Management Interface IPMI and Advanced Telecom Computing Architecture ATCA 1 2 1 1 The 2C Bus Protocol The C bus is composed by two bi directional wires the Serial DAta line SDA and the Se rial Clock Line SCL Every device connected to the bus has a unique address and can act as a master or as a slave device depending on its functionality This bus is also a Multi master bus which is the same as saying that more than one device capable of initiate a data transfer can be connected to it however when one device starts transferring data all the others devices hooked on the bus are regarded as slaves The master device is the one which initiates a data transfer on the bus and also who generates the SCL signals to enables the transfer 1 Figures 2 1 and 2 2 shows master slave and a Multi master architectures respectively Vdd Figure 2 1 master slave architecture 2 1
34. 2C Verification Component Topology 20 Usage Model for HVC 800 SV lt lt 0 000000000000 22 nSys Verification Suite ee 24 SmartDV VIP for IC go gee ordo o do Ra l oaa 26 SmartDV VIP topology o es ea lt EF Master BFM topology ooa af Slave BFM topology lt lt lt lt lt 4 28 Monitor topology lt lt lt lt lene 29 The CMS automates protocol compliance verification 31 The UVC for Z C Environment 43449 PY o4 rk Sr pd dE 32 START condition ne 37 Repeated START 2222 38 Acknowledge ACK 22 39 Not Acknowledge NACK i 39 STOP conditio s ss hb ek eV a ame ed d RV ud x eis 39 Bus free time between a STOP anda START 40 LOW period of SCL signal 00000000 2 eee 41 HIGH period of SCLsignal 0 0 000000000000 42 SCL clock frequency ee 42 Data hold time during a transfer lens 43 Data set up time during a transfer 44 Data valid time during a transfer ee 45 XI xii 3 13 3 14 3 15 3 16 41 42 43 4 4 4 5 4 6 4 7 4 8 4 9 4 10 411 4 12 5 1 5 2 53 54 5 5 5 6 Al A2 A3 LIST OF FIGURES Verification of the slave address llle 45 Data integrity check from master to slave lt lt lt lt 44 46 Data integrity check from slave to master lt llle 47 Void Message ax ce ae th wae a br ae ak LL a E E ob 47 PC Verification Suite ke ark ie
35. 364 1800 html Synopsys Verification IP for PC Available online at http www synplicity com dw doc php ds v i2c ds pdf eInfochips LC SystemVerilog Verification Component 2009 Available online at http www einfochips com download I2C Syst Verilog pdf hdl Design House HVC800 SV PC SystemVerilog Monitor 2007 Available online at http www hdl dh com prodbroch HVC800 20 04 07 pdf nSYS Design Systems PC nVS nVS Verification Suite Available online at http www nsysinc com i2c nvs pdf 109 110 REFERENCES 22 SmartDV Technologies PC Verification IP Datasheet December 2007 23 SmartDV Technologies 17C Verification IP Available online at http www smart dv com vip i2c html 24 Cadence Incisive Verification IP for IC Available online at http www cadence com rl Resources datasheets I2C VIP DS pdf 25 Cadence Compliance Management System Available online at http www cadence com products fv verification ip Pages cms aspx 26 Peter Jensen Wolfgang Ecker Thomas Kruse and Martin Zambaldi SystemVerilog Interface Based Design 2004 Forum on specification amp Design Languages 2004 FDL 04 Available online at http www syosil com files publications FDL04 jensen kruse ecker zambaldi pdf 27 Stuart Sutherland Simon Davidmann and Peter Flake SystemVerilog for Design A Guide to Using SystemVer ilog for Hardware Desgin and Modeling Springer Second edition 2006 28 Doulos Ltd
36. 8008V PC monitor Signal pin level Figure 2 17 Usage Model for HVC 800 SV 20 The HVC 800 SV as shown in figure 2 17 does not participate directly in the C communi cation All signals of IC bus protocol communication are inputs of the monitor component The hdl Design House C bus monitor performs two functions One of them checks if any transfer violates the C protocol specifications the other detects all transitions that occurred on the bus and makes them available to the other testbench components The HVC 800 SV monitor inherent role is to raise the level of abstraction from the signal level domain into the transaction level domain However the remaining testbench components connected to this model are designed at the transaction level allowing the reusability the components are more easy to maintain and quicker to design For this purpose the HVC 800 SV monitor presents two transaction level mod eling TLM outputs one for error analysis and another for the transactions This component is also compliant with the C specification protocol version 2 1 implemented in Systemverilog and use SystemVerilog assertions properties to check the 72C protocol HVC 800 SV detects illegal conditions and void transactions START condition followed by STOP condi tion With this component is also possible to detect violations in setup time of START and STOP 2 3 Other Verification platforms 23 conditions hold time of Start conditi
37. 92 70us 70us 70us 70us 70us 70us 70us 70us 70us 00us 70us 70us 70us 70us 70us 70us 70us 70us 70us 70us 00us 70us 70us 70us 70us 00us 70us 70us 70us 70us 70us OK 298 00us OK 303 00us OK 303 00us FAIL 303 00us OK 308 00us OK 308 00us OK 313 00us OK 313 00us FAIL 313 00us TSU DAT with 5 00us TLOW with 5 00us T HIGH with 5 00us OK OK OK OK OK OK OK OK 318 318 323 323 328 333 333 338 00us 00us 00us 00us 00us 00us 00us 00us TLOW with 5 00us T HIGH with 5 00us F SCL with 100 000000 kHz TLOW with 5 00us T HIGH with 5 00us F SCL with 100 000000 kHz TLOW with 5 00us T HIGH with 5 00us F SCL with 100 000000 kHz T HD DAT with 0 30us TSU DAT with 4 70us TLOW with 5 00us T HIGH with 5 00us F SCL with 100 000000 kHz TLOW with 5 00us T HIGH with 5 00us F SCL with 100 000000 kHz TLOW with 5 00us T HIGH with 5 00us F SCL with 100 000000 kHz T HD DAT with 0 30us TSU DAT with 4 70us TLOW with 5 00us T HIGH with 5 00us F SCL with 100 000000 kHz T HD DAT with 0 30us TSU DAT with 4 70us TLOW with 5 00us T HIGH with 5 00us F SCL with 100 000000 kHz T VD ACK with 0 00us 292 70us Final Verification Report detailed version THD DAT minimal time FAIL with 0 00us TLOW with 5 30us T HIGH with 5 00us F SCL with 97 000000 kHz
38. C slave device is as follows Listing 5 1 Interface declaration SLAVE ADDR 14 BUS DEVICES 2 SCL FREO INPUT METHOD N COMM 3 N BYTES 5 DISPLAY REPORT REPORT TYPE STOP ON ERROR VERIFICATION TYPE Since the VERIFICATION TYPE is defined to verify all the specifications data protocol and data integrity there is no need to insert the individual verifications parameters To verify the general call address the process is the same described above Note that the SLAVE ADDR field is now 0 and once again since the platform will verify all the specifica tions there is no need to define the verifications to perform 5 3 Verification Results 81 Listing 5 2 Interface declaration SLAVE ADDR BUS DEVICES 2 SCL FREQ INPUT METHOD N COMM N BYTES nN to O DISPLAY REPORT REPORT TYPE STOP ON ERROR VERIFICATION TYPE After the configuration process is done and the device under verification is connected to the PC the verification can now begin These two verifications can be defined in the configuration file The 72C Verification Suite will run the first and then automatically will start the second The complete configuration file is represented in appendix B 5 3 Verification Results During the verification process the C Verification Suite stimulate the DUT and at the same time keeps a record of all the events occurred in the C bus as well as the result of the data in tegrity verificat
39. FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO PC Verification Suite Miguel Jos Chaves Caetano Master in Electrical and Computer Engineering Supervisor Jos Carlos dos Santos Alves PhD Co supervisor Pedro Faria de Oliveira Eng July 2010 Copyright by Miguel Caetano 2010 Some rights reserved OOOO You are free to Share to copy distribute and transmit the work Under the following conditions Attribution You must attribute the work in the manner specified by the author or licensor but not in any way that suggests that they endorse you or your use of the work Noncommercial You may not use this work for commercial purposes No Derivative Works You may not alter transform or build upon this work With the understanding that Waiver Any of the above conditions can be waived if you get permission from the copy right holder Other Rights In no way are any of the following rights affected by the license e Your fair dealing or fair use rights e The author s moral rights e Rights other persons may have either in the work itself or in how the work is used such as publicity or privacy rights Notice For any reuse or distribution you must make clear to others the license terms of this work The best way to do this is with a link to this web page Resumo Ao longo destes anos os circuitos t m vindo a ficar cada vez mais comp
40. K K k K Kk KK K K K K FO KK KK K Kk Kk k K K KK K Kk KK K K End of I2C Verification Suite Report K K Kk K Kk K k K K KK Kk KK K K K K FO KKK k K Kk Kk k K k Kk K Kk KK k K References 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 NXP Semiconductors C bus specification and user manual June 2007 Version 3 0 Available online at http ics nxp com support documents i2c pdf i2c bus specification pdf Christian B Spear SystemVerilog for Verification A Guide to Learning the Testbench Language Features Springer Second edition 2008 David C Brock Understanding Moore s Law 2006 Available online at http www chemheritage org pubs moores law Moore Chap Front pdf Archive Builders Moore s law 1999 Available online at http www archivebuilders com pdf 22017v005 pdf NXP Semiconductors Introduction to using 2C Available online at http ics nxp com support i2c usage Embedded Systems Academy 12C Inter Integrated Circuit Bus Technical Overview Available online at http www esacademy com en library technical articles and documents miscellaneous i2c bus html Philips Semiconductors J2C bus specification version 2 1 2000 Available online at http www nxp com acrobat __ download literature 9398 39340011 pdf Planet Analog The C Bus 2010 Available online at http www planetanalog co
41. K k BRR HEHEHE DRE ROKK ROKR RR DR EEEE EEE KK OR KK ROKK K k K k k k k k k k k kk kk k Kk Kk k kk Kk k k k K k K k K K K K K K k OH OH KK KK k k Kk KK k KK K K K K FG OH K K Kk KK k K k K K k Kk K Kk KK K K kok okokokokokokokokokokokokokokokokokokokokokokok Communication nr kokokokokokokokokokokokokokokookokokokokokokokokokokokok FRC KK KK KK k k KK kk k KK K K K K FG OH K K Kk KK k K k K K K Kk K Kk KK K K skok KKK KKK ROKR okokokookokokokokookokokookokokokok E E DR E ORK KR k k k k k k k k k K k k k kk RK k Kk Kk k kk Kk k k k K k K k K K K K K EEE EHEHEHE SEDE okeok EEEE EE E EEEE EE IG EEE I EE E E E AR K k k kk kK k k Kk K kk k K K kkk K K K kk K K K KK 2k RR k k k k k k k kkk kkk 1 Transfer Byte nr l kkkkkkkkkkokokokokokokokokokok k skok okokokokokokokokookookokokok okokokookokookokokookokokookookokokok E E E E E E E E E K E K k okokok k k k k k k kk kk k Kk kkk kk Kk k k k K k Kk K K K K k I2C Specification Standard OK 15 00us T_HD_STA with 4 00us OK 20 00us TLOW with 5 00us OK 25 00us T_HIGH with 5 00us 97 98 OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK FAIL 105 00us OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK OK 25 00us 30 00us 35 00us 35 00us 40 00us 45
42. PC Inter Integrated Circuit 7 Each device has a unigue 7 bit address representing a total 128 devices However 8 of those addresses are reserved by the PC bus protocol The 7 bit address are expandable to 10 bit This protocol was designed for low power communications which comprises byte oriented transactions Both SDA and SCL are open drain lines Vdd Figure 2 2 Multi master architecture To perform data transfers the ZC bus protocol has several conditions that must be met This conditions allow the communications between the devices hooked up to the bus for example to start and ends data transfers or to avoid data loss In the next lines these conditions are described in order to lead to a better understanding of how the C bus protocol works Figure 2 3 represents a possible data transfer It starts with the START condition and then sends the address of the device it wishes to communicate with After receive the acknowledge ment signal from the device addressed the master device starts sending data After each byte transferred the slave device perform an acknowledge signal to inform the master that the byte was well received When the master sends the last byte after received the acknowledge signal it performs the STOP condition to inform the slave that the communication is over After the STOP condition the I C bus is free to allow data transfers between the devices connected to it 7 Bit Ca 8 Bit 8 Bit ACK SDA
43. SystemVerilog Golden Reference Guide A concise guide to SystemVerilog IEEE Std 18007M 2005 Doulos Fourth edition 2006
44. Verification Methodology Manual VMM for SystemVerilog The DesignWare Verification IP supports the following Platforms Simulators and Testbench Languages Platforms Solaris SUSE Linux Simulators VCS NC Sim ModelSim Testbench Languages systemVerilog OpenVera Verilog VHDL 20 State of the Art 2 3 2 eInfochips C Verification Component The C Verification Component from eInfochips is a component with the aim of verifying the PC bus protocol 19 The component topology is shown in figure 2 16 Transactor 12C Configuration Master I2C Bus Register Slave Interface Both SlaveMemory Monitor amp Protocol Checker SVA Figure 2 16 eInfochips I2C Verification Component Topology 19 This component is compatible with version 2 1 of C Bus Specification protocol but only sup ports the standard and fast speed operations In addition it allows the configuration of a number of parameters to set clock synchronization and the generation of the Serial Clock Line SCL Has even a set of parameters to configure verification process such as the slave address and transfer abort in case of error It allows to configure SCL s period and its duty cycle as well as data FIFO depths and command retries The testbench can be triggered in case of significant events through the use of notifications Represented in figure 2 16 are two main conceptual components They
45. and a START Minimal time for Low period of SCL Minimal time for High period of SCL Minimal data hold time Minimal time for data set up Minimal time for valid data Slave address Data sent from Master to Slave Data sent from Slave to Master Clock Frequency A 3 How to Start the Verification Process 91 A 3 How to Start the Verification Process After the instantiation of all the devices you want to verify and after the configuration of the verification process is now time to start the verification To perform this run the run script in the command line You can find this command in i2c_verification verification_suite I vO tool_data ncsim When the verification process finishes you are able to see the global verification report printed in the command line as represented in figure A 1 Figure A 1 Global verification report You can also see in the command line the final report of each verification before the global reportis printed Figure A 2 represents the the final individual report of one verification performed Figure A 2 Single report for each verification After performing all the verifications described in the global parameters conf file the 77C Verification Suite creates a folder named with the local date and current time Inside this folder you have another folder named with the address of the device s you select to verify This folder contains the verification report of your device as w
46. arameter Sm Fm Emt Hs mode Unit y Min Max Min Max Min Max Min Max T Low Low period of SCL 47 1 3 0 5 0 16 us signal Table 3 6 Minimum time for the LOW period of SCL signal 3 3 2 SCL HIGH period Unlike the SCL LOW period the SCL HIGH period is defined as the time while SCL line is in a HIGH state from the raising edge until the falling edge of SCL signal The minimum time in which the signal can be 1 is defined in table 3 7 As in the SCL LOW period the C bus specification protocol do not specify any value for the maximum time However the SCL operating frequency will decrease with the increase of this value Figure 3 8 shows how the SCL HIGH period is measured 42 Verification of PC Devices 70 96 SDA 30 96 HIGH 70 96 SCL 30 Figure 3 8 HIGH period of SCL signal 1 Symbol Parameter Sm Fm Fm Hs mode Unit ze SES Min Max Min Max Min Max Min Max HIGH period of T_HIGH sor signal 4 0 0 6 026 0 06 us Table 3 7 Minimum time for the HIGH period of SCL signal 3 3 3 Operating frequency The operating frequency defines the speed of the transfers and is determined by the SCL LOW and HIGH periods It is measured from the falling edge to the raising edge of the SCL signal as represented in figure 3 9 Table 3 8 describes all the allowed operating frequencies for all speed modes 70 70 SCL 30 30
47. are the monitor and the transactor The monitor provides the SystemVerilog assertions SVA interface using the bus monitor which contains two elements the protocol checker and the SystemVerilog assertions These two elements can be plugged in or out and the verification component functionalities will not be affected The transactor emulates the 72C agent which generates and drives data on the bus It also provides the functional coverage to transactor component Composing the transactor there is the element master and slave 2 3 Other Verification platforms 21 FEATURES In addition to the above this platform presents some important features such as e Operate as a master slave e Supports General Call address e Possibility to address slaves with 7 or 10 bits e Supports standard and fast speed modes Controllable bus transactions generation e Supports error injection e Contains scoreboard feature to check data integrity e Capability to detect and notify errors such as Invalid slave Address Invalid Data Give Acknowledge Error Create Collision Invalid start e SystemVerilog Assertion at interface e Directed random test generation e HDL independent 2 State of the Art 2 3 3 hdl Design House HVC 800 SV 7 C HVC 800 SV is an C protocol monitor and checker based in System Verilog assertions de signed by hdl Design House 20 Figure 2 17 shows how HVC 800 SV component is used in a testbench HVC
48. as a counting semaphore e Use of Object Oriented Programing OOP e Use of Interfaces This construct makes the communication between modules and classes easier to describe and also facilitates the design re use e Constrained random generation This feature allows the creation of random scenarios for verification e Assertions Properties and Sequences The SystemVerilog assertions are used to verify characteristics of a design It comprises properties and sequences 16 In addition SystemVerilog HDVL brings several advantages for those which use it Has a IEEE standard it ensures a wide embracing and supported by multiple vendors of EDA tools and verification of Integrated Properties IP as well as interoperability between different tools and vendors SystemVerilog was adopted as a standard by Accellera organization and was approved by the Institute of Electrical and Electronics Engineers IEEE on November 9 2005 This ensures a comprehensive range and also supported by multiple vendors of Electronic design automation EDA tools and verification platforms as well as interoperability between different tools and ven dors 17 SystemVerilog is an extension of the Verilog language This leads the adoption process of SystemVerilog by engineers is extremely easy and simple making the risks and costs of this adoption low Being an integrated part of the simulation process systemVerilog eliminates the need of external v
49. aster can initiates a transfer and send data to a slave In this case the direction of the transfer data direction bit does not change The transfer is performed as shown in figure 2 10 Another transfer format occur after the master sends the slave address with the data direction bit set in READ mode it starts reading the slave immediately After this byte the slave sends a ACK and then starts sending data to the master At this point the master becomes the receiver and the slave becomes a transmitter and all the ACK from now are generated by the master every 8 bits received when data transfer ends the master sends a NACK and then the STOP condition figure 2 11 Is also possible have both these transfer formats without the need of generating a STOP con dition This transfer format is called combined format and is represented if figure 2 12 s saves re on A n bytes read or write ack n bytes read or write direction of transfer may change at this point Sr repeated START condition Figure 2 12 Example of a combined format 8 12 State of the Art The combined format occurs when the master change the data direction within a transfer In this case the START condition and the slave address are both repeated however the data direction bit figure 2 9 is inverted To generates a repeated START condition the master first generates a NACK and then the repeated START condition In figure 2 3 is
50. ated addressing and data transfer protocol allow system to be completely software dependent Don t reguire device drivers plug and play Low power consumption However and like everything in integrated circuits communication there are some limitations in the use of the C bus Some of them are 1 9 10 Different devices from different manufacturers come with hard coded slave address or ad dress will be configurable in a small range only This can lead to address clashes sometimes No automatic bus configuration or plug and play Get reflections at especially at high speeds To avoid this use dynamic resistor or current source Ghost signals may disturb transmission and corrupt the data Long lines present capacitive load No time outs in standard mode 16 State of the Art 2 20 IEEE 1800 System Verilog IEEE 1800 SystemVerilog is the industry s first unified Hardware Description and Verifica tion Language HDVL standard 11 System Verilog language is an extension of the established IEEE 1364 Verilog Language and initially developed by Accellera in 2002 In 2005 System Verilog was accepted as IEEE 1800 2005 standard 12 and in 2007 some upgrades were made creating the IEEE 1800 2007 13 Finally in 2009 this standard was merged with the IEEE 1364 2005 Verilog Language generating the IEEE standard 1800 2009 the actual version 14 System Verilog is used to simulate and verify the functionality of digital electronic ci
51. ation Report compact version Final Verification Report detailed version General call Verification Report compact version O O w General call Verification Report detailed version References CONTENTS 79 P S eee ave 79 P 80 a 81 n dd at ee Bog 84 85 TE 85 a 86 P 86 87 ba ka dmg 87 o 88 m 91 93 95 97 103 105 109 List of Figures 2 1 2 2 2 3 2 4 25 2 6 2 2 8 2 9 2 10 2 11 2 12 2 13 2 14 2 15 2 16 2 17 2 18 2 19 2 20 2 21 2 22 2 23 2 24 2 25 3 1 32 3 3 34 35 3 6 3 7 3 8 3 9 3 10 3 11 3 12 master slave architecture ooo 6 Multi master architecture es 7 A complete data transfer on the 7C bus lt lt lt lt lt lt lt lt J START Condition o s e soe ala eo xoc a a aa ee a 8 STOP Condition 4 sa 68 ee em e ee ee ee 8 ACK signal 52 224 Rage q bi x a DEN es Saree Me ba aii 9 NACK signal aec a REUS oS RS v RU koky hae ak ee bk k cb l dn 9 Example of a data transfer on the C bus lt lt lt lt lt lt lt lt 9 The slave address plus the data direction bit len 10 Example of a WRITE operation lt lt lt lt lt 444 10 Example of a READ operation lt lt lt lt 44 4 4 eee eee 11 Example of a combined format lt lt lt lt lt 4 4 eee 1 Data valid P Mc 12 System Verilog extensions i 16 DesignWare I2C Verification IP Topology lt 4 18 eInfochips I
52. ation for the hold time of the START condition If the time gap is greater of the one specified by the protocol the verification of the START condition pass Once again if the device performs an illegal transition the FSM transits to END state to stop the verification For every valid transition occurred in the bus the Verify Specs FSM saves the the simulation time of that transition This state machine has 4 registers to record the time of the transitions occurred in both SCL and SDA lines These registers are used as described in table 4 3 These times are needed to check the time specifications of the C bus As described before this checks are performed in 2 steps The first is to calculate the time gap between two transitions The next step is to compare the time gap calculated with the specification time the transition event occurred 4 2 Structure Adopted 71 Transition FC Bus Line FSM Register Definition Oto 1 SCL scl low time Time of SCL transition from 1 to 0 Ito 0 SCL scl high time Time of SCL transition from 0 to 1 0 to 1 SDA sda_low_time Time of SDA transition from to 0 1 to 0 SDA sda high time Time of SDA transition from 0 to I Table 4 3 FSM registers used to record transitions time After the verification of the hold time of the START condition the verify specs FSM transits to the S LOW state save the time of the SCL transition from 1 to 0 and waits for the next transitio
53. ator class waits until the master slave BFM reguest for a new byte When a new byte is reguested the data generator pro duces a new byte and send it to the master BFM In the second step the process is similar After the slave transmits the 8 h the master BFM requests a new byte for the slave device Both these processes are repeated as many times as the user define in the N COMM and inthe N BYTES parameters When the verification platform verifies the general call address only a write operation is per formed In this case the data is generated in the same way as in the first step of the verification process of a slave device In the figure 4 5 is represented the interactions between the data gener ator the master slave BFM the scoreboard with the devices plugged in the C bus Devices PC Verification Suite New byte reguest New byte generated m for BEM am for devices New byte reguest for New byte generated devices for BEM Figure 4 5 Data generator interactions during a verification of a C slave device 4 2 Structure Adopted 63 The data generator class when sending the generated data to the master slave BFM or for the PC devices connected to the bus also sends using the systemVerilog mailbox the generated data to the scoreboard to verify if the data transmitted received and generated are all the same 4 2 5 Master slave BFM The C verification platform performs data transfers in the C bus to verify C de
54. bed and explained all the IC time specifications needed to verify and validate the designed C circuit Table 3 12 summarizes all the time specifications described here Besides the time specifications are also described other specifications related to the data trans ferred between master and slave devices and also with the transfers itself such as the invalid ACK NACK invalid state and device address integrity Sm Fm Fm Hs mode Symbol Sorameter Min Max Min Max Min Max Min Max Unit Hold time repeated T_HD_STA START condition 4 0 0 6 0 26 0 16 us Set up time for repeated T SU STA START condition 4 7 0 6 0 26 0 16 us DESEE PU valid acknowl 345 po gas o 007 us edge time TSU STO SP time for STOP 06 loz Jone us condition Bus free time between eso AIE V ON anda STARTE a 13 05 E E E us condition T LOW s period of SCL sig 47 13 05 016 us me EOE p o Se O o e laal lawl us signal F SCL SCL clock frequency 0 100 0 400 0 1000 0 3400 kHz T HD DAT Data hold time 0 3 3 45 03 0 9 0 3 0 9 0 0 07 us T SU DAT Data set up time 250 100 50 10 ns T VD DAT Data set up time 250 100 50 10 ns Table 3 12 Time specifications for data transfer on 7 2C bus 1 These specifications guarantee a good performance and a good communication between the designed circuit s and other circui
55. cribed above it is now connected to the C bus A 2 Verification Process Configuration After all the devices are instantiated you need to configure the verification process To do this first open the global parameters conf file which is inside the ncsim folder in i2c verification verification suite 1v0 tool_data ncsim Then you need to configure all the parameters described below 1 The slave address SLAVE ADDR is the address of the device you want to verify NOTE If general call address is used you must specify how many devices are connected to the bus in BUS DEVICES parameter otherwise you can ignore this paremeter 2 Input the SCL clock Frequency SCL FREQ you want to verify 2 1 0 gt 100 KHz 2 2 1 gt 400 KHz 2 3 2 gt 1000 KHz 2 4 3 gt 3400 KHz 3 Choose the data input method INPUT METHOD A 2 Verification Process Configuration 89 3 1 Exhaustive simulation The system runs the simulations with all possible data values 256 3 2 Random simulation The system generates random data values 3 3 File simulation NOTE For method I use N COMN parameter to choose how many communications want to test 4 Choose how many bytes you want to send in each communication N BYTES NOTE For more than 1 byte is the bytes are transferred in burst mode 5 DISPLAY REPORT 5 1 0 gt Show the result 5 2 1 gt Show the result and the file report in the terminal 6 REPORT TYPE 6 1 O gt Compact repo
56. d a brief conclusions about all the work done in this dissertation iii iv Agradecimentos Em primeiro lugar gostaria de come ar por agradecer ao Professor Dr Jos Carlos dos San tos Alves por ter aceite o meu convite para ser orientador deste projecto Ao Eng Pedro Faria de Oliveira por me ter proporcionado a oportunidade de realizar este projecto num ambiente em presarial Gostaria ainda de agradecer a ambos por todo o apoio demonstrado e pela confian a depositada em mim Gostaria tamb m de agradecer aos meus colegas Diogo Melo e Ricardo Pereira Carvalhido aos restantes utilizadores da sala 1224 e aos Engenheiros Eduardo Sousa e Jo o Gon alves pelo apoio e disponibilidade que sempre demonstraram desde o in cio deste trabalho Quero tamb m agradecer minha namorada Alice e aos seus pais que apesar de me encontrar t o longe de casa sempre me proporcionaram um excelente ambiente familiar Finalmente e mais importante que tudo quero deixar um especial agradecimento ao meu Pai pelo incentivo minha M e pelo apoio e a ambos pelo enorme carinho que nunca me faltou A todos o meu muito obrigado Miguel Caetano vi vii Ao meu Pai minha M e e Alice viii Contents Introduction 1 1 Motivation aces regy ea roeien ea e a ea ER ep 12 ODCCUVES x eiee Be A en qo Ju a kom A ED dk ee Be Ae 1 3 Thesis Stricture e ss ee ssec k ee q m RO ok a ew 9o bokov a State of the Art 2 1 PC Inter I
57. d in the C bus which is collected and sent the scoreboard class by the data transfer FSM The data transfer FSM has the same structure with the same states and sensitive list as the state machine described in figure 4 11 The only difference is that this FSM only collects the data that is transferred in the C bus The only reason why two identical state machines were develop is because the verify specs FSM become a bit long and also and a bit complex This FSM also collect the bits transferred when a master device is sending the slave address This byte is then compared with the slave address defined by the user in the configuration process to verify the integrity of the address transferred This is useful because if the addressed slave is not acknowledge the slave address sent the user is able to detect if the problem is on from the slave or from the master If this verification fails the verification platform is able to end the current verification process or not It depends on the configuration made by user 4 2 9 Report Generator A verification process is not complete without a final report This final report should be simple and obvious in order to allow the user to know if the designed circuit accomplish its functions successfully or if not in which situations does it fails To provide such report the C Verification Suite incorporates a class called report generator used to generate the final report The PC Verification Suit
58. d of tools are too expensive Despite the IC being a relatively simple protocol of communication there are some flaws that may occur These flaws if not detected on time may compromise the performance of the designed circuit These failures also contribute to increase the cost of the project This dissertation presents the development and implementation of a verification platform for the 72C communication protocol This project was developed with the collaboration of Silicon Gate Lda First will be presented and compared different solutions that already exists in the market which verify this protocol Then will be described and explained the specifications for the PC communication protocol that are going to be checked by the developed platform After this description the developed platform will be presented and explained in detail showing its relationship with Hardware Verifi cation and Description Language HVDL as well as the characteristics and particularities of this solution Thereafter there will be a demonstration of some functionalities of the developed platform connecting one C device to the C bus in order to perform a set of verifications in order to validate the circuit under test and also to evaluate the effectiveness of the IC Verification Suite It also describes the reports generated by the platform which enables the user to see if any of the specifications mentioned earlier were or not violated Finally are presente
59. date a design that performs his task based in the specification finding potential bugs or discrepancies This is also the same ob jective of this dissertation The analysis made in this chapter describes the architecture elements functionality and characteristics of different solutions commercially available The solutions studied all support the C bus specification protocol v2 1 with the exception of SmartDV C VIP component which also supports the v3 0 of the C bus communication pro tocol Lower versions also exists along with dedicated platforms for them but in this dissertation only 2 1 and above were chosen to be studied because they are the most recent and effective Table 2 1 compares the main features of all the platforms studied and described in this chapter Platform JC Bus IC Bus Slave General Master slave Multi Error Data Protocol Speeds Address Cal operation master Injection Check Synopsys v2 1 Sm Fm 7 10 bits Yes master slave Yes Hs elnfochips v2 1 Sm Fm 7 10 bits Yes master slave Yes Yes hdl design v2 1 Yes nSys v2 1 Sm Fm 7 10 bits master slave Yes Yes Hs SmartDV v2 1 Sm Fm 7 10 bits Yes master slave Yes Yes v3 0 Fm Hs Cadence master slave Yes Yes Table 2 1 Comparative table of the different platforms studied The main goal of the platform developed during this dissertation has the same objective of t
60. ddress slaves with 7 or 10 bits e Has the possibility of configure the slave as Generic C slave device PC EEPROM slave e Checks the transferred data in case of I C EEPROM slave The nVS Verification suite supports Verilog and System Verilog hardware languages 26 State of the Art 2 3 5 SmartDV 2C VIP The 72C VIP is a verification IP designed by SmartDV to verify the Philip s 2C communica tion protocol 22 This platform is shown below in figure 2 19 12C DUT Figure 2 19 SmartDV VIP for PC 23 The SmartDV VIP for PC is fully compliant with versions 2 1 and 3 0 of the Philip s 2C Bus Specification It supports standard fast and high speed operations The model has a rich set of configuration parameters to set clock synchronization and generation of the Serial Clock Line SCL to meet all clocking requirements This platform can operate as a master or as a slave As a master the model can Start Stop all possible transfers In addition as a slave device it can detect Start Stop conditions and perform data transfers according to the initiator reguest The topology used in this suite is presented in figure 2 20 The SmartDV s PC Verification environment contains a BFM master and a BFM slave and also a monitor This environment is capable of a complete a regression suite containing all the testcases for the C verification This suite is supported for VMM AVM Reference Verifica tion Methodology RVM
61. e ACK the START condition Invalid START Invalid data transfer Generates a final report detailed or compact Is able to print the final report in the comand line Generates and drives bus traffic as a C master device Direct random data generation 4 4 Summary TI As benefits the IC Verification Suite provides the user an easy way to instantiate the device or devices to verify has a simple configuration file which allows the user to specify the verifica tion process and also specify more than one verification The user are able to specify an unlimited number of verifications to perform The verification platform offers not only a the final report described above but also a global verification report which gives the number of failures during each verification 4 4 Summary With the arrival of SystemVerilog new features could now be used In this thesis three of them were studied and implemented in great detail These are the Object Oriented Programming the Interface and the mailbox constructs The Object Oriented Programming allow testbenches and system level models to be designed at a more abstract level by calling routines to operate the data instead of toggling bits This also disassociates the testbench from the design making it more robust and easier to maintain The System Verilog mailbox enables the inter process communication between two threads as explained in subsection 4 2 2 A mailbox operates lik
62. e S ACK state when the counter is egual to 9 and also to decides when performing the T VD ACK verification as described in table 4 4 and in figure 4 11 It is also used to by the Data transfer FSM When the 9 SCL clock pulse arrives the FSM sends the byte collected from the C bus to the scoreboard class The structure of the SCL counter is based in a finite state machine composed by 4 states Fig ure 4 12 describes the transitions that can occur in this FSM Every time the SCL line transits from 0 to l the state machine increment the SCL CNT register When reaches 9 times which is when the SCL acknowledge pulse is performed the FSM reset the register and restart the same process SDA 0 SCL 0 Figure 4 12 Finite State Machine FSM used to counter the SCL clock pulses e Data Transfer FSM The C Verification Suite verifies the I2C bus specification protocol and also the data integrity which comprises the data and the slave address The verify specs FSM as explained before veri fies the specifications of the 2 wire bi directional bus whereas the scoreboard class check the data integrity The data integrity is verified by comparing the byte to be sent with the byte transferred in the bus and with the byte received As explained in subsections 4 2 7 and 4 2 6 the receiver class 74 The PC Verification Suite puts the received data into the mailbox for the scoreboard picks up and compares it with the data transferre
63. e a FIFO where one process can write data to the mailbox and the other process can read data from it about the System Verilog s Interface this are a new port type This port type helps the designer to group several ports together representing them as a single port and declare it in a single location as explained in subsection 4 2 1 This chapter has presented the developed C Verification Suite Next a detailed explanation of the developed platform was also done explaining all the blocks used in the verification platform describing how they were implemented and how they interact in the platform This chapter ends after describing the features and the benefits of this verification platform 78 The PC Verification Suite Chapter 5 Verification of C Slave Devices In this chapter the I2C Verification Suite will verify a IC Slave device It starts by describing the circuit under verification which is a C Slave device provided by SiliconGate It will also be explained all the necessary procedures to perform a verification Such procedures comprises the instantiation of the device s to be verified the configuration of the verification parameters and also the specification of the verification process Then a detailed analyses of the results of the verification will be performed 5 1 The IDC Slave The circuit under verification is a PC Slave device provided by SiliconGate This slave could be accessed by the address 000 1110 wh
64. e arrival of a new byte through the new byte x array every time it receives a byte giving the opportunity for the verification platform to captures the received data through the data out x array To perform this capture the receiver class courses the new byte x array looking for the new byte notification after the device under verification acknowledge the byte received to see how many devices have received the byte transmitted and at the same time also courses the data out x array to capture the new byte The scan of the new byte x array is needed for the platform can see if the byte captured in the data out x array is is really new 4 2 Structure Adopted 65 After captures the data the receiver class sends it to the scoreboard through a mailbox con struct for data integrity check In figure 4 6 is described how the receiver class capture the byte received in the device under verification during a write mode data transfer and also represents both arrays of the interface used to capture the data received in the DUTs SDA Data received in the 12C devices e New byte notification Data written in the mailbox Data removed from the mailbox Figure 4 6 Data capture during a write data transfer or a general call After transmit all the bytes requested by the user the platform will then perform reading operations from the DUT In this case the data previously generated in data generator class will be transferred throu
65. e comprises two types of reports One is generated after each simu lation called the individual report and the other only reports the result at the end of the entire verification process called the general report For the individual report before the verification process starts the report generator class is configured in the configuration process as described in subsection 4 2 3 The report generator class is configured with the type of verification that the platform will perform Verification Type and also if is a general call verification or a normal verification This is defined by the SLAVE ADDR parameter defined by the user and must ex ists because in a general call verification the platform only performs writing operations instead of writing and reading operations as in the normal verification The user is also able to define the report type which could be a detailed or compact The only difference is that the detailed report log all the events occurred in the PC bus while the compat report only logs the occurred errors During the verification process this class receives notifications reporting new results from the bus analyzer module or the scoreboard class Then the report generator reads the results and prints them to the report When verifying the device with writing transfers the report generator receives notifications by the scoreboard after this compares the received byte with the transmitted and also with the gen
66. e configuration parameters are used to define which devices are going to be tested and how are they going to be tested The user also defines the type of veri fication to perform and also what type of report does he want detailed or compact For the C Verification Suite verify a slave device or a master receiver device the user has to define the values of the high and low periods of the SCL signal for the master BFM performs the clock signal 60 The PC Verification Suite Since the C Verification Suite supports all the speed modes described in the 72C specification protocol the user has to define which speed mode want to verify Next are described all the parameters for the user configures the verification process SLAVE_ADDR This parameters is for the user specify the device address of the device under verification plugged to the C bus This could be a master or a slave device address For general call verifications the value of SLAVE_ADDR has to be 000 0000 BUS DEVICES The BUS DEVICES parameters is for the user specify how many devices are plugged in the PC bus system This parameter is used to know how many receiver devices could be masters or slaves receive data in a normal transfer or if a general call address is used SCL FREQ This parameter is for the user specify which bus speed want to verify The C Verification suite supports all the bus speed of the C bus specification
67. ell as the parameters you entered in 92 PC Verification Suite User Manual the global parameters conf which configure the verification for that device If you choose to verify more than one device the verification platform will create as many folders as the devices tested in the same verification process Figure A 3 represents the structure of the files saved by the verification platform o 6 2010 06 27 2010 06 27 08h27m41s 08h48m41s 22 This paranct paromat par anet par onet i2c testparamete i rs sv 0001110 o global verification Figure A 3 Structure of the report files After the verification process ends you should check the verification report created as ex plained above This report contains all the violations and errors occurred during the verification process Appendix B PC Verification Suite Configuration File Listing B 1 Interface declaration K K ok ok ok K K K CE OK K CE K CE OK K CE K CE OK K CE K CE OK K CE K CE DE CE CE K CE K CE CE K CE OK OK CE K CE OK K K K CE OK OK CE K CE OK K CE K OK K K OK K OK OK K OK K ok OK K OK K CE OK K CE K CE K K CE K CE DR CE CE K CE OK K CE K CE K CE CE K CE OK K CE K CE OK OK CE K CE OK K K K CE OK K K CE OK OK CE K OK OK K OK K OK OK SLAVE_ADDR BUS_DEVICES SCL_FREQ INPUT_METHOD N_COMN N_BYTES DISPLAY REPORT REPORT TYPE STOP ON ERROR VERIFICATION TYPE T HD STA T SU STA T VD ACK T SU STO T BUF T LOW T HIGH
68. erated byte Among with the notification the report generator also receives the result pass or 4 2 Structure Adopted 75 fail the byte transferred and the simulation time of the received byte From the side of the C bus specifications protocol the report generator receives the notifications every time the bus analyzer has any result of a performed verification From the bus analyzer the report generator receives besides the notifications the type of verification performed the result pass or fail the simulation time and also the result time used to compare with the specifications In case of the verification platform performs reading transfers from the DUT the whole process of the report generator is identical When verifying the general call address the C Verification Suite only performs writing trans fers For this verifications the report process is similar to the writing mode in the standard verifi cation The only difference is that when verifying the general call address the platform verifies if all the devices connected to the bus received the data transferred The bus analyzer and the report generator communicate using the already explained Sys temVerilog s interfaces as well as the scoreboard and the report generator The bus analyzer sends to the report generator a notification to inform the arrival of a new result It also sends the verification result time as well as the elapsed time and an array with 7 positions
69. erfaces used to allow the communication between all the modules and the classes as described later on in this section SDA FC Verification Suite Devices Figure 4 2 Top Module Between the platform and the C bus system bi directional communication pads are used as well as between the devices connected to the bus This pads are needed to perform a smooth data read or write from or to the SDA line Figure 4 3 explains how the platform is connected to the SDA line of the bi directional two wire bus To connect the SCL line or any other device to the PC bus system the structure is exactly the same 54 The PC Verification Suite The PAD is used to hold or release the SDA and SCL lines using the data direction port When a device is performing a read operation the PAD from the receiver device releases the SDA line and the SDA in out port becomes an input port and the data reaches the device by the Data received port If a write operation is performed the SDA in out port is now an output and the data is transferred using the Data to send port connected to the transmitter device In the SCL line the bi directional communication PAD is also used for the clock stretching The clock stretching pauses the data transfer by holding the SCL line at low state The transfer continues after the the SCL is released This is made by a slave device when it needs to perform some function before receiving more data SDA Data to send Figure
70. erification tools and interfaces 18 State of the Art 2 3 Other Verification platforms 2 3 1 Synopsys Verification IP for 7C The DesignWare Verification IP VIP for C is a platform designed by Synopsys that pro vides a way to verify the 72C bus protocol 18 The figure 2 15 shows how this model can interact as master slave or even both depending on the configuration set by the user This verification platform is compatible with version 2 1 of C Bus Specification Also sup ports standard fast and high speed operations Allow the user to configure the clock synchro nization and the generation of the Serial clock Line SCL As described before it can operates as a master slave or both and its role is capable to change dynamically according to the stimulus applied to the model without modifying any configuration parameters Operating as a master the platform can be used to Start or Stop any transfers Furthermore operating as a slave device the platform detects any possible Start or Stop conditions and perform the respective data transfers previously requested SDA SCL Model Clock CLK Object Interface Command Interface Object based Test bench HDL Test bench Features Input Output channels Callbacks Notifications Figure 2 15 DesignWare I2C Verification IP Topology 18 When operating as a master the following steps are taken First in each master is config
71. evels for both SDA and SCL lines 3 High speed mode HS mode With this speed mode the C devices are able to perform data transfers at a very high speed They can transfer information at bit rates up to 3 4 Mbit s Like in the other speed modes the devices here remain fully compatible with the remaining speed modes in the C bus system However in this mode the arbitration when using a multi master bus and the clock synchroniza tion are not performed during a data transfer The transfer format and the logic levels remains the same as in the Fast mode plus Fast mode and in Standard mode 14 State of the Art e General Call address The general call address is one of the reserved address of the C bus communication protocol This address is used to to address all devices plugged on the C bus After a master device sends the general call address a device is allowed to ignore the general call address by performing a NACK if it not need any of the data supplied within the general call On the other hand if a device reguire data from a general call it only has to ACK and behave as a receiver device During a general call address the master that performs it does not know how many devices are in the C bus or even how many devices acknowledged if any device performs the ACK The meaning of the general call address is defined by the second byte The following bytes will be acknowledged by each device connected to the C bus if
72. gh the 72C bus and received by the master slave BFM During this verification step the device under verification will transfer the same number of bytes transferred in the writing data transfer Each byte received in the master slave BFM class is transferred to the receiver class to be placed in the mailbox for the scoreboard for example when the platform performs writing data transfers Figure 4 7 describes how the receiver class captures the byte received in the master slave BFM class and placed it in the mailbox for the scoreboard during a read mode data transfer 66 The PC Verification Suite SDA n LN Devices PC Verification Suite New data arrived Data written in the signal mailbox Data removed from Data received the mailbox Figure 4 7 Data capture during a read data transfer When the verification platform verifies the general call address the process used to capture the data received in every device connected to the bus is similar to the explained above for the writing operation see figure 4 6 However in this case the receiver will scan the new_byte_x array looking for new byte notifications For each notification detected it will put the byte received in the device that produced the notification in the mailbox While that during the writing operation the scan of both arrays is used to check if only the addressed device has received the transmitted byte during verification of the general call this scan
73. h the byte acguired from the mailbox previously placed in the mailbox by the receiver class This byte is the byte received in the device that is being verified as was described earlier After transmits data to the device under verification the verification platform will receive data from the same DUT In this case the data generator provides the data not only for the device transmits to the platform but also to the scoreboard to verifies the integrity of the data transferred between the DUT and the platform The master slave BFM notifies the scoreboard that a new byte arrived from the device At this point the scoreboard is able to verify the integrity of the data transferred It picks up the data placed in the mailbox by the data generator and compares it with the data transferred in the bus Once again if the data integrity is verified the scoreboard will then verify the byte received in the bus functional model with the byte transferred in the bus Figure 4 8 describes from which classes the Scoreboard class receives bytes to compare New byte reguest for BEM New byte generated for BEM Byte transferred in the FC bus Byte generated Byte received PC Verification Suite Figure 4 8 The Scoreboard class interactions The scoreboard class also verifies the data integrity when a general call transfer is resquested by the user This verification is similar to the one explained above The scoreboard picks up the data placed in
74. he solutions studied above Having the same objective it is therefor enriching to this dissertation to have some characteristics presented in most if not all of the solutions studied such as e Compatible with version 3 0 of NXP s C bus specification protocol Operates at standard fast and high clocking speed e Two operating modes master slave Possibility to test different bus traffic for Read Write and General Call Use a simple effective and reusable verification environment Parameters to configure the verification process 34 State of the Art Random stimuli generation Scoreboard to check data integrity Error generation and injection into the stimulus Notifies the testbench if Wrong transaction occurs PC specification time is violated PC spceification protocol is violated Supports master slave arbitration and clock synchronization Is capable to generate and drive bus traffic as a PC master Is also capable to respond to transactions requests as a C slave Support multi master environment to check arbitration logic Generates START STOP and repeated START conditions Chapter 3 Verification of C Devices In order to provide a better understanding on what the C verification platform should verify this chapter describes in detail and based on the study done in chapter 2 all the conditions states and timings of the protocol that should be verified 3 1 Introd
75. hows the name type and argument list Table 4 1 Object Oriented Programing OOP terms and definitions 2 The environment class is instantiated in testcase program which passes all the interfaces as argument The verification environment contains the declarations of the virtual interfaces all the interfaces in the environment class are declared as virtual Virtual Interfaces are variables that represent different interfaces instances at different times during the verification process They are handlers like pointers in C A declared virtual interface only creates a handler to the real inter face does not create a real interface This is useful because it allows a class to operate on signals in different interfaces 28 In the environment class of the I C Verification Suite are instantiated all the methods used to control the verification process They are defined as follows x new This method is called the constructor It is used to connect the virtual interfaces declared in the environment class with those passed by the testcase program as argument x build The build method is used to construct all the objects used in the C Verification Suite such as Data generator 58 The PC Verification Suite Master slave BFM Receiver Scoreboard Report generator Beyond the objects this method also constructs the two mailboxes used for the communi cations between the data generator and the sc
76. ich could be modified This slave device supports the gen eral call address and is fully compliant with the NXP s bi directional 2 wire bus protocol version 3 0 SDA SCL New byte flag Data out byte received Data in byte to be sent Devices Figure 5 1 C Slave device properly connected to the bus 79 80 Verification of PC Slave Devices As represented in figure 5 1 this device has 2 inout ports for SCL and SDA lines two 8 bit port one for the data received from the bus data out and the other to receive the data to transmit to the bus data in It also has a one bit port which notifies the arrival of a new byte To be able to perform data transfers the I2C Slave must be connected to a bi directional pad as explained in subsection 4 2 1 After the device is connected to the bus is now time to configure the verification Note that the user can connect in the C bus a maximum of 120 devices 7 bit addressing 5 2 Verification Setup and Run Before starting the verification the user must configure the platform as explained in sub section 4 2 3 For this demonstration the C Verification Suite will verify all the specifications described in chapter 3 as an example the platform will perform 3 communications of 5 bytes each Then the platform will perform the same verification but now during a general call address with 2 devices in the 72C bus The configuration file to verify a
77. id device address lt lt 222 00000000004 3 5 2 Data from master to slave i 1x U NN F 3 5 3 Data from slave to master 3 6 Invalid datatransfer 0 2 002004 3 6 1 Ilegal format lt lt 3 6 2 Invalid ACK NACK 3 63 Invalid state a 3 7 Summ ry sucedem ed p kv RUE o e 4 The C Verification Suite 4 1 Overview sere reseca a ee 4 2 Structure Adopted i 4 2 1 TopModule ccccclc 4 2 2 Environment cle 42 3 CONE 4 2 sas a k E a maes 4 2 4 Data Generator 4 25 Master slave BFM 42 6 RECEIVED ae s ga ms ga EX Y X GUN 42 7 Scoreboard lle 4 2 8 Bus Analyzer i 4 2 9 Report Generator 4 3 Features and Benefits 4 4 Summary 22 5 Verification of 72C Slave Devices 51 TheDC Slave lt 444 oom Room omo a aa 5 2 Verification SetupandRun 5 3 Verification Results ess 54 Summary 22222224299 954 9734 xd ws 6 Conclusion 6 1 Conclusion 7 4 6 2 Prospective Work lt lt lt 0000005 6 3 Final Considerations A PC Verification Suite User Manual A l How Connect I C Devices A 2 Verification Process Configuration A 3 How to Start the Verification Process PC Verification Suite Configuration File Final Verific
78. ieter Sm Fm Fm Hs mode Unit JDO SEN Min Max Min Max Min Max Min Max d T_HD_DAT Data hold time 0 3 3 45 0 3 0 9 0 3 0 9 0 0 07 us Table 3 9 Data hold time specification for all speed modes 44 Verification of PC Devices 3 4 2 Data set up time Before the raising edge of the SCL signal the SDA line must be stable with the data to trans fer The elapsed time between the instant where SDA line changes state and the raising edge of the SCL signal defines the data set up time specification The figure 3 11 describes the data set up time specification which is compleated with table 3 10 that specifies all the set up times for each PC bus speed mode tsu DAT 70 SDA 30 70 70 SCL 30 30 Figure 3 11 Data set up time during a transfer 1 Symbol Parameter Sm Em aa Hs mode Unit y Min Max Min Max Min Max Min Max T SU DAT Data set up time 250 100 50 10 ns Table 3 10 Data set up time specification for all speed modes 3 4 3 Data valid time The data valid time is defined as the time elapsed from the falling edge of the SCL LOW signal to the SDA to the change of the SDA state LOW or HIGH depending on which one is worse before the raising edge of the SCL line Figure 3 12 describes how this specification is verified and in table 3 11 are specified the data valid time for all bus speeds 3 5 Addre
79. ing the PC Verification Suite A 1 How Connect 2C Devices Since the PC Verification Suite is connected to the C bus it becomes necessary to connect the device or the devices that you want to verify to the C bus system before any verification process takes place To connect your device to the C bus go to the directory where the platform is installed i2c verification verification suite 1vO tool data ncsim and then inside the ncsim folder instanti ate your device in the devices sv file Your device should be instantiated as described below 1 Your device should be already connected to a bi directional PAD 2 For SDA and SCL signals you need to use 2 1 bus intf sda for SDA 2 2 bus intf scl for SCL 3 For the output byte and the new byte output bit use 87 88 PC Verification Suite User Manual 4 data out x slave address for output byte 5 new byte x slave address for new byte bit NOTE Change the slave address by the slave address in DECIMAL 6 The other signals remain the same as in the device Here is an example Listing A 1 Device instantiation i2c top dut dutl sda bus intf sda scl bus_intf scl rstz dut in intf rstz byte in bgen2device intf data to device byte out data out x 14 write write new byte new byte x 14 This is the file where you instantiate all of your devices After your device is instantiated as des
80. ing the information submitted during a data transferred these suite should be based on the 72C bus specification and user manual to ensure that the PC Communication Protocol is not violated The work described here was develop with the collaboration of SiliconGate an Integrated Circuit design company The work took place at the Faculty of Engineering of University of Porto and at the proponent company SiliconGate 1 2 Objectives The objective of this dissertation is to develop a verification structure enabling a designer to improve the verification time and coverage using the recent System Verilog language and its ca pabilities 1 3 Thesis Structure 3 This suite will focus in the inter chip communication protocol 7C using the IEEE1800 System Verilog Hardware Verification and Description Language and should verify all the specifi cations of the C Bus Communication Protocol in order to validate the designs under verification The structure is comprised by a testbench a stimuli generator and a bus analyzer To enhance the design platform a master bus functional model BFM will set a C bus protocol with a slave device which will be verified by the platform 1 3 Thesis Structure Beyond the introduction chapter this dissertation has five more chapters So this dissertation in chapter 2 starts with a detailed description of the State of the Art This chapter comprises the technologies used to develop this dissertation a
81. ion time 402 00us ok KK ok KK ok okokookeookokeokoskokeokookokeokeok koe koe okoskeokeokokeokokokokokokeskokokeokokokekoxkokekookookokoskokokokokokek oko xkokokekoxkekekokoekokokeekokeekekekekbekekek skok GC KK KKK RK OK KKK KOK RK KKK RR KR k kK k k k k k k KK ORK k Kk Kk Kk k Kk k k k k k K k KK K K K K K KK KK KK k K k K K KK Kk KK K K K K SK KK k K Kk Kk k K k KK K Kk KK K K End of I2C Verification Suite Report K K Kk KK k K k K K k K KK KK K K K K E KK K k K Kk Kk k K k Kk K KK KK K K Appendix D Final Verification Report detailed version Listing D 1 Interface declaration skok okokokok KK KK KK RK K K k Kk K Kk KK k K EEEE E KK K k Kk k K k K K k Kk K Kk KK k K I2C Verification Suite Report EEEE OH SH OH K KK KK kk K K K Kk K Kk KK K K FOGG OH OH OH K Kk KK k K k K K K Kk K Kk KK K K kokokokokokok KKK sek RR DR EEEE ERR EEE DR E KKK E E E K k K k k k k k k k KKK kk k Kk Kk k kk Kk k kk K k K k K K k K k kokokokokokokokokokokokokokokokokokok K K K KK KKK K K k kokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokok K SR K KK K KK KK K KK K FKK oak 2k K ok ok 2k KK ok 2k K WRITE MODE FOK 2K 2 K KK K KK K KK ke FKK K FKK FK FKK FK KK FK K K KK K K k kokokokokokokokokokokokokokokokokokokokokokokokokokokokok K K kokokokokokokokokokok K k k k eee 3K K 3K KK KK K 3K K K K 3K KKK KKK RR EEEE EEEE OK KOK KKK E E E RK E K E K k k k k k k k k kk k k k kk kkk kk Kk k k k K k K k K K k
82. ions if a detailed report type was chosen otherwise only the platform only records the errors occurred When this process finishes the verification platform prints in the command line a report with the result of the verification process This report only has the number of errors occurred during the verification of each device In this case only one device was verified so only one device appears in this report as represented in figure 5 2 This report is called the global report Besides this report the platform also prints the final report of each verification before the global report is printed called individual report This report has the total errors and also what type of errors occured data transfer errors or I2C specification protocol errors Figure 5 3 represents the final individual report of the verification performed to the slave device under verification 82 Verification of PC Slave Devices Figure 5 2 Global verification report Figure 5 3 Single report for each verification If errors occurs both reports inform the user However only the single report describes which are the errors The global report only informs the total number of errors In figure 5 4 is repre sented the individual report of the same device which fails in some verifications Figure 5 4 Single report for each verification with errors 5 3 Verification Results 83 Every time a general call address is verified the individual report
83. ith 5 00us F SCL with 100 000000 TLOW with 5 00us T HIGH with 5 00us F SCL with 100 000000 T HD DAT minimal time FAIL with 0 00us TSU DAT with 5 00us TLOW with 5 00us T HIGH with 5 00us F SCL with 100 000000 T HD DAT with 0 30us TSU DAT with 4 70us TLOW with 5 00us T HIGH with 5 00us E SCL with 100 000000 T HD DAT with 0 30us TSU DAT with 4 70us TLOW with 5 00us T HIGH with 5 00us E SCL with 100 000000 TLOW with 5 00us T HIGH with 5 00us FE SCL with 100 000000 TLOW with 5 00us T HIGH with 5 00us FE SCL with 100 000000 TLOW with 5 00us T HIGH with 5 00us E SCL with 100 000000 TLOW with 5 00us General call Verification Report detailed version kHz kHz kHz kHz kHz kHz kHz kHz kHz kHz kHz kHz kHz kHz General call Verification Report detailed version 107 OK 175 00us T HIGH with 5 00us OK 175 00us F SCL with 100 000000 kHz OK 180 00us TLOW with 5 00us OK 185 00us T HIGH with 5 00us OK 185 00us F SCL with 100 000000 kHz OK 185 00us T VD ACK with 0 00us FAIL 185 00us T HD DAT minimal time FAIL with 0 00us OK 190 00us T LOW with 5 00us OK 195 00us T HIGH with 5 00us OK 195 00us F SCL with 100 000000 kHz OK 200 00us T LOW with 5 00us OK 204 00us T SU STO with 4 00us NC Data transfer OK 190 00us Data Received in device 3 match the data
84. ive table of the different platforms studied lt 33 Hold time specifications for START and repeated START condition 37 Set up time specifications for the repeated START condition 38 Data valid ACK time specifications lt lt lt lt lt 00200000004 39 STOP condition time specifications lt lt lt lt 4 40 STOP condition time specifications lt lt lt lt lt 00004 40 Minimum time for the LOW period of SCL signal 41 Minimum time for the HIGH period of SCL signal 42 Operating frequency for SCL Clock lt lt lt 43 Data hold time specification for all speed modes lt lt 43 Data set up time specification for all speed modes lt 44 Data valid time specification for all speed modes 45 Time specifications for data transfer on 7 2Cbus l A ad Sa k ECY E 49 Object Oriented Programing OOP terms and definitions 2 eT States and next valid states of the Verify Specs FSM 70 FSM registers used to record transitions time 71 Verifications performed per each state of the verify specs FSM T2 xiii XIV LIST OF TABLES Abbreviations ACK ATCA AVM BFM CMS DPI DUT DUV EDA EEPROM FSM FM FM FIFO HDVL HS mode PC IEEE IP IC IPMI LSB MSB NACK NXP OOP OVM PMBUS RVM RTL SCL SDA SM SMBUS SUSE TLM UVC
85. ived in the devices under verification The Receiver class provides to the verification platform a way to capture these data It receives the data from the devices under verification and also from the master slave bus functional model These data is then transferred to the scoreboard class to check its integrity using SystemVerilog s mailbox To receive data from the master slave BFM the receiver class use a system Verilog interface as well as to capture the bytes received in the device under verification The interface used to capture the bytes received in the devices connected to the bus is composed by 1 register of one bit One array named as data_out_x has 120 positions each one with 8 bits One array named as new byte x has 120 positions with one bit per position Each device plugged in the C bus is connected to the verification platform through the data_out_x and the new_byte_x arrays Each position of the arrays corresponds to a device con nected to the bus The array position is defined by the address of the device For example a slave whose address is 14 000_1110 has the data received output and the new byte output bit in the 14 position of each array data out x 14 and new byte x 14 respectively During the verification of a slave device as explained above the platform starts to transmit data to the DUT and then reguest a read operation to the slave device For each byte transmit ted the IC device notifies th
86. k Kk K k K K k Kk KK k KK KKK K K K FO k K KK kkk kokokokokokokok Final Result xxokokokokokokokokokokokokokokokookokokokokokokokokokokok k FR CCK KK KK KK SO SS O O KKK KK KK FRR CCK KKK kk K k k K k Kk K Kk KK KKK K K K ROK KK OK KK EE EEE RR DR EEEE EEE RR EE KKK RK E E E E ORK k k k k k K k Kk k kk kk k kk Kk Kk K K k K k xokokokek eo kkk KK ok KK ES Total errors y gt kokokokok kk ee kkk kk Rx ok Kk Verification FAIL kokokokok kkk kk kk kk kk 103 104 General call Verification Report compact version kokokokok Total Errors in Write Mode 2 ek KK KKK kk KK Kk k kokokokok I2C data transferred errors 0 gt kokokokok DEE EES I2C Specification Standard errors 2 KOK PEPEE ok KK ok KK ok KK dokokokok ok KK x Total simulation time 402 00us xxx kkk k xokekokek FOGG GGG GGG GOI IGG IG GI IGG IG I GK SII Ca ak ak a ak ak ak skok CCK KR KK RK RR DR RR DRE DRE OR KK KKK KK ER RK KK KR RK RR KK KK Ko aK kk kK kK FO skok kok ok k k A I AK AK FSSC ICICI AC aK ak ak ak ok End of I2C Verification Suite Report se ok ok ok ICICI A I A A ACK FICCI CGI ICI ok kok ak ak ak ok J Appendix F General call Verification Report detailed version Listing F 1 Interface declaration skok kok skok KK KKK KK KK kk KK k KK k K FG KKK KK KK k K k KK K Kk K Kk KK k K I2C Verification Suite Report EEEE E E K k KK k kk K K K Kk K Kk KK K K FG OH K K Kk KK k K k K K K Kk K Kk KK K K
87. l da BS dow Hoke e ROO ew 8 52 Top Module i gt a ucc ae wad GbR ba OS Boo nee oe Ba ark 53 Example of a bi directional communication PAD 54 Interface connections lt lt lt 4 ee 56 Data generator interactions during a verification of a C slave device 62 Data capture during a write data transfer or a general call 65 Data capture during a read data transfer lt lt 444 66 The Scoreboard class interactions lt lt lt lt lens 67 The bus analyzer module lt lt lt aaa 68 Communication Speed decoder to configure Verify Specs FSM time specs 69 Finite State Machine FSM used to verify the C bus specification protocol 71 Finite State Machine FSM used to counter the SCL clock pulses 73 PC Slave device properly connected to the bus lt lt lt lt lt lt lt lt 79 Global verification report lt lt lt lt lt een 82 Single report for each verification lt lt lt lt lt eee 82 Single report for each verification With errors lt 82 Single report for general call verification lt 83 Structure of the report files ee ee 83 Global verification report o oo ee 91 Single report for each verification lt lt lt lt les 91 Structure of the report files ee 92 List of Tables 21 31 32 33 34 3 5 3 6 3 7 3 8 3 9 3 10 3 11 3 12 41 42 43 44 Comparat
88. le 4 4 complements the figure 4 11 It has the possible transfers and also the verifications performed by each state according to the transitions performed by both SDA and SCL signals Current State Next State Verifications to Conditions Perform START COND S LOW T HD STA S LOW S ACK T LOW If the SCL clock pulse is the 9 S ACK S LOW T HIGH F SCL S LOW SZ ON T LOW SZ ON S LOW T HIGH F SCL SZ ON STOP COND T SU STO STOP COND START COND T BUF S Z ON S ON Z T HIGH T HD DAT S LOW S ON Z T HD DAT S ON Z S LOW T HD DAT Previous state was S LOW C and the T VD ACK SCL clock pulse is the 9 S ON Z S HIGH T LOW If data flag 1 also verifies T SU DAT S HIGH S ON Z T HIGH F SCL S HIGH S LOW T HIGH T HD DAT S LOW S HIGH T LOW T HD DAT T SU DAT S ACK S ON Z T HIGH T HD DAT F SCL S HIGH SZ ON T SU STA S ON Z SZ ON T LOW T SU DAT S ON Z S LOW C Verifies T HD DAT if previous state was S HIGH S LOW C S ON Z S LOW C S HIGH T HD DAT F SCL T SU DAT T LOW S LOW C SZ ON T LOW F SCL Table 4 4 Verifications performed per each state of the verify specs FSM 4 2 Structure Adopted 73 e SCL Counter FSM The SCL counter FSM is a task of the bus analyzer module It performs a simple counter and 1s used to counter the SCL clock pulses This counter allow the verify specs FSM to decide when transits to th
89. lexos guer em tamanho quer em funcionalidade Este aumento de complexidade obriga a que as ferramentas de verifica o se tornem cada vez mais eficientes acompanhando assim a evolu o destes Estas ferramentas de vem detectar todos os erros e falhas antes do circuito passar ao processo de fabrico O processo de verifica o muito importante para identificar eventuais erros de projecto ainda um processo dispendioso quer a n vel temporal j que a verifica o ocupa cerca de 60 a 80 do tempo quer a n vel monet rio visto que este tipo de ferramentes excessivamente caro Apesar do C ser um protocolo de communica o relativamente simples existem algumas falhas que poder o ocorrer comprometendo assim o desempenho do circuito projectado Tais fal has dever o ser detectadas ainda durante o processo de verifica o evitando assim aumentos n o considerados inicialmente no custo final do projecto Esta disserta o apresenta o desenvolvimento e a implementa o de uma plataforma de ver ifica o que por simula o verifica os circuitos que respons veis pela comunica o com outros circuitos usando o protocolo de comunica o IC O desenvolvimento desde projecto contou ainda com a colabora o da empresa SiliconGate Lda Primeiramente ser o apresentadas e comparadas diferentes solu es j existestes no mercado actual para a verifica o deste protocolo Em seguida ser o apresentadas as especifica es referente
90. lications As a standalone C core or a verification IP or even a system on chip SoC verification with JC interface The nSys verification suite supplies protocol checks for C as a master or as a slave device Being a master this platform generates the stimulus and drives them to the bus as a slave it re sponds to the master performing the transactions requested Multi master environment capable of checking arbitration logic is also supported by this structure and even has the capacity of simulate the bus with BFM tasks A detailed assertion coverage report can be automatically generated by the IC checker The verification environment and logical parameters can be parameterized by the verification engineer 2 3 Other Verification platforms 25 FEATURES In addition to the previously described and according to the 72C functionality this suite has the following features e Two operating modes master slave e Is capable to generate and drive bus traffic as a C master e Is also capable to respond to transactions requests as a C slave e Support multi master environment to check arbitration logic e Generates START STOP and repeated START conditions e The C checker generates a detailed verification report e Allows to configure the verification environment and other logical parameters e Supports NXP s C bus specification protocol v2 1 e Operates at standard fast and high clocking speed e Possibility to a
91. ll the time specifications described in the C bus specification protocol for each bus speed mode The user have to specify during the configuration process the operating speed for the verification process this will define the time specifications used to monitor the PC bus Different operating speeds have different time specifications These specifications will then be used in the verify specs FSM to compare the time of the events occurred on the C bus with the time specified in the bus specification protocol for the same events Figure 4 10 represents the communication speed decoder with the specifications which configure the verify specs FSM HD STA SU STA SU STO SU DAT HD DAT T LOW T HIGH T BUF VD ACK F SCL Operating Speed mode Figure 4 10 Communication Speed decoder to configure Verify Specs FSM time specs e Verify Specs FSM Another task used by the bus analyzer module is the verify specs FSM This state machine monitors the C bus to verify if the PC bus specification protocol is not violated The verification of the IC bus communication protocol is performed during the communication between the PC 70 The PC Verification Suite Verification Suite and the device s under verification The verify specs FSM is sensitive to both SCL and SDA IC signals and it is composed by 10 states The table 4 2 defines the verify specs FSM based on the SCL and SDA signals It also defines the next possible valid state
92. m show Article jhtml articleID 219000119 Philips Semiconductors PC Logic Family Overview 2004 Available online at http www nxp com acrobat download various philips i2c logic overview pdf PC Bus Interfacing and Tools Available online at http www i2cbus com IEEE amp Accellera SystemVerilog Available online at http www systemverilog org IEEE Computer Society IEEE Standard for SystemVerilog Unified Hardware Design Specification and Verifi cation Language November 2005 Available online at http ieeexplore ieee org servlet opac punumber 10437 IEEE Computer Society IEEE Standard for System Verilog Unified Hardware Design Specification and Verifi cation Language November 2007 Available online at http ieeexplore ieee org servlet opac punumber 4410438 IEEE Computer Society IEEE Standard for SystemVerilog Unified Hardware Design Specification and Verifi cation Language December 2009 Available online at http ieeexplore ieee org servlet opac punumber 5354133 AsicGuru com Introduction to SystemVerilog Available online at http www asicguru com system verilog tutorial introduction 1 Srikanth Vijayaraghavan and Meyyappan Ramanathan A Practical Guide for SystemVerilog Assertions Springer First edition 2005 IEEE Standards Association IEEE Aproves SystemVerilog and Verilog standards for Electronic Desgin Avail able online at http standards ieee org announcements pr p1
93. n which could be from the SCL or the SDA line During the communication between the verification platform and the device s under verification the verify specs FSM transits from state to state according to the transitions of the SDA and SCL lines as described in figure 4 11 SDA 1 SCL 1 SDA 0 SCL 1 If 9th SCL SDA 1 0 SCL 010 SDA 14 SCLs10 e e Sv scL 0 01 WE SCL 1 SDA 1 0 SCL 0 0 Valid State only one line changes S Valid State specification time fails E X X P M lae EDEN Invalid State X iat due a E wrong transition X SCL 1 A N SDA 1 xn SCL 0 ee _ so Figure 4 11 Finite State Machine FSM used to verify the C bus specification protocol During a data transfer SCL and SDA line can perform several transitions However not all are valid Figure 4 11 contains all the transitions that can occur during the simulation The transitions represented in green line pattern are valid however they can fail the verification test if the result 72 The PC Verification Suite of the verification performed does not meet the minimum requirements defined by the protocol In red dash point pattern are the transitions that can occur but with one of the specifications fail Finally in black dashed are invalid and forbidden transitions They force the FSM to enter in a state to ends the current simulation The tab
94. nd are also described others 72C verification plat forms available on today s market The chapter 3 describes with very detail all the verifications that has to be performed to verify a PC device In the chapter 4 is presented and explained with a high detail the adopted structure for the C Verification Suite This chapter also describes each block that defines the developed ver ification platform In chapter 5 the develop platform will verify a real C slave device provided by SiliconGate All steps necessary to perform a verification are explained and demonstrated also in this chapter Finally the conclusions of this dissertation are described in chapter 6 as well as the future work and some final considerations This dissertation ends with the presentation of the references Introduction Chapter 2 State of the Art In this chapter are described the technologies used to develop the 72C verification suite and are also described some C verification platforms available in today s market It starts with the analysis of the NXP C Bus Communication Protocol describing its func tional mode its characteristics and advantages and also the disadvantages Then is described the language used to develop the verification suite industry s first unified Hardware Description and Verification Language HDVL standard the IEEE 1800 System Verilog The verification platforms field has a very broad market There are several solutions a
95. nd some of them very expensive to verify digital components in this case C components Without a great deal of detail this chapter presents the studied I2C verification platforms that most resemble the subject of this dissertation The objective of this chapter is to present the reader with other solutions commercially available and also to describe the most differences and likeness between them 2 1 C Inter Integrated Circuit In 1980 s Philips Semiconductors developed a simple bi directional 2 wire bus The original propose of this bus was to achieve the communication between a small number of devices on a single card such as the control of a radio or to providing a way to connect the CPU with peripheral chips in a TV set and then the Inter Integrated Communication ZC bus first developed in Philips labs at Eindhoven was born Philips Semiconductors migrated to NXP in 2006 5 6 1 In 1992 the first standardized version of I C was released This new released added a new operation speed the fast mode which allow communications at 400 kbit s and also a 10 bit ad dressing mode to increase capacity to 1008 nodes 6 State of the Art In 1998 the second version of this protocol was presented to the market Version 2 0 added another operating speed the high speed mode which enable communications at 3 4 Mbit s with reduced voltage and current reguirements that saved power The Version 2 1 from 2000 is a minor cleanup of version
96. nsfer in the 72C bus a master device has to generate a START condition to alert all slaves that it will occur a data transfer This condition will put all the slaves monitoring the bus for incoming data After the START condition the master sends the address of the device it wants to communicate The device address is 7 bits long followed by another bit which represents the data direction see figure 2 9 If after the slave address the data direction bit is 0 it indicates a data transmission WRITE However if the data direction bit is 1 the master is requesting for data READ 1 MSB LSB T T T T T T E 1 L 1 1 L 1 slave address Figure 2 9 The slave address plus the data direction bit 8 After the master sending the slave address plus the data direction bit all devices in the bus will compare the 8 bits received with their own address The device that has the same address as the one sent by the master will respond to it with the ACK signal However if the address does not match any of the devices on the bus all the devices will wait until the bus is released by a STOP condition S SLAVE ADDRESS RW A DATA A DATA AA P data transferred 0 write n bytes acknowledge zi from master to slave A acknowledge SDA LOW A not acknowledge SDA HIGH from slave to master S START condition P STOP condition Figure 2 10 Example of a WRITE operation
97. ntegrated Circuit x 2439 44 9 9X REE EEE RSS 3 2 1 1 The G Bus Protocol oa a sk a ow Bae s eS OR S dur 2 1 2 Advantages and limitations of C bus lt lt lt lt lt 4444 2 2 IEEE 1800 SystemVerilog es 2 3 Other Verification platforms lt lt lt lt lt en 2 3 1 Synopsys Verification IP for PC lt 2 3 2 eInfochips PC Verification Component 2 3 3 hdl Design House HVC 800 SV PC i 2 3 4 nSys nVS Verification suite lt lt ee ee 295 SmatDV FO VIP ge qon sega vr ea cg Frid dc Ra 2 3 6 Cadence Verification IP for C lt 2 4 Summary o 24 405 Rs oe a hee dx EUR RS ELE GE J ADA deo E RUE EUR A A Verification of C Devices 31 Introduction lt z s esses ed e ooo ee Re OE SERE Ree e 3 2 Communication Status Messages i 3 2 1 Hold time specification for START and repeated START condition 3 2 2 Set up for repeated START condition a 32 3 Data valid ACK time lees 3 2 4 Set up time for STOP condition llle 3 25 Bus Tee time ssa 6s os ae Bae a Po doe a okn a 33 SCLsignal 2242222204443 449 LR ERE LE s 3 3 1 SCLLOWperiod lt lt lt ee ee 3 3 2 SCLHIGHperiod en 3 3 3 Operating frequency i 3 4 SDA Signal 422436 pa Ba Pa x 94V Pa Rae Remo e ep Bae ead 341 Data hold time os 3 4 2 Data set up time lee 343 Data valid time 20 0 000 000 00000008 3 5 Address Dataintegrity lt eee ee 3 5 1 Inval
98. o several aspects and characteristics of technol ogy Speed of processing size power cost and even the time of manufacturing comply or follow very closely this law 3 4 Digital microelectronics design is a very important step in the creation of advanced technology One of the most important aspects of this step is the transistor density meaning the number of transistors on a given area Therefore microelectronics design is particularly responsive to the Moore s law This increase in complexity creates a situation in which more flaws are not foreseen in the design phase These flaws when not detected before the fabrication can lead to an unexpected behaviour from the circuit Because the fabrication process is a very cost expensive and time consuming it is desirable to reduce any potential errors To counteract this there s a verification phase before any fabrication takes place but with the complexity in circuits the tools that are used in the verification phase need to be more complex as well This creates the need to improve and even develop new ways to turn more efficient the verification phase In terms of time this phase occupies more that half the time consumed this fact makes the creation of a good and efficient verification process even more critical Furthermore the solutions that already exist in the market for the verification process are very expensive specially for start up companies This dissertation presents the
99. of one bit each It comprises the verification type 5 bits and the result pass fail 2 bits The scoreboard sends to the report generator a notification and an array of 3 positions with 8 bits each This array is to sends the three bytes used to verify the data integrity For each time the C Verification Suite performs a verification process it creates inside the results folder a folder named with the local data and current time dd mm aa_hhmmss Next to this folders the verification platform creates additional folders which one corresponds to each device verified 76 The PC Verification Suite 4 3 Features and Benefits The C Verification Suite provides a simple way to verify the 72C bi directional two ire bus This verification platform is fully compliant with version 3 0 of NXP s C bus specification pro tocol and provides th following features Supports standard fast fast and high speed operations Support for all types of C devices Master Slave Generates START STOP and repeated START conditions General call verification Data integrity checking Support 7 bit addressing Performs writing and reading operations Contains many configurable features such as SCL s period Verification type Number of communications to perform unlimited Number of bytes to transfer unlimited Detects and reports protocol errors such as Invalid Slave Address Empty bus no devic
100. og language System Verilog Inter faces not only allow the communication between modules but also between classes The interface described in F 1 exemplifies how to declare an interface and in figure 4 4 is represented how to connect it to modules and classes from the declaration in the top module 26 27 Listing 4 1 Interface declaration interface intf 1 logic signal A logic signal B modport Al input signal A output signal B modport A2 input signal B output signal A endinterface The modport construct used in the interface F 1 is one of the elements included in System Ver ilog Interfaces It is used to provides information about the direction of the variables wires between a module or a class clients and the interface Besides modports System Verilog Interfaces also comprises objects methods and processes The objects are data carriers in the form of variable and or wire The methods are functions or tasks for handling the objects in the interfaces and the processes are static functionalities presented in the interfaces such as the always statements The objects and the processes are elements of the Interface whereas the methods are functions to allow connected modules or classes accessing handling and manipulating the interface objects The methods can also be invoked by the interface processes and their access can be controlled When a client access an interface and if objects are listed the client c
101. ok FSSC I I AC a Ak ak ak ok End of I2C Verification Suite Report FOI ICICI ACI IK ACK FSSC CI I I CC ak ak ok ok Appendix E General call Verification Report compact version Listing E 1 Interface declaration FORK KK KKK KK K K kk KK k Kk k K FG E K KKK KK k K k K K k Kk K Kk KK k K I2C Verification Suite Report EEEE K OH K KK KK kk K K K Kk KK k KK K K FG OH K K Kk KK k K k K K K Kk K Kk KK K K skok KKK KKK skok okokok okokokookokokokokookokokookokokokok E E E E E E E RK k k k kk k k k K k Kk kk RK k Kk Kk k kk Kk k k k K k K k K K K K K kokokokokok ok K K K K k K k K K K K K K KK KKK K K K kokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokok K SRR KK K KK KK K KK K KK K KK K KK K KK K 2k K WRITE MODE kK 2K 2 K KK K KK FK KK FK FKK FK FKK FK FKK FK FKK FK K K K K K K k kokokokokokokokokokokokokokokoko K K K K K RR KK K K K K K kokokokokokokokokokok K k k k eee K K K 3K KK KK K K K K K 3K KKK KR ROK RK EEEE EEE KR RK KKK ORK RK E K k k k k k k k k k KKK kk k Kk kkk kk Kk k k k K k Kk K K k K k xFAIL 105 00us T HD DAT minimal time FAIL with 0 00us Byte 1 of transfer 1 xFAIL 185 00us T HD DAT minimal time FAIL with 0 00us Byte 1 of transfer 1 skok okok okokokookokokookookokokok okokokookokokokokookokokookokokokok okokokookokokokokookookokookok okokok k k k k k k k kk k Kk kk k kk kk k k k K k K k K K K K kK K K k K k K Kk k k k K k KK K KK KK k K K K K K K K EEEE K K K k Kk
102. okokokokok ok K K K K k K k K K K K K K KK KKK K K K kokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokok K SRR KK K KK KK K KK K KK K KK K KK K KK K 2k K WRITE MODE FK 2K 2 K KK K KK FK KK FK FKK FK FKK FK FKK FK FKK FK K K K K K K k EE K K K K K K k K k RGR RR KK K K K K K kokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokok K skok KKK KK ROKK okokokookokookokokookokokookokokokok EE E E E E E E E RK K k k k k k k k k k k kk kk k Kk kkk kk Kk k k k Kk Kk K K K K k xFAIL 105 00us T HD DAT minimal time FAIL with 0 00us Byte 1 of transfer 1 xFAIL 185 00us T HD DAT minimal time FAIL with 0 00us Byte 1 of transfer 1 skok KKK ROKK okokokokokokokokookokokookokokokok EE DR E OR KK RR k k k k k k k k K k k k kk kk k Kk Kk k kk Kk k k k K k K k K K K K K kokokokokokokokokokokokokokokok K kok K K RR KK K K K K K E E K K K eee eee eee eee eee ee ee FRR ROKK KK KK K KK K AK K KK K K K K K K K K ak K READ MODE FK 2K 2 K KK K KK K KK FK FKK FK FKK FK KK FK KK FK K K K K K K k FOGG SSG GRR RR RR RK ok kokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokok k skok kok okokokookokokookokokokok okokokookokokokokookokokookookokokok okokokokokokokokookookokookok okokok k k k k k k kk kk k Kk Kk k kk Kk k k k K k K k K K K K k xFAIL 292 70us T HD DAT minimal time FAIL with 0 00us Byte xFAIL 303 00us T HD DAT minimal time FAIL with 0 00us Byte xFAIL 313 00us T HD DAT minimal time FAIL with 0 00us B
103. on and the bus free time between a STOP and a START con dition FEATURES In accordance with 7 C functionality this platform presents some important features such as Supports C bus specification v2 1 Platform monitor based in System Verilog assertions Capture the C transactions Property checks implemented for both protocol and timing Platform developed following Mentor Graphics Advanced Verification Methodology AVM Transactions with reserved address Detects when SCL or SDA stucks at 0 Detects illegal RESTART condition Detects empty transfers STOP condition immediately after a START condition Illegal transfers in 10 bit read mode Errors in GENERAL CALL mode 24 State of the Art 2 3 4 nSys nVS Verification suite The PC nVS is the solution developed by nSys for verifying the inter chip bus communication protocol 21 In figure 2 18 is represented the nSys solution for this type of verification SoC Verification Environment Test Suites 12C Monitor 12C Checker Figure 2 18 nSys Verification Suite 21 As we can see in figure 2 18 the C nVS verification has four main elements They are the master and slave Bus Functional Model BFM the checker the monitor and finally the test suites The test suites are comprised by several kinds of tests such as the basic the error directed constrained random and also user specified The C nVS verification platform can be used for dif ferent app
104. on protocol is violated e Comes with a testsuite to test every feature of C specification 2 3 Other Verification platforms 31 2 3 6 Cadence Verification IP for C The Advanced Cadence testbench VIP known as Universal Verification Component UVC for PC case is a platform to verify the 7C NXP s communication bus protocol 24 This UVC for C offer a system called Compliance Management System CMS shown in figure 2 24 The CMS is a metric driven verification solution that automates protocol compliance verifi cation It enables users to achieve high functional coverage without having to write and manage hundreds or even thousands of directed tests The CMS also correlates coverage to the protocol specification itself 24 25 The structure of Cadence UVC environment is shown in figure 2 25 Figure 2 24 The CMS automates protocol compliance verification 24 25 UVC FOR PC The Cadence UVC complies with the 72C bus specification protocol Offers a functional cov erage generating a large number of packets to stimulate the device under verification DUV and at the same time using its predefined set of coverage points measure the verification completeness This component has the ability to be configured to emulate a single master slave or both devices or even emulates the entire C bus system with various devices It offers the chance to generate automatic constrained random stimulus assertion checking and also functi
105. onal coverage analysis This VIP for C complies with Open Verification Methodology OVM and support simul taneous hardware and software verification at different levels It also supports IEEE standard testbench and systemVerilog Verilog e and VHDL design languages 32 State of the Art PC Bus Interface Figure 2 25 The UVC for I 2C Environment 24 FEATURES In addition to the described above this platform presents some important features such as e Supports C bus specification Can be configured to support each individual DUT Verifies I C based devices and IP s e Use the CMS system Metric Driven automated verification e Complies with OVM Allow the user to choose between SystemVerilog or e testbenches language e Supports coverage measurement and also generate reports e Has the possibility to configure the Verification environment Configurable UVC to focus the verification in any part of the design Capability to turn on or off any functional block coverage or check and report ele ments e Generates constrained random stimulus e Error generation and injection or even noise into the stimulus e Include functional coverage measurement and reporting with built in functional coverage items 2 4 Summary 33 2 4 Summary This chapter introduced different kinds of verification platforms for verify the C bus specifi cations Despite their differences they have the same objective vali
106. onnected using that modport is enabled to access all the named objects using one of several access modes types input output or inout Modports can be omitted when designing non RTL interfaces however they are mandatory for RTL synthesis 26 27 So in the Top Module are instantiated the bi directional communication pads the devices under verification the bus analyzer the verification program testcase and all the interfaces for the communication between all the platform blocks and the devices The interfaces declared are used to enable the communications between e IC bus and the bi directional pads e Verification platform and DUV inputs 56 The PC Verification Suite e DUT outputs and the C Verification Suite e Bus analyzer and Scoreboard e Bus analyzer and report generator e Master BFM and receiver e Data generator and report e Data generator and master slave BFM e Scoreboard and report generator e Master slave BFM and bi directional pads e Devices under verification and bi directional pads top module sv module A sv program A sv class A sv Figure 4 4 Interface connections The Testcase block was implemented using SystemVerilog s program block This construct is used to modelling the test environment subsection 4 2 2 It provides an entry point to the verification platform and also creates a scope that encapsulates program wide data This block contains all the above interfaces declared a
107. oreboard classes the for the communication between the receiver and the scoreboard classes x reset This method is used to reset all the devices under verification connected to the I2C bus before the verification process starts x config The config method configs the IC Verification Suite according to the parameters set by the user start The Start method starts the verification process by calling other methods which are declared in other classes such as the data generator the master slave BFM the receiver the scoreboard and the report generator x report The report method is used to print all the events or only the errors occurred during the verification process The constructor method is declared with virtual interface as arguments so that when the object environment class is created in the testcase program the new method can pass the interfaces in to environment class where they are assigned to the local virtual interface handle This points the virtual interfaces declared in the environment class to the physical interfaces declared in the top module SYSTEMVERILOG MAILBOX Mailboxes are a solution provided by SystemVerilog that enables the inter process communi cation between two threads A mailbox operates like a FIFO where one process can write data to the mailbox and the other process can read data from it SystemVerilog mailboxes can have a limited size or they can be unlimited 11
108. perform a ACK signal figure 3 3 the process is identical but only makes sense if the 8 bit is 1 In this case the SDA signal must remains with the current value during the specified time after the falling edge of the SCL 8 pulse and change to 0 after this time Table 3 3 shows the minimum and maximum time when performing a ACK or NACK signal 3 2 Communication Status Messages 39 SDA tvD ACK SCL 70 SCL 30 gth clock gth clock Figure 3 3 Acknowledge ACK 1 Figure 3 4 Not Acknowledge NACK 1 Symbol Parameter sm Fm Ent Hs mode Unit Min Max Min Max Min Max Min Max Data valid T VD ACK acknowledge 3 45 0 9 0 45 0 0 07 us time Table 3 3 Data valid ACK time specifications 3 2 4 Set up time for STOP condition The STOP condition is the condition that communicates the end of a transmission This con dition has a minimal set up time that has to be met by the master devices This specification is defined as the time passed between the raising edge of the SCL signal and the raising edge of the SDA signal as described in figure 3 5 Table 3 4 shows the minimum time that STOP condition must have SCL Figure 3 5 STOP condition 1 40 Verification of PC Devices Sm Fm Fm Hs mode Symbol Parameter Min Max Min Max Min Max Min Max ene Set up time T_SU_STO for STOP 4 0 0 6 0 26 0 16 us condition
109. rcuits at levels of abstraction ranging from system level stochastic and behaviour down to gate and switch level It is also used for gate level verification of ICs including simulation fault simulation and timing verification Beyond the verification capabilities SystemVerilog is also used synthesize gate level descriptions from more abstract descriptions The SystemVerilog HDVL has features inherited from Verilog C C SystemC and also offers the possibility to call functions from these languages using the System Verilog s Direct Programing Interface DPI and vice versa Figure 2 14 shows the unique features of System Verilog and also and what is it inherited from these other languages SystemVerilog test program blocks persistent events PEK from G C cocscccccccccey clocking domains process control classes dynamic arrays mailboxes constrained random values inheritance associative arrays semaphores direct C function calls strings references assertions dynamic processes int globals break interfaces 2 state modeling shortint enum continue nested hierarchy packed arrays longint typedef return unrestricted ports array assignments shortreal structures do while automatic port connect specialized procedures double unions em m n enhanced literals enhanced event control char casting gt gt x gt gt gt lt cc time values and units unigue priority caselif void const 8 Verilog 2001 ANSI C style por
110. rification Figure 3 14 Data integrity check from master to slave 3 5 3 Data from slave to master This verification checks the data integrity transmitted from the slave to the master device The verification principle is the same as the verification of the data transmitted from the master to the slave device compares the data transmitted in the C bus with the data in the slave device and with the data received in the master device In this mode is also possible stop the verification if an error occur Like the 2 previous verifications this is also done in the comparator block as represented in figure 3 15 3 6 Invalid data transfer 47 L Figure 3 15 Data integrity check from slave to master 3 6 Invalid data transfer 3 6 1 Illegal format If immediately after a START condition a STOP condition is performed this is defined as a illegal format also known as void message Despite some devices can operate properly under this condition this is not defined in the C bus specification protocol Figure 3 16 describes how a void message is performed pl SDA SCL sorsr p L _ bd START or STOP repeated START condition condition Figure 3 16 Void message 3 6 2 Invalid ACK NACK As stated in section 2 1 after each byte transmitted by the master the slave device has to perform an ACK signal if received the byte correctly or a NACK is something went wrong
111. rs the master BFM after receiving the ACK from the device under verification request a new byte to the data generator if burst mode is used in write mode This process is repeated as many as the number of bytes defined in the N BYTES parameter If at any time during a transfer the device under verification performs a NACK signal the master BFM can stop the communication performing a STOP condition Otherwise it does not resquest a new byte and re send the same byte This option is once again configurable in the config class In read mode the process is almost identical The master BFM reads the C device previously addressed and at the same time that performs the ACK signal requests to the data generator a new 64 The PC Verification Suite byte for the device under verification Like in the read mode this process is repeated as many as the number of bytes defined in the N BYTES parameter The communication ends when the master BFM produces a NACK and then the STOP condition as specified in the NXP s C bus specification protocol The data received by the slave under verification is then sent to the receiver class to be then sent to the scoreboard class to verify the data integrity as will be described later on 4 2 6 Receiver The C Verification Suite performs data transfers to stimulate the devices under verification in order to verify their behavior During the verification of this devices is necessary to capture the data rece
112. rt 6 2 1 gt Detailed report 7 Use STOP ON ERROR parameter to stop the verification process if an error occurs 7 1 0 gt Continue if an error occur 7 2 1 gt STOP the verification process 8 Use the VERIFICATION TYPE parameter to choose how to do the verification 8 1 Verify all data and time specifications 8 2 Verify only all time specifications 8 3 Verify only all data specifications 8 4 Choose the type of verifications Note To choose the verification just insert the verification name in the config file 8 4 1 T HD STA 8 42 T SU STA 8 43 T VD ACK 8 44 T SU STO 8 45 T BUF 8 46 T LOW 8 4 7 T HIGH 8 4 8 T HD DAT 90 8 4 9 T SU DAT 8 4 10 T VD DAT 8 4 11 AS A 8 4 12 D_M_S 8 4 13 D_S_M 8 4 14 F_SCL PC Verification Suite User Manual The configuration of the verification process for one device should be like the example de scribed below Listing A 2 Device instantiation SLAVE ADDR BUS DEVICES SCL FREQ INPUT METHOD N COMN N BYTES DISPLAY REPORT REPORT TYPE STOP ON ERROR VERIFICATION TYPE T HD STA T SU STA T VD ACK T SU STO dk dk T BUF T LOW T HIGH T HD DAT T SU DAT T VD DAT ASA DMS DSM F SCL dk HH db HH db db HH 14 9 o F o Hold time for START and reSTART condition Set up time for repeated START condition Data valid ACK time Set up time for STOP condition Bus free time between a STOP
113. s F SCL with 100 000000 kHz TLOW with 5 00us T HIGH with 5 00us Final Verification Report detailed version Final Verification Report detailed version 99 OK 155 00us F SCL with 100 000000 kHz OK 160 00us TLOW with 5 00us OK 165 00us T HIGH with 5 00us OK 165 00us F SCL with 100 000000 kHz OK 170 00us TLOW with 5 00us OK 175 00us T HIGH with 5 00us OK 175 00us F SCL with 100 000000 kHz OK 180 00us TLOW with 5 00us OK 185 00us T HIGH with 5 00us OK 185 00us F SCL with 100 000000 kHz OK 185 00us T VD ACK with 0 00us FAIL 185 00us T HD DAT minimal time FAIL with 0 00us OK 190 00us T LOW with 5 00us OK 195 00us T HIGH with 5 00us OK 195 00us F SCL with 100 000000 kHz OK 200 00us TLOW with 5 00us OK 204 00us T SU STO with 4 00us NC Data transfer OK 190 00us Data Received match the data transmitted 10111111 skok KKK KKK okookokokok KKK KOK KK okokokokokokokokookookokookok okokok k k k k k k kk k k k Kk kkk kk Kk k k k K k K k K K K K k E K OH K K KK KK kk K k KK K Kk KK k KK K K K K K READ MODE E K OH K K K Kk k k k K k KK K Kk KK KKK k K K K FR CCK OH K KK k k k K k KK K Kk KK k Kk K K K K K BRR OH OH E OH OH KOK k Kk k kk K k KK K Kk KK k Kk K K K K K BRR EK OH K KK k Kk k kk K k KK K Kk Kk k KK K K K K K EEK OH K K k Kk k k k K k KK K Kk KK k KK K K K K K skok KKK RK KKK KKK KOK OK KKK KKK RR k k k kk k k k kK
114. s proposed It verifies all the C time specifications protocol and also checks all the integrity of all the data transferred in the C bus During the development of the C Verification Suite there was always the concern to make a platform to verify all the protocol specifications described earlier and at the same time to make it as simple and flexible as possible not only in the structure but essentially in the blocks where the user interacts This led to some improvements that were made not only during the develop ment of the platform but also after it was finished because during the tests some difficulties to configure and use the platform were detected In order to overcome these difficulties some extra improvements were made so that this platform would become simple intuitive dynamic and flex ible In the same way was always a concern about the final report This had to be very simple to understand to allow the user to detects the violations and to know exactally where and why they occurred Despite the increasing complexity of digital circuits this dissertation proves that new verifica tion platforms are also possible to develop and follow the development of new circuits 85 86 Conclusion 6 2 Prospective Work The future work can be divided into 3 parts The first one is connected with the improvement of the bus analyzer Given enough time if implemented using SystemVerilog s assertions with sequences and proper
115. s a module called bus analyzer This module monitors the C bus and verifies if the I2C bus specification protocol is violated at any time during the data transfers per formed between the C devices connected to the C bus and the verification platform In figure 4 9 are represented the components of the bus analyzer module and how they are inter connected SDA Data Transferred Operating Speed mode Bus Analyzer Figure 4 9 The bus analyzer module To monitor the C bus the verification platform uses a module called bus analyzer This module is composed by 3 finite state machines FSM and a decoder which are The Verify Specs FSM The Data Transfer FSM 4 2 Structure Adopted 69 The SCL Counter FSM The Communication Speed decoder The verify specs FSM is used to monitor the C bus verifying if any specification is violated during data transfers The data transfer FSM also captures the data transferred in the C bus whereas the SCL counter FSM performs a counter which is used to counts the the SCL clock pulses Finally the communication speed FSM is used to the configure the verify specs FSM with the time specifications defined for each bus speed by the C bus specification protocol e Communication Speed decoder Before starts monitor the C bus the verify specs FSM has to be configured with the time specifications defined for the operating bus speed The communication speed decoder contains a
116. s ao protocolo de comunica o 12C que ser o verificadas pela plataforma desenvolvida que aqui se apresenta Ap s esta descri o apresenta se detalhadamente a plataforma desenvolvida a sua rela o com a linguagem de verifi ca o e descri o de hardware assim como as caracter sticas e especificidades desta solu o Posteriormente ser demonstrada a funcionalidade da plataforma interligando a a um circuito de comunica o 1 C de forma a executar um conjunto de verifica es permitindo validar o cir cuito em teste de forma a avaliar a efic cida da plataforma desenvolvida S o ainda apresentados relat rios gerados pela plataforma que permitem informar se alguma das especifica es j referi das foi ou n o violada Finalmente s o ainda apresentadas breves conclus es sobre toda a disserta o ii Abstract During the last years circuits have been getting more complex in size and specially in function ality This increased complexity reguires that the verification tools become increasingly efficient These tools should detect all the errors and failures before the fabrication process takes place The verification process is very important to an engineer be sure that the designed circuit can accom plish the task for which it was designed successfully and according the specifications It is also an expensive process either temporal because the check takes about 60 to 80 of the time either monetary because these kin
117. s arguments using the construct described in figure 4 4 4 2 Structure Adopted 57 The Testcase program contains the instance of the environment class and has access to all the public declaration of environment class It passes all the interfaces and variables as an argument to the environment class and also invokes the methods defined in the environment class to start the verification process These methods are described and explained in subsection 4 2 2 4 2 2 Environment As stated earlier SystemVerilog uses Object Oriented Programing OOP It comprises classes objects handles properties methods and prototypes A class is a collection of data called prop erties and routines 1 e Verilog tasks and functions to access the data called methods which can only access to the properties of the same class Table 4 1 shows a comparison between these OOP terms and the eguivalent in Verilog 2005 and also describes the definition of each term 2 OOP Term Definition Eguivalent in Verilog 2005 Class Basic building block containing routines Module and variables Object Instance of a class Modules instances Handle Pointer to an object Instance name to refer signals and methods from outside the module Property A variable that contains data Register or Wire Method Code that manipulates the variables of the Modules in Verilog has tasks plus initial and tasks and functions always blocks Prototype Routine header which s
118. ss Data integrity 45 Figure 3 12 Data valid time during a transfer 1 Symbol P t Sm Fm Fm Hs mode Unit piane een Min Max Min Max Min Max Min Max T_VD_DAT Data set up time 250 100 50 10 ns Table 3 11 Data valid time specification for all speed modes 3 5 Address Data integrity 3 5 1 Invalid device address This verification is used to check the integrity of the device address sent This is done in the comparator block by comparing the address selected to be transferred with the address sent If they do not match this verification allow the platform to detect if the error occurs during the transfer in the master device or in the receiver device Figure 3 13 shows how this verification is performed Figure 3 13 Verification of the slave address 46 Verification of PC Devices 3 5 2 Data from master to slave When a master device transfers data to a slave device this verification will compare the data to be transferred with the data transmitted in the C bus and with the data received in the slave device This verification checks all the data transferred to all the devices and also checks if a slave received the correct data Also done in comparator block it allows the user to know in case of failure if the problem is in the master or in the slave device with the possibility to stop the current verification Figure 3 13 represents the structure of this ve
119. ties this module may prove to become more robust The second part is improve the slave bus functional mode to enable the verification platform to verify a master device Finally the last part is connected with the software used to run the 72C Verification Suite I think it would be better if the developed verification platform could be multi platform to be accessible to other software 6 3 Final Considerations Though far from a commercial product I think this C verification platform presents a new solution for the verification of C devices It contains some concepts and ideas that makes this type of verification tools some times complex to use easier for ordinary users Appendix A PC Verification Suite User Manual This manual is divided in two parts The first part describes all the steps needed to configure a verification of a C slave device The second part concerns to the analysis of the results provided by the platform It starts by explaining where and how the designed I2C slave connects to the IC bus Then is necessary to run the setup for the verification process This process will define the entire ver ification process stimulus number of devices to verify data to transfer report type among others Finally a description and an explanation of the final results are made always followed by illustrative images of the current process in order to provide a better understanding of how verify a I C slave device us
120. tion 3 2 2 Set up for repeated START condition The repeated START condition is performed exactly like the START condition see sec tion 2 1 This condition repeated START has a set up time specification that has to be met With the SCL signal in a LOW state and the SDA signal in a HIGH state this specification is de fined has the time elapsing from the raising edge of the SCL signal to the falling edge of the SDA signal Figure 3 2 shows how a repeated START condition is performed while in the table 3 2 are 38 Verification of PC Devices described the specifications for all operating speed in the bus SCL Figure 3 2 Repeated START 1 Symbol Param ter Sm Fm Fm Hs mode Unit s A Min Max Min Max Min Max Min Max Set up time for repeated START condi tion T SU STA 4 7 0 6 0 26 0 16 us Table 3 2 Set up time specifications for the repeated START condition 3 2 3 Data valid ACK time As stated earlier the ACK or NACK signals are defined each 8 bits transferred section 2 1 The device that will generate the ACK singal need to respect this time specification so that the device that waits for this signal can detect it This specification is defined as the time elapsing from the falling edge of the 8 SCL pulse to the next raising edge of the SDA signal before the 9 SCL pulse Figure 3 4 shows how this specification time works when performing a NACK signal If a device wants to
121. transmitted 10111111 OK 190 00us Data Received in device 14 match the data transmitted 10111111 Total Devices that respond to the generall call 2 2 skok KKK EEE EE EEE KK KKK OK KK okokokokokokokokookookokookok okokok k k k k k k kk k k k Kk kkk kk Kk k k k K k Kk K K K K k BRR OH K SH OH k KK KK kk Kk KK K Kk KK k KK K K K K K EEEE E E KKK kk K k k K k Kk K Kk KK k K k K K K K K SRG KK KKK Final Result KK KKK okokok KKK KKK KK KK KKK KKK skok K K K k K Kk OK k k K k KK K Kk KK KKK K K K K EEEE E K k KK k k k K k K K k KK K Kk KK K K k K K K K K 3K KKK KKK EE EEE EEEE EEEE EEE EE RR DR E KKK RR k K k k k k k k k k k k kk kk k Kk kkk kk Kk k k k K k K k K K k K k kkkk PEPEE xokokokek ok KK KK KK Total errors 7 gt kokokokok kk o kkk kk ok KK Kk kkk Verification FAIL LEETE kkkk PEPEE door ok ok KK Total Errors in Write Mode 2 KKK Kk OK kkk KK Kk k skokokokok I2C data transferred errors 0 gt kokokokok Ok OK I2C Specification Standard errors 2 DEE EES kk ok KK kk ok KK kkk kk kK kkk Total simulation time 402 00us kk ok KK okokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokokok skok KKK ROKK RK okokokookokokokokookokokookokokokok EE E E E ORK KR KK okokok k k k k k k kk kk k Kk kkk kk Kk k k k K k Kk K K K K K 108 General call Verification Report detailed version FRR K Kk K Kk K k
122. ts hooked up in the C bus system 50 Verification of PC Devices Chapter 4 The I C Verification Suite Once described and explained all the specifications that guarantee a good communication with out loss of data this chapter presents the developed 72C Verification Suite It starts by explaining the structure adopted why and how it works Then there will be a detailed analysis of each block explaining the function performed in the C Verification Suite the type of specification it per forms how it works and how its implemented Finally at the end of this chapter are described all the features and benefits of the C Verification Suite 4 1 Overview The main goal of a C verification platform is to validate circuits that use the C bus commu nication protocol To achieve this objective the C verification suite has to stimulate the device under verification DUV by performing data transfers on the C bus system reading and writing data modes During each transfer the platform has to monitor the SCL and SDA lines to verify if the time and data transfer specifications are met At the same time is also needed to verify the data integrity during a communication by checking the data which could be generated by the platform or by the user with the data received and with the data transmitted on the C bus To verify some specifications such as the ACK signal after the master send the slave address or the general call address
123. ts standard file I O attributes multi dimensional arrays generate value plusargs configurations signed types localparam ifndef elsif line memory part selects automatic constant functions O variable part select power operator Verilog 1995 modules Sfinish fopen fclose initial wire reg begin end parameters Sdisplay write disable integer real while function tasks monitor events time for forever gt gt lt lt always define ifdef else wait packed arrays if else assign include timescale fork join 2D memory repeat PE PE PE Figure 2 14 SystemVerilog extensions 15 SystemVerilog also provides a complete verification environment with the possibility of using Constraint Random Generation Assertion Based Verification and Coverage Driven Verification These methods allow a verification engineer to improve the verification process These are not the 2 2 IEEE 1800 System Verilog 17 the only features that System Verilog HDVL provides for the verification phase It also has other important features such as e Data types SystemVerilog brings new data types such as dynamic arrays and logic data e Synchronization System Verilog offers two simple built in classes to perform a synchronous communication between different verification components They are Mailbox and Semaphore The Mailbox construct is like a FIFO while the Semaphore is modeled
124. uction The C bus communication protocol has some electric and time specifications and conditions that has to be met by the designers when designing a C compatible IC These conditions specify the IC functional mode and guarantee the communication between ICs Since the verification platform to develop will only check time specifications data integrity and communication condi tions the electric specifications are not described here The specifications that will be checked are grouped according to the function performed For example the events that precede the data transfer are grouped in the communication status section as well as those which occur after each byte transferred or after the transfer is completed The clock specifications are in the SCL signal section as the specifications for data transfer that are in SDA signal section 35 36 Verification of PC Devices Next are presented all the specifications grouped according to their functions which the IC verification platform should verify and detect if any of them fails They are as follow 1 Communication status messages 1 1 Hold time for START and repeated START condition 1 2 Set up for repeated START condition 1 3 Data valid ACK time 1 4 Set up time for STOP condition 1 5 Bus free time between STOP and START conditions 2 SCL signal 2 1 Minimal time for LOW period of SCL signal 2 2 Minimal time for HIGH period of SCL signal 2 3 Operating freguency
125. ured the speed address and the address type of all slaves connected to the bus Next the reguests are initiated with the read write and general call transfers generated in the testbench It is also possible for the master arbitrates the bus in case the bus is not free Its reaction can be configured in different ways Intentional errors can be created by forcing the master to abort a transfer The arbitration obeys all the rules specified in the C protocol 2 3 Other Verification platforms 19 Operating as a slave the bus will be monitored in order to detected a transfer reguest If it has been selected for a read reguest the response from the slave will be to send the data received in the input channel For the write reguests the master transmits data to the slave and the data will be passed to be compared in the testbench Errors can be created by forcing the slave to respond with or without an acknowledgement to any transfer reguests FEATURES In addition to the above this platform presents some important features such as Operate as a master slave or both Operates at standard fast and high clocking speed Possibility to address slaves with 7 or 10 bits Allows testing of varied bus traffic for Read Write and General Call Contains scoreboard feature to check data integrity Includes protocol based scenario generation Warms the testbench of protocol errors warnings and any other significant events Supports the
126. veral verifications he does not need to wait that one verification ends to start another He only needs to specify all the checks that he intends to do and start the verification process The verification platform will automatically run the next verification after it finishes the current one producing a final report of the whole verification process To configure the verification process the user only need to specify these specifications as he wish in a file called global parameters conf 4 2 4 Data Generator After the C Verification Suite is configured the platform will perform data transfers to ver ify the devices plugged in to the C bus The goal of this class is providing the data for these 62 The PC Verification Suite transfers The user is free to choose how the 8 bits data are generated They could be generated randomly or seguential from 0 to 255 This class also offers the possibility of instead generate the data for the simulation read the values from a file specified by the user and send them to be transferred The PC Verification Suite verifies a slave device in two steps In the first step the verification platform performs a write operation to the slave under verification After all data is transmitted the verification platform reads data from the slave device The data generator class provides the data for both reading and writing operations During the write operation of the verification process the data gener
127. vices PC Verification Suite Figure 4 1 PC Verification Suite 4 2 Structure Adopted 53 The C Verification Suite provides a simple way to verify C bi directional two wire bus This verification platform is fully compliant with version 3 0 of NXP s C Bus Specification Protocol Supports Standard Fast Fast plus and High speed operations It has a rich set of con figuration parameters to set the generation of the Serial Clock Line SCL and to configure the simulation This Verification platform also verifies all the others specifications described in chap ter 3 such as the general call address data and address integrity detects void messages illegal transitions and invalid ACK or NACK In the following sections is made a thorough examination of each of these blocks describing how they were developed how they work and how they interact in structure 4 2 1 Top Module The modules that are included in the source text but are not instantiated are called top modules This module is the highest scope of modules where all the modules are instantiated and connected Here this module is named as top module and is where C Verification Suite and all devices under verification are instantiated and connected to the 72C bus system As shown in Figure 4 2 in the top module are instantiated the bus analyzer the verification program testcase and com munication pad s In addition to these blocks are also declared in this module the int
128. vices con nected to the C bus The bus functional model class simulates a C master or slave devices connected to the PC bus This provides a way to stimulate the devices under verification The IC Verification Suite performs the SCL signal clock with the specifications defined by the user as explained above It is capable to send the device address of the device under verification or to perform the general call address The master bus functional model is capable of performing all data transfers including write and read operations at any frequency specified in the C bus specification protocol Burst mode is also supported by the verification platform in both write and read operations As said before the verification process is composed by write transfer followed by a read trans fer To perform data transfers the master slave BFM class receives data from the data generator which could be provided by the user or generated by the data generator class To verify a slave device the C Verification Suite can use different types of transfers which are One byte in a single communication Multiple communications with one byte each A single communication with several bytes several communications with several bytes each As explained before this is defined in the config class with the N_COMM parameter for the number of communications and with the N_BYTES parameter for the number of bytes When performing data transfe
129. was successfully received and can start sending another byte Once again all the SCL pulses including the pulse needed for the ACK signal 9 SCL pulse are generated by the master device 1 For the ACK signal occur the transmitter must release the SDA line during the 9 SCL pulse the acknowledge clock pulse so the receiver can pull down the SDA line and stays in LOW state during the HIGH period of the 9 SCL pulse see figure 2 6 However if during the SCL acknowledge pulse the SDA line remains in HIGH state a Not Acknowledge signal is performed figure 2 7 The NACK signal will occur if one of the following conditions is verified e The device addressed by the master is not present on the bus 2 1 PC Inter Integrated Circuit 9 e The device to which the master intends to establish a communication is not ready to receive or transmit data because is performing some other function at the same time e The receiver during a data transfer receives data or commands that it does not understand e During a communication the receiver cannot receive more information e If the receiver device is a master this needs to notify the slave transmitter the end of the transmission SDA GA ACK SDA st NACK SCL 8 9 SCL Figure 2 6 ACK signal 8 Figure 2 7 NACK signal 8 If after transfer 8 bits a NACK occurs the master can choose between generate a stop condi tion and terminate the communication with the slave or generate
130. work developed in the 2 Introduction design and verification structure using the System Verilog language to correct or minimize all the setbacks in today s verification process for a industry standard serial bus the C As a secondary goal it will be proved that it is possible to create an editable verification structure and safeguard some budget 1 1 Motivation As circuits become more complex the more capable verification tools must be These verifi cation tools must detect the maximum number of errors and flaws before the fabrication process takes place The verification process is also very important to an engineer be certain that the de sired circuit correspond flawlessly to the specifications Nowadays more electronic equipments use the C protocol to communicate internally This means that for the verification process must be created a suite to verification verify and validate the designed circuits responsible for the internal communications Although the C protocol is relatively simple when designing an integrated system that uses this communication protocol there are some potential sources of errors such as Logic violations Time violations Data loss Wrong slave address The challenge is to develop a verification suite that verifies the 72C bus communication proto col and prove that it can be an alternative to other existing platforms when verifying a PC slave IP core Addition to verify
131. yte xFAIL 373 00us T HD DAT minimal time FAIL with 0 00us Byte xFAIL 393 00us T HD DAT minimal time FAIL with 0 00us Byte of transfer 1 of transfer 1 of transfer 1 of transfer 1 E E E O of transfer 1 95 96 Final Verification Report compact version skok okokok okokookokokookookokokok okokokookokokokokookokokookookokokok okokokookokokokokookookokookokokokok k k k k kk kk k Kk Kk Kk k kk k k k k k Kk KK K K K K k KCC OH K k Kk k k k K k KK K Kk KK k K K K K K K K EEEE E E KKK OR k K K k Kk Kk k Kk k k k K k K K K K K FO ko KKK kkk k kkk kkkkkk Final Result xkxokokokokokokokokokokokokokokokokokokokokokokokokokokok k skok kok skok K K k KK k kk K k KK K Kk KK k K K K K K K K EEEE E E KKK k k KK K Kk KK k Kk k K k K k K K K K K BRR HEHE DR KKK OK EEE EEE DR R DR DRE OR ROK KKK E E E E E E E E k k k k E KKK RK Kk Kk k kk k k k k k Kk KK K K k K k xokokokok eo o ok KK KK Total errors 7 gt kokokokok xokokokok ok KK ok KK ok KK kK KK Verification FAIL dokokekok ok KK ok KK ok KK ok KK kokokokok Total Errors in Write Mode 2 ek KK KKK kk KK Kk k KK KK I2C data transferred errors 0 2K KKK DEE EES I2C Specification Standard errors 2 DEE EES KKK kk dokokokok ok ok KK kokokokok Total Errors in Read Mode 5 ek KKK eK KKK KKK kK I2C data transferred errors 0 KK KK DEE EES I2C Specification Standard errors 5 DEE EES ok KK ok KK ok KK ok KK ok KK ok KK Total simulat

I C Verification Suite - Repositório Aberto da Universidade do Porto

Contents

Download Pdf Manuals

Related Search

Related Contents

I C Verification Suite - Reposit&oacute;rio Aberto da Universidade do Porto

Contents

Download Pdf Manuals

Related Search

Related Contents

I C Verification Suite - Repositório Aberto da Universidade do Porto