Title: Emulation Testing Methodology FPGA Prototyping Author: S.Ramakrishna Rao Email: Ramakrishna.soogoori@wipro.

com Theme: This paper describes emulation testing methodology and FPGA prototyping for the hardware IP core designs. It also explains advantages and limitations of emulation testing. Emulation Testing Methodology FPGA Prototyping

Purpose of this paper is to discuss emulation testing methodology for developing IP cores and achieving first time silicon success. System level and stand alone test benches cannot simulate some of the r eal time conditions. This paper gives various aspects of emulation platform development and testing. It also discusses advantages and limitations associated with it. OHCI_1394 and WCDMA projects are used as case study. System level test bench is useful for developing test cases, which exercise vari ous logic portions of IP core logic in a controllable manner. Basic functionality testing and good code coverage is possi ble. Still this soft testing does not provide required confidence to go for ASIC directly, because few of the real tim e situations are not simulatable. To achieve more confidence it requires hard testing or real time hardware testing. Th is requires emulation platform development for the IP and test it with real time operating conditions. Emulation Platform Development Considerations: Emulation board development has to be started during the early stage of developm ent of IP core. It is necessary to get a fair idea of the final IP gate count, and it is key to choose FPGA. Multiple FPG As are also required depending up on the size of the IP. Complete system level knowledge is necessary for developing emul ation board. Good anticipation for accommodating extra logic is required and FPGAs must be chosen accordingly. Enou gh number of debug ports (mictors) are required to capture various signals using Logic Analyzer. Other useful consi derations would be FPGA configuration mechanism, LED status/error indicators, DRAM, FLASH, serial interface, switches etc. System bus (PCI or ARM..etc) plays important role in designing the emulation board. When logic is very huge, multiple FPGAs may also be needed to accommodate entire logic. In the synthesis perspective, important considerations would be the interconnections between the FPGAs. Variou s signals those connect between different FPGAs are to be properly taken cared. Signals must be registered at le ast at one place (either at origination or at destination) so that timing is met across the FPGAs. Implementing FPGA (Synthesis and PAR): This phase involves carrying out multiple rounds of FPGA synthesis and Place and Route (PAR). To meet the FPGA timing, long timing violations needs to be corrected in the RTL. It also require s identifying false paths and multi-cycle paths in the design, which helps in avoiding few timing violations to be reporte d. The process involves several iterations of correcting RTL, synthesis and PAR. Automated synthesis and PAR scripts would be required to minimize manual

interaction for managing the scripts. This process needs to be carried out each time whenever (1) RTL design is update d with new piece of code and logical release is done (2) Any functional bug fixes are done (3) Long timing paths in t he RTL are corrected. Refer to figure1 for emulation testing flow. Automated scripts are also required for converting ASICRTL to FPGA specific RTL. Because, memory instantiation, debug ports and few other items are specific to FPGA RTL.

FunctionalbugsFPGA timingerrorsModified RTLModifiedRTLBugs caughtin emulationtestingFunctionaltesting OKEmulation testing OKRTLSpecification System Design Architecture RTL developmentTest Bench development FPGA Emulation Platform development RTL Bug fixes and Timing fixes Functional bugs FPGA timing errors Functional Testing FPGA Synthesis & PAR Modified RTL Modified RTL FPGA Emulation Testing Bugs caught in emulation testing ASIC synthesis & Backend Functional testing OK Emulation testing OK RTL FunctionalbugsFPGA timingerrorsModified RTLModifiedRTLBugs caughtin emulationtestingFunctionaltesting OKEmulation testing OKRTLSpecification System Design Architecture RTL developmentTest Bench development FPGA Emulation Platform development RTL Bug fixes and Timing fixes Functional bugs FPGA timing errors Functional Testing

FPGA Synthesis & PAR Modified RTL Modified RTL FPGA Emulation Testing Bugs caught in emulation testing ASIC synthesis & Backend Functional testing OK Emulation testing OK RTL E EEm mmul ulula aat tti iion onon t ttes esest tti iin nng gg f ffl llo oow ww Figure1. Emulation testing flow Emulation phase Emulation Testing: Emulation testing can be started when IP has developed to logical stage from whe re definite functionality is achieved. Incremental logical additions can be done later on. Initially diagnostic tests c an be performed to exercise fundamental functionality like register read/writes, basic packet transmission & reception e tc. It is very likely that fundamental bugs/issues can be found at this stage of testing. After resolving and fixing th ese bugs next level of testing is carried out.

Now actual system/host can be used for real time testing. These tests depend upo n IP s functionality. In the case of OHCI_1394 following tests have been carried out. 1. Isochronous tests. It basica lly transmits and receives video/audio data. 2. Asynchronous tests: Winthrax, HCT etc. These tests do secured data tran sfers between various hard drives and the OHCI. Bugs that are found in system testing will be of random nature and ver y difficult to recreate in controlled environment (test bench). Each bug has to be carefully narrowed down by looking at required signal transitions and analyzing the root cause. Each bug is fixed in the RTL and re synthesized and em ulation has to be carried forward. Sufficient internal number of signals has to be connected to debug port as they can be analyzed using Logic analyzer. Figure1 Gives Emulation testing phase and its impact on actual IP development. Emulation Limitations: Basic emulation limitations are due to FPGA timing problems. This again depends upon the IP architecture and clocking frequency. The ideal way of FPGA implementation without any timing errors is dep endent on RTL design methodology and designed with the FPGA point of view. Again design has to be balanced betwee n ASIC and FPGA. If the design drifted more towards ASIC, then FPGA timing can cause serious emulation limitati on. As in the case of OHCI_1394 which is targeted for ASIC, 80 % of logic is operated at 33 MHz pci clock and 20 % of logic is operated at 50 MHz link clock. When OHCI_1394 is synthesized to XCV3200E Xilinx Virtexe device, pci clock was m et 20 MHz and link clock was met 34 MHz. To overcome this timing, host PC made to run at lower frequency of 20 MH z. But Link clock can not be altered, which is supplied by 1394 PHY. Reduction of pci clock frequency resulted in less pci bandwidth. To compensate for link timing errors, all packet transfers are made to 100 Mbps (Max is 400 Mbps) on th e 1394 bus with the assumption that critical timing paths will not be exercised at lower operating(speed) mode. Sinc e pci clock is reduced and link clock is kept unchanged, some performance degradation is expected. In the transmit side more p acket under runs and receive side more packet over runs are expected. Emulation advantages: Provides real time environment for IP core testing Real time testing environment can never be simulated using conventional test ben ch approach. Emulation environment is very fast than traditional test bench. This can be high ly appreciated and if any simulation has to be carried for 10 minutes time duration. In this case conventi onal test bench will be very much slower than emulation environment. Conventional test bench might take even several hours for simulating 10 minutes of time. Emulation environment obviously proves its upper hand in simulating larger time duration.

Testing will be very faster, e.g. for RF communication applications where system has to be run in real time. Normal simulation will be helpful only up to few microseconds of time in real ti me duration. Critical bugs can be found, which may not be possible to hit with conventional t est bench simulations The bugs, which are caught in emulation testing, can be fixed and tested in emul ation environment, as FPGAs are programmable with new fixed RTL. Provides confidence to go for ASIC and results in first time silicon (ASIC) succ ess. Conclusion: IP core architecture and FPGA friendly design are the key things for developing successful FPGA emulation platform Emulation platform development must take place in the early stage of IP design a nd must be synchronized with intermediate logical IP deliveries. Late development of emulation platform might cause serious and critical architec tural modifications if the FPGA timing is not met. Automated synthesis and PAR scripts can be efficiently executed for smoothening the emulation testing flow Automated scripts for generating FPGA specific RTL from the main ASIC RTL stream are required. Sufficient number of internal signals to be connected to the external debug port s so that the internal signals can be analyzed using Logic analyzer for analyzing the bugs. The bugs, which are caught in emulation testing, have to be fixed in RTL. The ne w RTL with all bug fixes should pass both the conventional (functional) testing and the emulation testing . In the same way the bugs which are caught in conventional testing are have to be fixed in the RTL and the modified RTL with the bug fixes should pass both functional testing and emulation testing.