An Ad-hoc IP Functional Verification Procedure A.K. Oudjida, D. Benamrouche, R. Tiar, M. Goudjil, A. Liacha Centre de Développement des Technologies Avancée (CDTA) Algiers Email :
[email protected]:
Abstract— This paper presents an ad-hoc IP-verification procedure used to verify the conformity between the IP specifications and their corresponding HDL-code implementation. The verification procedure is a general purpose solution offering automatic way to validating any IP design. The purpose of this paper is to provide a full description of the verification procedure and how to tailor it in order to fit any particular needs. For a good illustration of the procedure, an I2C-slave-transceiver core is chosen for verification. The Ad-hoc verification procedure has been used to validate several designed IPs. The whole procedure code is implemented in both Verilog 2001 (IEEE 1365) and VHDL (2002).
This paper deals with a fully automated ad-hoc FV procedure. For clearer illustration of the proposed method, a medium complexity core “I2C-slave transceiver” is chosen as DUT, but the verification procedure is general purpose and hence can be applied for the verification of any IP, whatever its complexity. All relevant issues either at concept level or at implementation level (scripts) are thoroughly commented through a set of examples and figures, making the whole FV procedure easily reproductible. The paper is organized as follows: In this section we outlined the weight of the FV process in the design cycle. Section 2 makes a brief description of the I2C-slave-transceiver core. Section 3 provides a detailed description of our ad-hoc verification procedure. And finally some concluding remarks.
Keywords— Intellectual Property (IP), System-on-Chip (SoC), ASIC/FPGA design, Functional Verification (FV).
II. I2C-SLAVE-TRANSCEIVER
I. INTRODUCTION
F
unctional Verification (FV) is a process used to demonstrate the functional correctness of a design. More precisely, FV verifies that all design features included in the specification document are correctly implemented. It’s noteworthy that FV process can only show that the design meets the intent of its specification, but in no case it can prove it. In other words, FV can easily prove that the design does not implement the intended function by identifying a single discrepancy (presence of bugs), but it can not prove that there are no discrepancies (absence of bugs). Today, in the era of multi-million gate ASIC, reusable Intellectual Property (IP), and System-on-a-Chip (SoC) designs, FV consumes about 70% of the design effort and the code that implements the testbenches makes up to 80% of the total code volume [1]. Thus, FV becomes the most challenging task the design engineers are confronted to. Given the amount of time and effort demanded, FV has been the target of new tools and ad-hoc methodologies which attempt to reduce the overall verification time by enabling parallelism of effort, higher levels of abstraction, and especially through the use of automation whenever possible [1].
Based on a recent market study of an important number of I2C devices[8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21], all fully compliant with the Philips I2Cbus specification, version 2.1, release January 2000 [2] [3] [4] [5], we developed a new I2C-slave VLSI-architecture (figure 1.) [25] that incorporates all necessary features required by modern ASIC/SoC applications, except high speed mode. The design is a general purpose solution offering practical ways to controlling I2C-bus and highly adaptable to suit any particular requirements. For the purpose of this paper, only the filter unit will be dealt with for the presentation of our ad-hoc verification procedure. We used a noise filter in our I2C core [25] to guarantee high noise immunity in case of motor system applications. The two I2C lines (SDA & SCL) are first passed through a Schmitt trigger (PAD level) and then passed to a digital filter unit. The result of this circuitry is that pulses shorter than a certain user-defined-number of CLK periods are considered as noise spikes and are automatically ignored. When the filter unit is disabled (ENFU = "0") or iic_filter_reg content is equal to zero (reset value), the two I2C lines pass directly without being filtered. Example: CLK=50MHz Ù CLKT = 20 ns, and ENFU="1". If we consider that pulses shorter than 60 ns are considered as noise-spikes to be rejected, the value (60/20)=3 must be put into the iic_filter_reg.
low_wate nfull high_wate nempty Data Low-Level I2C Noise Filter Unit Unit Slave Protocol Unit iic_tx_data_reg
iic_rx_data_reg
SDA_low
digital filter
sda
address/data IO shift register
iic_filter_reg
iic_address_reg
digital filter
scl SCL_low
Transmitter-FIFO
Control Unit
Receiver-FIFO
iic_tx_no_reg
FSM
iic_tx_low_water_reg
clk
iic_tx_timeout_reg
iic_control_reg
iic_rx_no_reg
iic_status_reg
iic_rx_high_water_reg
iic_recover_reg
iic_rx_timeout_reg
nreset
Host Side Interface Unit
iic_timeout_now_reg iic_trans_status_reg
2
Figure 1. I C-Slave-Transceiver Block Diagram
III. OUR AD-HOC FV PROCEDURE In order to ensure a first-time-success, i.e. that the implemented design fully meets the initial specifications, the design has undergone two types of verifications: at core level (cycle accurate test bench) and at board level (Csoftware test bench.) A. Core Level Verification Each unit of the architecture is tested separately. First, each unit is challenged against a set of severe special cases (verification plan,) and then against a very large number of random patterns. Once all units tested successfully, the same test process is repeated for the whole IP core. For special cases, we identified some of severe features that must be exercised under some drastic conditions along with their respective response, whilst random test has been used to create conditions that we have not thought about when writing our verification plan. Random verification does not mean that we randomly applied zeroes and ones to every input signals in the design. This would not represent an accurate usage of the design and would not accomplish anything. On the contrary, the inputs are subjected to valid individual operations, such as a read cycle, or data frame transmission/reception. It is the sequence of these operations and the content of the data transferred that is random. For ease of verification, a fully automated verification procedure (self-checking HDL test bench) is used (Figure 2.) For this purpose, we used Unix Gawk tool to generate a parametrizable number of random-pattern files, which are submitted to both the synthetisable RTL code and to the behavioural test bench code for simulation (behavioral versus RTL thinking.) The reason behind using behavioural
cs
Register-address decoder
8
8
rw 5
din dout adr
style is that less effort is required to insure that the code is correct. The simulator Modelsim, which runs in batch mode, performs a comparison between the delivered results and issues an error if any. In case of error, the Tcsh process (figure 3.) is stopped and a visual simulation (wave mode) is performed on the responsible pattern-file (figure 4.) to localise the bug. In case of no error, the whole process is reiterated using Tcsh (Unix shell tool.) script. B. Board Level Verification The hardware (evaluation board) used for the SoC application is represented by the PCB of [24]. The system includes an ARM9TDMI as central 32-Bits CPU and different standard IO ports like 10/100 Ethernet and USB 1.1 together with a standard memory bus connecting SRAM, SDRAM and FLASH to the CPU. A free programmable FPGA for the implementation of approx. 30 000 gates allows any additional digital I/O interface. The system runs under a mini Real Time Operating System. A standard ARM based software development toolkit (assembler, compiler, debugging tools etc...,) is applied to the system. Concerning simulation of the total system, all modules are available in a common data base as HDL file or PLI file (for ARM9TDMI) as well as at the gate net list level, in a readable or encrypted version. This system has been used to validate our designed IPs (FIFO, Transceiver, I2C) core at board level. We wrote a C interrupt–driven application using nempty and nfull interrupts that verifies that the frame-transfers between a software FIFO and our I2C transceiver FIFO are correct. To make the C application independent from the hardware, drivers have been developed.
Modelsim Gawk Behaviora Testbenc Code Random Patter File
Comparison Syntetisabl
RT Code
Erro Fil
Ye
Visua Simulation
No
Tcsh
Fig. 2. Automated Verification Procedure #!/usr/bin/tcsh -f cd $PRJ_HOME/IIC_SLAVE/FILTER/sim ../bin/makecomp # set parameter set no_errors = true set no_iteration = 0 set width = 9 set ln = 20 set fn = 4 while ( "$no_errors" == "true" ) rm -rf wlf* #if ( -f ./sim_data/*.ctrl ) rm -rf *.ctrl gawk -v WIDTH=$width -v LN=$ln -v FN=$fn -f ../bin/rand_sig_gen.awk vsim -c -quiet -lib v_lib v_lib.filter_tb -do wave.do grep 'MISMATCH' ./sim_data/report.out if ( "$status" != "0" ) then rm -rf ./sim_data/*.out else echo "### ERRORS FOUND" set no_errors = false endif set no_iteration = `expr $no_iteration + 1` set no_samples = `expr $no_iteration \* $fn \* $ln` echo echo "#################################" echo "ITERATION NUMBER : " $no_iteration echo "NUMBER OF SAMPLES : " $no_samples echo "#################################" echo end Note: width = pulse size of the input signal (Sig) of the filter ln = (line number) number of pulses par random pattern files fn = (file number) number of random pattern files per one batch mode simulation run
Figure 3. Tcsh script
SIG 5 5 2 3 5 2 1 1 8 7 4 5 6 3 2 2 9 4 3 8 Figure 4. Random Pattern File for Filter Unit
IV. CONCLUDING REMARKS FV is indispensable. To be marketable, a design must be functionally correct and provide features that the customer requires. But FV always takes at least twice as much effort as the design itself. This is why FV is currently the target of new tools and methodologies, which attempt to reduce the overall verification time by enabling parallelism of effort, higher levels of abstraction and automation [1]. Throughout this paper, we presented a self test ad-hoc FV procedure mainly based upon automation, allowing faster and predictable results. However, despite the generalpurpose character of our FV procedure, automation requires standard processes with well defined inputs and outputs. Not all processes can be automated because of the variety of functions, interfaces, protocols and transformations. In such a case, it is always possible to use our ad-hoc FV procedure to automate some portion of the verification process, especially when applied to a narrow application domain.
REFERENCES [1] Janick Bergeron, “Writing Testbenches, Functional Verification of HDL Models,” Kluwer Academic Publisher, Copyright 2001. [2] Philips Semiconductors, “The IIC-Bus Specifications,” version 2.1, January 2000. www.6502.org/miniprojects/dpod/dpodfiles/I2C_BUS_SPECIFICATION_3.pdf [3] J.M. Irazabel & S. Blozis, Philips Semiconductors, “IIC-Manual,” application note, ref. AN10216-0, March 24, 2003. www.cpdee.ufmg.br/~diogenes/pse/I2C/Philips-i2c-AN10216_1.pdf [4] Philips Semiconductors, “IIC Logic Selection Guide, Advanced IIC Devices: Innovation in a Mature Technology”, www.semiconductors.philips.com/acrobat_download/literature/9397/75013239.pdf version 2.1, January 2005. [5] Philips Semiconductors, “I2C Bus Solutions” February 2004. www.semiconductors.philips.com/acrobat_download/literature/9397/75012744.pdf [6] C. Diou, Université de Metz metz.fr/IMG/pdf/Cours_Bus_I2C.pdf
“Introduction
au
Bus
I2C,“
www.licm.sciences.univ-
[7] J. Francomme, Lycée technique Louis Armand, “Le Bus I2C,“ ver. 1.1, March 2002. membres.lycos.fr/jackece/presentation_I2C.PDF [8] Infineon Technologies AG, “Hardware IIC-Bus in Slave Mode by Using Polling and Interrupt Methods,” application note, ref. AP16045, V 1.0, Feb. 2004. www.infineon.com//upload/Document/cmc_upload/documents/010/021/Ap1604510_Hardware_I2C-bus.pdf [9] Fraunhofer Institut Integrierte Schaltungen, “CorePool FHG_I2C Databook,” version v1.4, June 2002. www.corepool.com/products/databook/fhg_i2c.pdf [10] Xilinx Inc.“IIC Bus Interface Design Specification,” version v1.01a, December 2001. www.xilinx.com/ipcenter/processor_central/processor_ip/iic/opb_iic.pdf [11] Philips Semiconductors, “PCF8584 I2C-Bus Controller,” data sheet, October 1997. www.xilinx.com/ipcenter/processor_central/processor_ip/iic/opb_iic.pdf [12] Atmel Cor., “Using the TWI Module as I2C Slave,” ref. AVR311, October 2004. www.atmel.com/dyn/resources/prod_documents/doc2565.pdf [13] Cast Inc., “Slave Bus Controller Megafunction,” 2004. www.altera.com.cn/products/ip/ampp/cast/documents/m-casi2cs.pdf [14] Altium Limited, “I2CM Controller,” ref. CR0105, ver. v1.2, December 2004. www.altium.com/files/learningguides/CR0105%20I2CM%20Controller.pdf [15] Richard Herveille, “I2C-Master Core Specification” ver. 0.9, July 2003. www.opencores.org/cvsweb.shtml/i2c/doc/i2c_specs.pdf [16] C-Logic Semiconductors, “I2C-Master and Slave Controller,” www.clogicindia.com/chipI2C.pdf [17] Lattice Semiconductor Cor., “Designing an I2C Master Controller,” ref. RD1005, July 2005. www.latticesemi.com/lit/docs/refdesigns/rd1005.pdf [18] Digital Design Core, “I2C Bus Interface – Master” ver. 3.07, 2004. www.dcd.pl/dcdpdf/alt/di2cm_ds.pdf [19] Digital Design Core, “I2C Bus Interface – Slave” ver. 1.14, 2004. www.dcd.pl/dcdpdf/alt/di2csb_ds.pdf [20] Altera Cor., “I2C Master Interface Megafunction,” ver. 1, June 1999. www.altera.com/literature/sb/sb039.pdf [21] Altera Cor., “I2C Slave Interface Megafunction,” ver. 1, June 1999. www.altera.com/literature/sb/sb040.pdf [22] R. Usselmann, “OpenCores SoC Bus review,” revision 1.0, January 2001. www.opencores.org/projects.cgi/web/wishbone/soc_bus_comparison.pdf [23] A.K. Oudjida & al, “Master-Slave Wrapper Communication Protocol: A Case Study,” Proceedings of the 1st IEEE International Computer Systems and Information Technology Conference ICSIT’05, pp 461-467, 19-21 July 2006, Algiers, Algeria. [24] MAZ Brandenburg GmbH,”ELPEC3 – Low Cost Microcontroller for Industry Automation,” July 2003, Berlin, Germany. www.mazbr.de/frames/products.html [25] A.K. Oudjida et al, “Universal Low/Medium Speed I2C-Slave Transceiver: a Detailed VLSI Implementation,” Proceedings of IEEE design and test of Integrated Circuits Conference DTIS’06, 4-7 September 2006, Tunis, Tunisia
