SoC Design Environment with Automated Configurable Bus Generation for Rapid Prototyping

Transcription

1 SoC esign Environment with utomated Configurable Bus Generation for Rapid Prototyping Sang-Heon Lee, Jae-Gon Lee, Seonpil Kim, Woong Hwangbo, Chong-Min Kyung P PElectrical Engineering epartment, KIST, aejeon, Korea [shlee, jglee, spkim, woonghb]@vslab.kaist.ac.kr kyung@ee.kaist.ac.kr bstract It is important in SoC design that the design and verification can be done easily and quickly. nd RT-level simulation in verification methods is still necessary, but the usage is limited by its slow speed. Therefore we propose a SoC verification environment in which hardware parts are accelerated in FPG and cores are modeled with ISS. To connect ISS in high abstraction level with emulator in pin-level accuracy, bus functional model(bfm) is used. For hardware debugging, bus monitor is designed. By post-processing the data obtained by bus monitoring, debugging and performance estimation are possible. For easy and quick design and verification, we developed a tool which creates configurable bus architectures automatically. With this, the design time from specification to FPG based prototyping can be reduced remarkably. Thus fast verification and design space exploration are possible. MB is chosen as the SoC bus protocol. Keywords: SoC, BFM, MB, prototype, bus generation 1 Introduction For the system-on-chip(soc) design, many high abstraction level design methodologies, for example, using SystemC[1] are introduced and being developed. But RT-level test and verification is still important step in SOC design flow. For this, co-simulation has been used, which is generally based on ISS and HL simulator. Co-simulation methodologies provide accurate verification, but their performance is limited. s the designs are getting bigger, especially in the case of SoC, the HL simulation can not afford sufficient test. So the prototyping which is based on FPG is used as an alternative methodology. In the prototyping system, synthesized hardware designs are mapped into FPG to accelerate the operating clock speed. Of course, co-verification must be able to support concurrent development of software application which will be executed on an embedded core[3]. In some prototyping systems, real chip is used to model core. But the cores are not always available in test chip form, so ISS are used to model various cores. In our SoC design environment, the core is modeled in host computer with ISS and the hardware IPs are mapped into FPG. To improve performance, the communication between ISS and hardware takes place in transaction level to reduce the communication overhead. For this, bus functional model(bfm), which takes higher abstract command and generates pin and cycle accurate signals, is implemented in the FPG. The number of IPs in a SOC design is increasing, and the bus architecture is getting complicated having hierarchy. The IP reuse became a common sense and the reusable IP libraries are getting wealthy. ccordingly though the required IPs are various, most of them would be already available. Only a small part of the whole SOC design needs to be newly created. For these reasons, designing the on-chip bus architecture becomes a relatively big job. In many case the bus protocol would be fixed in the very early design time, automatic bus generation can make the SOC design and verification easy and speedy. Thus we developed a tool which generates bus architecture in fast and easy way. This work can reduce the design time considerably, and make design space exploration for the bus architecture possible. In this paper, the idea is realized on FPG based prototype system[4]. The hardware prototype board is mounted on a PCI slot of the host computer. nd thus communication between hardware and software takes place through PCI interface. For the onchip bus protocol, MB has chosen. This paper organized as follows. The related works are explained in section 2. In section 3, we explain prototyping and debugging methodology in the proposed environment. In section 4, a tool which generates onchip bus architecture automatically is depicted. In section 5, we show a case study on JPEG. nd in section 6, we give conclusions. 2 Related works There are various prototyping systems. In [6], the coverification system consists of VLIW processor and FPG board. The software component is an ISS of the core running on the VLIW processor. nd BFM is used to make pin signal. In [7], for design space exploration simulation based method is used. nd after that whole system is mapped in prototyping system where special SP is implemented in FPG. RM offers Integrator family[2] to provide the developer with a rapid prototyping environment that enables the integration of hardware and software IP. It consists of RM test chipbased Core Modules, and FPG-based Logic Modules. But it mainly aims to assist developing software so that it does not concern about hardware debugging.

2 For the automatic bus generation, Synopsys esignware MB On-chip bus[4] provides synthesizable and configurable bus components. But this package does not provide a way how to interact with cores. nd the generated components are configured in hardwired manner, so even for small changes the hardware must be re-generated, re-synthesized and re-compiled to the FPG. In our environment, every component has configuration registers. So HW characteristics such as address map, priority, clock frequencies can be changed immediately. 3 Proposed SoC design environment 3.1 Co-simulation For Co-simualtion, the IPC library of the emulator[4] is used. The software application in C/C++ can run in native code or in cross complied code on ISS. The hardware blocks including generated bus components in the dotted box and application specific IPs are run in HL simulator. Two processes run during cosimulation. The first is the process of C algorithm where PIs of the emulator are interacting with each other to generate stimulus to HL simulator. The second is the process of HL simulator where the HL simulator executes model of bus components and IPs. 3.2 Prototype Because bus generator offers synthesized bus components too, you can go to the prototyping step easily and quickly. In the FPG based prototyping system used in this paper, the system clock is based on the PCI clock which is 33MHz or 66MHz. The cycles per second of emulation system is hundreds times bigger than that of simulation. So the exhaustive verification or design space exploration is possible Bus functional model BFM(Bus Functional Model) enables C algorithm to communicate with hardware IPs in transaction level. BFM gets high abstraction level commands from C algorithm and interprets them to make pin and cycle accurate transaction to HB bus. The one side of BFM is PCI controller interface of emulator and the other side is HB interface. The major role of BFM is HB master. But it has HB slave interface also to utilize BFM as HB slave or both. BFM is MB HB rev 2.0 compliant and supports all features of the HB specification. In C algorithm, MB PI is used to communicate with BFM ebugging In the Prototype system, the debuggability is generally lacking because of the poor probing. The logic analyzer could help this problem but it is troublesome work and the channel bandwidth is still insufficient. So we designed MB monitor which is a pin-accurate and cycle-accurate debugger for MB development environment. MB monitor is composed of hardware and software parts. The hardware part of MB monitor samples the HB and PB signal values at every clock cycle respectively and sends them to the software part. There are several triggering conditions which define bus activities. With triggering conditions, the hardware part of monitor starts working when a predefined triggering condition is met, and stops when stopping triggering condition is met. The software part of monitor stores bus sampling information in a file. When the output file size reaches 1GBytes, it closes the file and opens a new file. One can debug with waveform viewer. Statistics of bus activity, coverage testing and protocol violence checking could be obtained through post processing with the dump files. This information can help performance measuring and bus architecture determination Synchronization We have applied a simple scheme to synchronize the cycle count between SW and HW. Figure 3 shows clock flow. HW holds clock when there is no request. When SW needs to access HW, it sends not only the request but also the cycle count between requests. BFM can enable or disable the clock generator. Figure 2 Co-emulation system Figure 1 Co-simulation system Figure 3 Cycle flow between SW and HW When the BFM gets a request, it first enables the clock generator during N cycle, and next manages the request.

3 The number of cycles consumed for the request is returned to SW, so that the total cycle count for an application can be obtained by summing all the cycle counts. 4 utomated bus generation For the requirements described above, we made a tool which generates bus architecture automatically from the bus specification. Figure 4 shows design flow using the tool. Bus generator produces two kinds of bus models from user bus specification, using MB bus component library which is described in section 4.1. One of the bus models is for simulation in HL. The other bus model is for emulation in EIF format. Bus generator takes bus specification via graphical user interface and connects automatically all components required. From the specification to the bus models which are ready to be used for simulation or emulation, it takes several minutes only. So the time and effort which are required for complicated SOC design process can go down very much. nd also when the bus architecture is not fixed, the design space exploration can be done in accurate and fast way. The bus architecture may include bus hierarchy, arbitration scheme, memory map, clock speed and so on. Because the design iteration time is quite small, such design factors can be decided based on the results of through simulation or emulation. 4.1 Reconfigurable bus components There are several components in MB bus system. Figure 5 illustrates MB bus example. The gray blocks are application specific user IPs. There are two kinds of components, the basic MB bus blocks and special function blocks. ll components are configurable with parameters. rbiter, decoder, Muxes, PB bridge, HB-to-HB bridges are the basic blocks of MB bus. rbiter does priority based arbitration and support up to 16 masters. The priorities of masters and default master are setting address mode control bit. ecoder includes default slave. There are two muxes, master-to-slave mux and slave-to-master mux. These muxes can support 16 masters and 16 slaves respectively. PB bridge has two sets of address map, normal and boot. nd PB bridge includes asynchronous FIFO. So the clock of PB bus could be independent of that of HB. It supports 16 PB slaves. HB-to-HB bridge connects two HB buses and enables constructing hierarchical bus architecture. It has asynchronous FIFO, so clocks of the two HB can be independent. It supports all burst mode of master and responses of slave nd there are three special function blocks, BFM, bus configuration module and clock generator. Bus functional model(bfm) is used to communicate with software side in transaction level. s described above, almost all bus components are configurable and bus configuration module does the work. This module takes configuration information from software and distributes it to configurable components. Clock generator is connected to the configuration module to get configuration information. Based on the information, it produces up to 16 different clocks and 4 resets. The frequency of the fastest clock is same with PCI clock. The slowest is slow 128 times than PCI clock. The phases of each clock are controllable. 4.2 Bus architecture Figure 6(a) shows example MB based SoC bus which has three hierarchically organized HB buses. The system can be redrawn as figure 6(b). The connection between bus and master/slave IPs can be replaced with switch box. So to make the connection configurable, the switch box should be implemented with reasonable resources. The proposed method is depicted in figure 7. In this scheme, master-to-slave mux in HB bus is merged with switch box. So, for each HB bus, only one mux is enough. But it requires relatively complex mux controller which takes not only configuration information but also HMSTER and HREY as input. HMSTER is arbiter output which indicates which master has the bus ownership now. Bus Configuration module Clock Generator HB slave1 rbiter PB Bridge PB slave1 rbiter HB slave0 MUX_M2S MUX_S2M MUX_M2S MUX_S2M HB slave3 PB slave0 HB slave2 BFM0 ecoder HB-to- HB Bridge ecoder BFM1 Figure 4 esign flow with Bus generator configurable. ecoder has two sets of address map, normal and boot. Each address can be configured. ctive address set can be switched during runtime by HB0 HB1 Figure 5 Bus architecture example

4 S0 S1 S2 HB0 H2H Bridge M0 M1 M2 S3 S4 S5 HB1 H2H Bridge M3 HB0 S6 M5 The signals which are not the inputs of master-to-slave mux, such as HBUSREQ and HLOCK, needs another switch box. It would be implemented with three stage clos network. In this scheme, the resource overhead is like below. < N 1 > a+α, whereα is the resource for clos network <Nx1> means N by one mux which covers all output pins of master. Note that this includes the master-toslave mux of HB. When the number of HB(a) is 3, the number of mater IP(N) is 20; a switch box requires 5010 LUTs which is 5.3% of the total LUTs of Xilinx VirtexII The target synthesis library used is FPG, because the reconfigurable bus would be used in the FPG based prototyping system. The mux for inputs of master is counted and clos network for HBUSREQ and HLOCK is counted. 5 Case study We applied the proposed environment to JPEG decoding system. Figure 8 shows the system. Header management part is implemented in C algorithm in the host side. The other parts such as VL(Variable Length ecode), ICT(Inverse iscrete Cosine Transform) and memory are implemented in hardware. BFM which operates as master takes charge of communication Figure 7 Merged-Mux based switch box M4 S7 M6 (a) HB2 Switch Box Mx Sx HB1 M0 M1 M2 M3 M4 M5 M6 S0 S1 S2 Master Slave rbiter ecoder HB2 (b) Figure 6 Example SoC: (a) hierarchical bus structure and (b) reconstructed bus S3 S4 S5 S6 S7 Figure 8 JPEG ecoding system between algorithm and hardware. VL and ICT have master and slave interfaces respectively. So there are three masters and three slaves in the system. Configuration module and clock generator are omitted in the figure. Using bus generation tool, the bus system could be created in a few minutes. nd the next step is connecting the bus with IPs such VL, ICT and memory. It takes also just a few minutes. To map the design into FPG, FPG compilation is needed. The compile time depends on the FPG device and the operating system, generally about one or two hours. So when the required IPs are available, a few hours are enough to co-emulate from specification. The JPEG hardware ran at 33MHz clock frequency. 6 Conclusions We introduced a SoC design environment with FPG based emulation system. For debuggability, we have designed MB monitor which samples all bus activities in pin and cycle accurate way. To improve the SOC design flow, we have developed automatic bus generation tool. In that environment, bus architecture can be generated from the bus specification in an easy and quick way with configurable bus components library. Using this, complicate SOC design processes from the specification to the prototyping system can be done in very small amount of time and effort. References [1] Benini, L., Virtual In-Circuit Emulation for Timing ccurate System Prototyping, SIC/SOC Conference, (2002), pp [2] Schaumont, P., Interactive Cosimulation with Partial Evaluation, esign utomation and Test in Europe Conference and Exhibition, (2004), pp [3] P.html [4] [5] ibrary.html [6] Schnerr, J., Instruction Set Emulation for Rapid Prototyping of SoCs, esign utomation and Test in Europe Conference and Exhibition, (2003), pp [7] Bieger, J. Rapid Prototyping for Configurable System-on-a-Chip Platforms: Simulation Based pproach, International Conference on VLSI esign,(2004), pp [8] RM. MB specification Rev 2.0

5 Title: SoC esign Environment with utomated Configurable Bus Generation for Rapid Prototyping uthor: Sang-Heon Lee, Jae-Gon Lee, Seonpil Kim, Woong Hwangbo, Chong-Min Kyung Key Words: SoC, BFM, MB, prototype, bus generation