Development of an FPGA for space missions is, for many engineers, one of the most exciting end applications. However, due to the critical nature of space, the development typically comes with an increased verification workload. Not only must the design be verified functionally in simulation, we must also ensure the developer has not inadvertently introduced any latent design issues during the coding process.

Functional verification of an FPGA’s RTL requires a considerable simulation effort to achieve code coverage (branch, path, toggle, condition, expression etc). To achieve a high level of coverage the simulation must test several boundary and corner cases to observe the behaviour of the unit under test and ensure its correctness. This can lead to long simulation runs and significant delays between iterations when issues are detected. Of course, issues found in simulation can range from functional performance such as insufficient throughput, to state machine deadlocks due to incorrect implementation during the coding process.

This is where static analysis tools such as the Visual Verification Suite from Blue Pearl Software can be wonderfully complementary to functional simulation and can help save considerable time and effort in the verification stage, when code coverage is being investigated.

Static analysis enables functional verification to be started with a much higher quality of code, reducing iterations late in the verification cycle. In addition, static analysis typically also runs in tens of seconds to minutes compared to long running simulations.

Let’s take a look at how a typical space FPGA development can be assisted by the use of a static analysis tool up front prior to starting functional verification.

The first step in the use of a static analysis tool is the selection of the rule set against which the RTL code will be checked for errors and warnings. The rule set can include structural checks e.g. is a single or two process state machines used, are there unreachable states, does the state machine address a power-of-two states, etc. There are also rules for coding style enforcement, which ensures compliance with organizational coding standards while improving readability and comprehension by other team members.

Definition of the rule set can be challenging, which is why the Visual Verification Suite includes a number of predefined rule sets.These include rules which ensure DO-254 best practice, along with a new rule set generated from recent ESA work based upon the CNES VHDL coding rules.

Many of the predefined rules focus upon the structural elements which may be incorrect in the design and include elements such as:

• Unnecessary events – These are unnecessary signals included in the sensitivity list. Such inclusion will lead to simulation mismatch and add complexity to achieving code coverage.
• If-Then-Else Depth – This will analyse the If-Then-Else structures to identify deep paths which may impact timing performance and throughput when implemented.
• Terminal State – This is a state in a state machine which once entered has no exit condition. Finding this prior to simulation can save wasted simulation time.
• Unreachable State -This is a state in a state machine which has no entrance condition. Finding this prior to simulation can again save considerable simulation time.
• Reset -This ensures each flip flop is reset and reset removal is synchronous to the clock domain of the reset. Several in-orbit issues have been detected relying upon the power-on status of registers and as such reset for all flip flops is best practice.
• Clocking – Clocking structures are also analysed to ensure there is no clock gating or generation of internal clocks.
• Safe Counters – Checks to counters ensure that terminal counts use greater than or equal to for up counters and less than or equal to for down counters. This ensures single event effects have a reduced impact on locking up counters.
• Dead / unused code – Analyses and warns about unused / dead code in the design. This can be removed prior to functional simulation and reduces head scratching when code coverage cannot be achieved.

Modern space FPGA designs also often include multi-clock solutions, for example ADC and DAC clocking domains. This multi-clock environment can introduce Clock Domain Crossing challenges as information is passed between clock domains, leading to corruption if incorrectly synchronised.

Finding CDC issues is impossible in functional simulation, and they are normally identified using vendors’ timing analysis tools. This means information on CDC is only available at the end of the implementation process, and iterations will require the rerunning of verification and implementation to achieve a corrected implementation.

The ability to identify the Clock Domain Crossing issues prior to the verification stage can save significant time and verification iterations. The Visual Verification Suite provides designers the ability to perform CDC analysis on the source code, identifying CDC issues earlier in the development cycle and saving considerable time in the development process.

In summary, Static Analysis provides developers of FPGA for space applications the ability to reduce development and verification time as it enables entry into functional simulation and implementation with a higher quality of code. If this interests you, please take it for a test drive on your next FPGA.