Xilinx Unveils Vivado Design Suite for the Next Decade of ‘All Programmable’ Devices

model of the system specification. The model-checking software processes each of the properties, exhaustively traversing all the reachable states of the design in order to verify the properties. When a property fails, the model checker returns a counterexample that represents a trace from reset for which the property is not satisfied. Model checking has the benefits of being automatic and executing relatively fast. Unlike simulation-based verification, it exhaustively tests the system model with the result that it frequently exposes hard-to-find bugs. Sometimes these bugs arise in obscure corner cases; sometimes the verification engineer who created the stimulus test patterns and assertions for the simulation testbench simply overlooked the conditions under which the bugs arise. Modern systems with large numbers of state variables frequently exhibit the so-called “state-space explosion” problem, in which the number of reachable states grows exponentially. The complexity of their state-spaces can easily exceed the capacity of conventional model checkers, thereby limiting the practical utility of the technique. This restriction has prompted the development of newer forms of model checking, including interval property checking, the methodology we used in this work. [2] IPC is a specialized example of what are known as bounded model checkers. In common with other bounded model checkers, IPC restricts the scope of properties to a finite number of clock cycles to limit overall complexity and uses Boolean satisfiability (SAT) solvers to perform the actual model checking. IPC differs from conventional bounded model checkers by allowing the window of clock cycles over which a property may be asserted to start at an arbitrary point in time. IPC also introduces an intuitive approach to overcoming the statespace explosion challenge. The IPC methodology exploits design abstraction to guide the user in creating a conSecond Quarter 2012 Xcell Journal 57 X P L A N A T I O N : F P G A 1 0 1 INSIDE AN INTERVAL PROPERTY The following example shows the pseudocode of a simple SVA-style property that describes the operation of an ADD instruction in a processor. As you can see, at time 0, an ADD instruction and its two operands are fetched, and two cycles later, the register is correctly updated with the sum of the two operands. Property ADD_INSTRUCTION; t##0 ready_to_issue_instr() and t##0 decode(ADD,op1,op2,res) implies t##1 pc_updated() and t##2 reg(res)=reg(op1)+reg(op2) endproperty more complete systems consisting of both hardware and firmware. The focus of this work has been to evaluate a unified, formal-verification environment that describes both firmware and hardware and their interactions by applying IPC to a commercially available, soft IP core from Xilinx called the Soft-Error Mitigation (SEM) core (http://www.xilinx.com/products/intellectual-property/SEM.htm). The core incorporates register-transfer-level (RTL) logic and a PicoBlazeTM microcontroller. THE SEM CORE To better understand the verification task, let’s first look at the soft IP core in more detail. This Xilinx soft IP core can detect, classify and correct errors in the configuration memory of Xilinx FPGAs. It can also inject errors for testing purposes. Modern semiconductor devices are susceptible to disturbances resulting from high levels of radiation. A highenergy neutron, for example, can impact a chip by causing a singleevent upset (SEU), resulting in a change of state in a configuration memory cell. To mitigate these effects, the memory cells of the configuration frames in Xilinx FPGAs are protected with single-error correcting, doubleerror detecting hardware blocks. For certain applications, such as the instrumentation in spacecraft, even more elaborate schemes are necessary to offset the extremely high levels of radiation. The SEM core provides a solution in these cases by monitoring the status of the error-correcting code (ECC) blocks via the FRAME_ECC port within Xilinx FPGAs. The SEM core uses a Xilinx PicoBlaze microcontroller to monitor the status of the configuration memory cells and to take corrective action as required. Designers can incorporate the SEM core into a design and combine it with additional circuitry of their own to implement higher levels of protection against radiation effects as mandated by the application. Should it ceptual state machine (CSM) representing the key functionality of the design under verification. The CSM captures all the essential operations or transactions within a given design. At the highest level of abstraction, each transition between states in the CSM represents a single atomic action that is covered by a unique property. In reality, because the CSM is an abstract view of the design from which it is extracted, each CSM transaction can correspond to as many as a couple of hundred clock cycles of related signal activity in the corresponding RTL code. A well-formed property captures all of the most relevant state, as well as input and output signal behaviors at the cycle-accurate level for the complete interval it abstracts. Each property specifies the expected behaviors within a multicycle interval corresponding to exactly one transition or operation of the CSM. Hence the methodology is known as interval property checking or, equivalently, operationstyle interval property checking. The CSM abstraction deliberately does not attempt to capture every detail of the underlying RTL design. Instead, the methodology reduces the state-space and state-transition complexity by elaborating only the subset of control states that is important for capturing complete system behavior. In this way, IPC is different from standard assertion-based verification, where a designer adds local signallevel assertions to the RTL code and checks them using simulation or with formal techniques whenever possible. Very often such assertions check preconditions that the designer has inferred when implementing the corresponding portion of the RTL code. It can be unclear how these local assertions relate to the specification of the IP block. Additionally, these hand-generated assertions are sprinkled throughout the code base, making it difficult to reason about the extent to which the assertions cover the entire design functionality. 58 Xcell Journal Second Quarter 2012 X P L A N A T I O N : F P G A 1 0 1 Next, all viable state transitions are automatically and exhaustively explored and their corresponding properties are verified. Any failures are highlighted along with details of the counterexamples that triggered the failures. Operation-style IPC with the OneSpin 360 MV formal-verification tool also allows for an automatic proof-of-completeness analysis. This is accomplished with the same state-ofthe-art property-checking technology (based on efficient solvers for the Boolean satisfiability problem) that is used for proving the CSM properties. The proof of completeness guarantees that for every possible input sequence, a unique chain of operation properties determines the behavior of the design. The properties in this chain are linked together via their abstract starting and ending states in the CSM, and the input triggers match the respective input trace under consideration. Moreover, the analysis checks that each property individually specifies all relevant output signals within a particular time interval, and that these intervals hook together without any gap in describing output behavior. In this way, this proof of completeness is a check of the set of properties as a whole. If the check succeeds, then there is no input scenario for which the behavior of the design remains undetermined by the set of properties; thus, the property set captures the complete functionality of the design. The challenge of applying formal methods to the growing task of verifying embedded firmware and its interaction with hardware is an area of active and ongoing research. It’s been the norm to separately verify the firmware and hardware components, a process that then requires final and time-consuming full-system integration. Until now, verification engineers have applied interval property checking mainly to the formal verification of hardware subsystems. Recently reported research, however, has outlined ways to extend the methodology to X P L A N A T I O N : F P G A 1 0 1 Second Quarter 2012 Xcell Journal 59 detect a configuration memory error, the SEM core can resolve it directly or communicate the error to the larger system design. The proper operation of the SEM core is vital because its sole purpose is to ensure the correctness of users’ FPGA circuits. While Xilinx has fully validated this core, it is a challenging piece of IP to verify for a variety of reasons. The core communicates with several interfaces including a UART, the previously mentioned FRAME_ECC, the FPGA’s Internal Configuration Access Port (ICAP) and a custom error-injection interface. These interfaces, while well understood, are difficult to exercise with every possible combination of input combinations to stress the embedded PicoBlaze microcontroller. Formal verification of the SEM core’s functionality requires that we capture the interaction among three things: the PicoBlaze firmware, written in assembly code; the “wrapper” logic; and the external interfaces to system resources described in specification documents. To accomplish these tasks, we applied interval property checking to verify the correctness of the hardwaredependent software in the SEM core. USING IPC TO FORMALLY VERIFY FIRMWARE AND HARDWARE Design teams face a major challenge when it comes to formally verifying low-level firmware such as boot code or drivers for bus protocols in conjunction with the hardware on which they are running. Recently, a team from the Electronic Design Automation Group at the University of Kaiserslautern in Germany has reported on how to extend interval property checking to make it tractable for h