СИСТЕМА ПРОГРАММНО-УПРАВЛЯЕМОЙ ВЕРИФИКАЦИИ СЕТЕВЫХ СЛОЖНОФУНКЦИОНАЛЬНЫХ БЛОКОВ В ЭТАЛОННОЙ СИСТЕМЕ НА КРИСТАЛЛЕ

Полный текст

Introduction. Functional verification (FV) is intended to serve for the validation of a designed device or an intel- lectual property core (IP-core) to set functional specifica- tions [1]. The FV significance rises together with the increase of designed devices complexity. The FV com- plexity also increases reaching 70 % of all development work [2]. Usually FV is performed on models of a designed device and then models are converted into a hardware prototype which becomes a base for creating of a target digital device. FV is divided into 2 large groups of methods: methods based on dynamic modeling or simulation (Simulation- Based Verification, SBV) of a model of Register-Transfer Level (RTL) [1; 2]; and Formal Functional Verification (FFV) methods based on the representation of a verified IP-core as other models that are not RTL, which are called formal and used for logical fault finding [3]. SBV is a traditional approach still having high priority because a target device is synthesized from RTL-model created by Hardware Description Language (HDL). FFV methods actively developed in recent years are additional and serve to avoid faults at early project stages, to detect faults not identified by SBV-methods; to carry out formal provability of the errorless operation of a de- signed device. There are also so-called hybrid methods using the combinations of different approaches. Hereinaf- ter the SBV-methods are used in the paper. In general terms SBV-method consists of creating the test environment where RTL-model of Device Under Test (DUT) is simulated. The test environment generates test inputs (stimuli) on the model in the form of different se- quences of input signal sets and analyses responses, or model reactions, that is, changes in its state and its output values. The action described is provided by special programs - RTL-simulators. At the present moment the simulation of complex digital devices such as microprocessors or devices con- nected to their internal bus is based on the Transaction Level Modeling (TLM) concept [1; 2]. In this case the stimuli are not specially-generated input signal sets but high-level interaction with DUT (bus exchange operations and input/output interface exchange, processor instruc- tions, and network packages) converted into signals. DUT reactions to transactions are also converted into high-level data saved as response tracks. The given test environment creating simplifies the FV. For test environment creating one can use both programming languages such as С/С++ or assembler and VHDL. The latter way belongs to autonomous IP-core verification and is inherent in all RTL-simulators. A new stage of its development is presented by such well-known methodologies as Open Verification Methodology (OVM) and Universal Verification Methodology (UVM) [4; 5]. To reduce the time spent on developing the test environ- ment and creating stimuli of any complexity they use such an object-oriented system designing language as System Verilog and UVM class library. Traditional programming languages are usually used for IP-core verification within an entire system. For example, a well-known approach for processor verifica- tion is Instruction Set Simulation (ISS) [6]. The stimuli are program tests of verifiable processor instruction executing and result monitoring. ISS is more flexible: it is used not only for system verification but also for autonomous one on condition of corresponding prepara- tion as well as for hardware and software co-verification. Such approach is generally called Software-Driven Verification (SDV) [7]. In special literature one can come across another name - Processor-Driven Verification (PVD) [8]. The approach consists of IP-core RTL-model connection to the full-function microprocessor system (MPS) model, for example system-on-chip (SoC), by the standard bus and interface and later verification by MPS program tests. This paper presents the SoC system for software- driven IP-core verification, where IP-cores are interface devices. The software-driven verification system. The over- all architecture of IP-core verification system for network devices has the form of a classic test loop, when the inter- action of a reference device and a tested one is checked under the control of an operating device which in this case is a SoC processor with required test software. A codec test loop is first performed in the model and for FPGA prototyping it is replaced by cable connection. Depending on the type of network device to be veri- fied - a network codec, a network protocol controller or a network switch - the architecture of the verification system is modified. Fig. 1 shows the architecture of network codec IP-core verification system (DUT on fig. 1). All the other SoC devices - a processor, an on-chip bus, and other devices not shown in the figure for simplicity - are reference ones in this case. It is supposed that reference IP-cores were previously fully verified and approved; correctness of their functioning is guaranteed; and they can be fully trusted. The given IP-cores can be self-developed, pur- chased as commercial products or obtained from informa- tion resources as open products, but in any case their cor- rectness is guaranteed. The entire SoC system consisting of reference IP-cores which are guaranteed to correctly and unerringly interact in it is a reference system. In a reference system only one separate IP-core is verified at a time. The scheme presented in fig. 1 is intended for verifica- tion of a new IP-core of a network codec, for example, its fault-tolerant version, by a reference IP-core of a network codec. The test inputs generated by test software are fed to a verified IP-core network codec from two directions: from an on-chip bus and a codec reference IP-core. Verified IP-core responses to inputs impacts are also processed by test software. The conclusion about exe- cuted or unexecuted tests is based on the expected results. The cumulative expected result is a DUT reference model realized in a reference SoC. Подпись: Network connectionThe architecture of a verification system of a network protocol controller IP-core is presented in fig. 2. A network controller includes a reference network codec. The logic of a network controller is to be verified. The architecture of network switch verification is built the same way (fig. 3). The network switch has n reference network codecs equal to the number of switch ports. A separate network con- nection using the n network codecs of the reference SoC is created for every switch port. Only the network switch logic should be verified. Presented architectures illustrate the simplicity of software-driven verification. Test environment naturally results from the reference SoC model and test software developed in a high-level programming language, usually C/C++. Test software. According to general verification methodology, if software-driven IP-core verification takes place in SoC reference environment then the test software consists of two test types: a directed test and a restricted random test. Directed software tests are designed manually. They are used for initial testing of a verified IP-core basic elements and its basic function as well as for checking of hard to formalize and rare events [6]. Besides, directed software tests allow recreating and checking the typical scenarios of network device interaction which consists of request-reply packages transmission between network nodes. To check fault tolerance function the network device interaction scenarios can be practised in response to pos- sible faults injected by predetermined fault introducing into packages transmitted over the network connections. Подпись: On-chip BusFig. 1. The architecture of a network codec IP-core verification system Рис. 1. Архитектура системы верификации СФ-блока сетевого кодека Рис. 2. Архитектура системы верификации СФ-блока контроллера сетевого протокола Рис. 3. Архитектура системы верификации СФ-блока сетевого коммутатора The major part of detailed verification is performed by restricted random verification based on the object-oriented programming capability. The method of restricted random (stochastic) testing is that the test sequence is generated automatically according to a set template with parameter- ized pseudorandom selection of test body instructions and their arguments. The method key benefit is the opportu- nity to fully automate tests generation and start-up proc- esses, as well as the comparison of tests results which is necessary for mass testing of complex IP-cores [9]. The advantage of the software-driven IP-core verifica- tion by reference SoC is naturalness and simplicity. There is no need to study specialized methodologies, language aids and verification libraries, and then with their help to create required verification environment and test inputs. In this case the test environment results naturally from a priori available reference SoC model created by a tradi- tional designing language (VHDL, Verilog), and tests are written in a high-level programming language C/C++, studied in the course of preparation for all engineering degrees at technical universities. The hardware and soft- ware co-verification task is also naturally solved because the program tests developed for IP-core verification be- come the basis for operational software of a given IP-core in a given SoC [10]. The restriction of this methodology usage is the ab- sence of a reference SoC. Such a situation is possible when a principally new SoC with a new processor and a new on-chip bus is developed. But the situation is not typical for the major part of IP-core development and testing processes. Verification results. Software-driven verification method for a reference SoC and presented verification system architectures are used to verify IP-cores of net- work infrastructure SpaceWire [11]. The reference SoC as well as the other IP-cores except SpaceWire reference codec are realized on the basis of LEON3 processor core from the open library GR-LIB of Gobham Gaisler [12]. The open codec SpaceWire Light is used as a SpaceWire reference codec [13]. SoC created on the basis of GR-LIB IP-core base can serve as a reference one. Gobham Gaisler Company has a good reputation, its concepts have piloting capacity and are realized both in FPGA and in ASIC. The architecture presented in fig. 1 is used for SpaceWire fault-tolerant codec verification; the one pre- sented in fig. 2 - for RMAP protocol controller verifica- tion [14], and the one presented in fig. 3 - for a routing switch of SpaceWire network. Verification process is performed in two stages: the first stage - verification on a model and the second one - verification by FPGA prototype. Testing by FPGA implementation allows both detecting errors that were not detected during the model verification, and making sure of IP-core functional specification values for a specific FPGA [15]. In this process the test software which was used for model verification is fully used for FPGA proto- type verification which is an important advantage of soft- ware-driven verification in a reference SoC. Further the developed test software can be used for target VLSI test- ing, including a reference SoC and a verified IP-core. Conclusion. The software-driven IP-core verification method with a reference SoC provides flexibility and va- riety of possible ways of creating test software; it does not create disparity between verification and synthesis; it pro- vides the SoC hardware and software co-verification; it provides software test portability when tests are created during the verification process of an IP-core model in a computational model on a SoC FPGA-prototype includ- ing this IP-core. Software-driven verification architecture with a refer- ence SoC realizes the classic test loop regardless of a veri- fied network device type. Developed modifications of software-driven verification system with a reference SoC are used for IP-core testing in SpaceWire network: a fault-tolerant codec, a RMAP protocol controller and a routing switch.

Об авторах

А. В. Шахматов

Сибирский государственный университет науки и технологий имени академика М. Ф. Решетнева

Российская Федерация, 660037, г. Красноярск, просп. им. газ. «Красноярский рабочий», 31

Е. С. Лепёшкина

Сибирский государственный университет науки и технологий имени академика М. Ф. Решетнева

Email: klepka1111.93@mail.ru
Российская Федерация, 660037, г. Красноярск, просп. им. газ. «Красноярский рабочий», 31

В. Х. Ханов

Сибирский государственный университет науки и технологий имени академика М. Ф. Решетнева

Российская Федерация, 660037, г. Красноярск, просп. им. газ. «Красноярский рабочий», 31

Список литературы

Дополнительные файлы