Debugging of FPGA based Prototypes - A Case Study

Transcription

1 Proc. Design, Automation and Test in Europe Conference, Designer s Forum, München, , pp Debugging of FPGA based Prototypes - A Case Study Rainer Ulrich 1, Wolfgang Grafen 1, Jürgen Haufe 2, Jens Grosse 2 1 Marconi Communications GmbH, Germany 2 Fraunhofer Institut für Integrierte Schaltungen, Germany Abstract Reduced product cycles and stringent time-to-market requirements in spite of growing complexity make faster verification of System on Chip (SoC) mandatory. FPGA prototypes are used to achieve this, but debugging the system gets more difficult with growing size of the FPGAs due to decreasing observability. A debugger was developed which couples the prototype hardware with simulator software. The aim is to test the system or its modules in the real environment and still be able to reproduce the tests in the simulator. This paper describes in a case study the application of the debugger in real telecommunication designs. 1. Introduction The classical verification methodology relying on simulation offers excellent debugging support and short turnaround times in case of a malfunction. So modifications and "what if..." analysis are quickly done. On the other hand the environment in which the device works has to be created. The development of the testbenches for a design requires nearly as much time as the development of the design itself and is error prone. Most trouble usually arises from misunderstanding the interactions between device under test (DUT) and system. In addition simulation is slow and exhaustive testing may not be feasible because of long run-times. Therefore either emulation or prototyping with FPGAs is used, which allows verification at real-time or at least at a vastly increased speed. If a certain minimum speed can be achieved, it is also possible to verify the device in its already existing environment. This removes the time consuming and error prone task to model the environment. A drawback common to both is the long turn-around time for larger designs in case of a malfunction because after every change a new synthesis and place-and-route is necessary. Emulation using commercially available systems offers relatively automatic usage and good support for debugging the design, but they are expensive and sometimes too slow (up to several MHz) for real-time applications [1]. FGPAs have now reached a complexity and performance which makes their use for prototyping and speeding up the verification process in telecommunication applications possible. The main drawback of FPGA based rapid prototypes is their missing support for debugging. In classical real-time hardware debugging approaches, the hardware behaviour is observed using logic analysers or oscilloscopes connected to externally accessible I/O pins or probe pins of the DUT. Hardware internal nodes are usually accessed by routing them to external pins which are not used by the DUT. Because of the limited number of unused external pins, only a small number of signals may be traced by that technique. FPGA vendor specific solutions offer only a limited scope of up to 256 nodes [2],[3]. In order to remedy this problem a design and technology independent debugger was developed, which tightly connects FPGA based prototypes with any desired simulator [4]. 2. Description of the debugger RAM 36 HW Controller 42 HW Kernel 7 Shadow Cells Breakpoint DUT 6 Host Interface Simulator Logic Analyser System Environment Figure 1. Debugging Environment The debugger traces all internal registers of the DUT 109

2 frequently and non-intrusively while the circuit is running at speed. The traced data are stored in a RAM to be downloaded into a host computer for a detailed analysis (trace mode). Alternatively the debugger allows loading data from the simulator simultaneously into all internal registers of the DUT (update mode) in order to achieve a certain state which is otherwise difficult to reach. In order to make this possible the registers of the DUT are replaced by shadow cells consisting of some combinatoric and two flipflops. The second flipflops of all shadow cells are lined up as a shift register to output the content to the RAM or to read data from the RAM without any feedback to the system. Additional control and interface logic is added to the DUT and connected (figure 1). To minimize the impact on the board design the debugger allows the user either to integrate all of its components into the DUT as a debugger core or to keep most of its components off-chip on a separate debugger device. [4] A complete reproduction of a test in the simulator also requires that the input data has to be sampled continuously between two trace events of the debugger if the inputs are not reproducible. For simplification we currently use a logic analyser to meet this task. 3. Prototyping flow 3.1 Flow without debugger The following flow is usually applied to develop FPGA based prototypes: Cause found? Debug in HW Cause found? Debug in SW Start Write/Modify code Simulate code Analysis & Synthesis Place & Route STA Program FPGA(s) Verify in system STA: static timing analysis Proceed to ASIC developement Figure 2. Prototyping Flow w/o Currently the simulations tend to be quite long due to the lack of FPGA debugging support. The engineers prefer to verify the code nearly completely by simulation instead of doing only a basic verification, thereby losing the advantage of the higher verification speed of FPGAs. The debugging of the FPGA(s) ( Debug in HW in figure 2) requires the most time. Because of the reduced observability of FPGAs usually several trials are necessary before the engineer is even able to inspect the correct signals which show the cause of the malfunction. Alternatively the engineer can try to reproduce the failing tests in the simulator. This is very time consuming because of the low achievable simulation speed and the effort to generate identical stimuli with system clock cycle exact timing, especially if the DUT contains feedback loops. Also the HW introduces additional possible sources of errors like physical defects of the board (interrupted or shorted traces) or faulty or undocumented behaviour of HW components which can t be detected by simulation. An iterative approach by refining the code piecewise in order to get easier to debug logic is not feasible due to the long turn-around times involved. 3.2 Flow with debugger When using the debugger the flow remains basically the same, only synthesis and the debugging of the FPGA(s) 110

3 differ: Cause found? Debug in SW Load test run data into simulator Start Write/Modify code Simulate code Analysis & Synthesis Place & Route STA Program FPGA(s) Verify in system STA: static timing analysis Proceed to ASIC developement Figure 3. Prototyping Flow with The analysis & synthesis step is shown in detail below: } Synthesis Tool Analysis Presynthesis Synthesis w/o timing Find registers } Replace regs by shadow cells Insert + Connect debugger logic Synthesis with timing Place & Route Tool optional Insertion debugger specific scripts Figure 4. Synthesis Flow with debugger Instead of having the debugger automatically searching and replacing all registers, the user can alternatively define the registers to be replaced himself. Depending on the complexity of the DUT a first verification by simulation may still be done. This serves to catch and correct the obvious bugs as fast as possible and to gain confidence that the design works as intended before investing time in long synthesis and place-and-route runs. In this phase only short simulations should be used and no model of the environment is required. The exhaustive verification is done using the FPGA prototype in the system. The debugger working in trace mode periodically samples the internal registers of the DUT and stores them in its RAM. In case of a malfunction the debugger is stopped. The failed test now can be exactly reproduced in the engineer s preferred simulator in order to analyse there the behaviour of the DUT. This is done automatically by calling a script after the simulator s initialization. This script forces all the internal signals of the DUT s model, which represent registers in the FPGA, to one of the trace vectors stored in the debugger s RAM. Then the input data stored by the logic analyser are applied to the DUT model. Because the model is preset immediately to an internal state traced by the debugger, only the time from this tracing event up to the occurrence of the malfunction must be simulated. This results in significant reduction of simulation time, if the malfunction occurs late in a test. The update mode enables the engineer to force the DUT hardware easily into desired states which are otherwise only reached after many clock cycles and applying complex input patterns, enabling thus quick what if... analysis. For the engineer using the debugger only means calling additional scripts which can easily be included as an option in existing flows. 4. Application Besides the different verification strategy, the debugger mainly influences the time needed for synthesis and the performance of the DUT. Its impact on the simulation s performance is minor because the only difference to simulations without debugger is the initialization of the DUT s model at the begin of the simulation. The time needed for debugging also depends too much on the specific problem to make meaningful comparisons. Therefore this chapter concentrates on the impact of the debugger on synthesis and performance of the modules. Currently, Marconi Communications is developing an ASIC for an advanced version of its digital point to multipoint system (MDMS) containing data processing in the frequency domain, Reed-Solomon channel coding, DES data encryption and dataintensive communication with external components as DSPs, a microcontroller and a SmartCard. Most modules of the ASIC operate with 52 MHz clock frequency. In order to evaluate the impact of the debugger several modules of our MDMS application were selected: 111

4 SCI: The first module is an ISO/IEC SmartCard interface. The main problem in this case is not the length of the simulation but the correct modeling of the environment. Exact models of the SmartCard are not easy to obtain because of the vendors reluctance to reveal the internal data processing due to security considerations. The vendors offer samples of their SmartCards as hardware, but a minimum clock frequency of at least several MHz is required for the communication with it to prevent fraud. E1IF: The second module is an ITU G.706 E1 interface including framing/deframing and a performance quality management. This interface needs long simulation runs (1 sec up to 15 min real-time when applying input data at 2 MHz data rate). OMUX: The third module is a filter structure to add two channels in the frequency domain. This module represents a typical telecommunication application and serves as an example for modules consisting nearly exclusively of arithmetic functions. We overconstrained the designs in order to have meaningful comparisons of the results. Otherwise the tools would simply stop when the requirements are fulfilled and the performance achieved would be incidental. The target was an ALTERA EPF10K250AGC599 FPGA. The synthesis tool was Synopsys Design Compiler version and for place-and route Altera MAXPLUS2 version 9.6 was used. A Sun Ultra 2 host was used for the evaluation. For each module 3 variants were investigated: First the plain DUT, then the DUT plus shadow cells only (+ S) and last (+ D) the DUT plus all design dependent modules of the debugger (HW debugger kernel in figure 2). A dedicated debugger FPGA plus external RAM devices were used for those parts of the debugger which are invariant regarding to the DUT. This is the preferred variant because there is no need to rerun the synthesis of the dedicated debugger FPGA if the DUT design changes. The dedicated debugger FPGA contains 352 flipflops and requires 1184 LCs. Design Synthesis P&R Total SCI 13 min 11 min 24 min SCI + S 53 min 22 min 75 min SCI + D 59 min 15 min 74 min E1IF 340 min 88 min 428 min E1IF + S 488 min 85 min 573 min Table 1: Impact on Implementation Time Design Synthesis P&R Total E1IF + D 404 min 216 min 620 min OMUX 39 min 86 min 125 min OMUX + S 232 min 211 min 443 min OMUX + D 182 min 224 min 406 min Table 1: Impact on Implementation Time The following table shows in more detail where the time is spent when inserting the debugger: Design Presynthesis FF Detection Insertion SCI + S 5 min 1 min 47 min SCI + D 8 min 2 min 49 min E1IF + S 136 min 10 min 342 min E1IF + D 134 min 10 min 260 min OMUX + S 18 min 6 min 208 min OMUX + D 21 min 7 min 154 min Table 2: Detailed Times for Synthesis The strange fact that the OMUX needed less time when the complete debugger was included than with shadow cells only is due to the heuristics used by synthesis tools. A different input, even when larger, can sometimes result in a shorter run-time because of a different starting point. The dramatic difference in time required for place-androute between E1IF + S and E1IF + D could be reproduced. It appears that the additional time spent for the final synthesis in variant E1IF + S compared to E1IF + D results in an faster to implement netlist. Also the time spent longer for place-and-route in design E1IF + D resulted in better performance than the other variants. The increase of synthesis time when integrating the debugger in the SCI or E1IF is acceptable to us. Especially in case of the E1IF the required time falls always into the overnight gap : it is too long to wait for the result during the usual working hours but it s available at the next morning. The large impact on implementation-time in case of OMUX is due to the fact that this module consists almost entirely of arithmetic. The FPGA synthesis tool recognizes this and uses FPGA vendor proprietary cores which also 112

5 include placement information. After insertion of the debugger, the synthesis tool has additionally to implement combinatorical logic between the flipflops. This slows down the process. In the following table the performance achieved in the implementation runs listed above is shown. In order to understand the impact of the debugger on the performance of the designs better, for each design an additional version (+ T) was introduced. In this version only the tracing of the internal registers is possible. Contrary to the full debug version (+ D) in this case no additional logic is inferred into the functional datapaths of the DUT. The second column of the table lists the number of flipflops in the functional core of the design which are to be replaced by shadow cells. The next column shows the total number of flipflops in the design including those of the debugger parts. Design core FFs total FFs Area in LC FPGA Usage Fmax in MHz SCI % 23.8 SCI + S % 18.2 SCI + T % 17.6 SCI + D % 18.1 E1IF % 8.0 E1IF + S % 8.4 E1IF + T % 8.9 E1IF + D % 9.2 OMUX % 15.8 OMUX + S % 15.8 OMUX + T % 15.8 OMUX + D % 15.8 Table 3: Performance of the modules Module SCI was in all variants constrained with 20 MHz, the other modules with 16 MHz. The number of core flipflops in the second row is lower for the designs without debugger, because in this case the synthesis tool can remove surplus flipflops. After shadow cell insertion these flipflops are no longer surplus because they feed data into the second flipflops of the shadow cells. For the designs with shadow cells only (+ S) the total number of flipflops is slightly more than double the core flipflops because additional flipflops are appended to the shadow cell chain in order to make the total number of flipflops in the chain a multiple of 16. This is required because the HW debugger stores 16 bit simultaneously into its RAM. When comparing the achieved speeds one should consider that in FPGAs the performance is dominated by the interconnection delays. Because of the heuristics used during placement, even the performance of the same design can differ about 1 MHz depending on the starting points of the place-and-route process. During prototyping area is not a concern up to a point. A certain overhead up to 50% is suggested in order to stay flexible for further changes. The achieved performance of the E1IF is still high enough to apply the input data at real-speed (2 MHz) using a system clock scaled down to 8 MHz. The quality management tests are performed at real-time by adjusting the counters for measuring the time intervals to the reduced system clock rate. When verifying those counters a test requiring 15 minutes real time when using a 52 MHz system clock takes 97.5 minutes due to the scaled down system clock (in either case the same number of clock cycles must be applied to the DUT). To give a comparison: On a Sun Ultra 2 host the simulation of about 400 ms real-time using the same reduced system clock takes about 9 h. In all cases the trace only version (+ T) has no noticeable impact on the performance. This is because in the selected examples the additional logic needed for the update mode fitted well into the existing hardware structures predefined by the FPGA architecture. 5. Conclusions This paper has described the application of a debugger for FPGA based prototypes in real telecommunication designs. The debugger was successfully applied to modules containing 3 to 8 times the number of registers currently supported by FPGA vendor specific solutions [2],[3] with minimal impact on the performance of the modules. The debugger has reached a stage where it can be applied to functional units in our applications. Especially if these units require long simulation runs or if their environment is already available in hardware, the debugger is used with advantage.for larger designs we currently suggest not using the debugger for the whole design but only for parts of it in 113

6 order to reduce the necessary overhead. In the future, we will evaluate the integration of dedicated FPGA synthesis tools further. We will also investigate how to speed up the flow and to overcome the current limitations of the debugger: synchronous DUT designs with maximal two clock domains, I/O signal trace using a logic analyser and embedded RAM as yet unsupported. Acknowledgments The authors would like to thank MEDEA for sponsoring this work within the research program European Intellectual Property in Designing Electronic Systems (EURIPIDES). 6. References [1] Ch. Fritsch, J. Haufe, Th. Berndt: Speeding Up Simulation by Emulation - A Case Study. in Design, Automation and Test in Europe Conference, Munich 1999, User Forum, [2] chipscope_ila_um.pdf [3] [4] J. Haufe, Ch. Fritsch, M. Gulbins, V. Lück, P. Schwarz: Real- Time Debugging of Digital Integrated Circuits. in Design, Automation and Test in Europe Conference, Paris 2000, User Forum,