Category Archives: Blog

Issue 8: RTL Coding for Space and High Reliability Applications

Thanks to their performance, flexibility and “any-to”outstanding interfacing capabilities, FPGAs are incredibly popular in high reliability applications. They are often used in space systems such as satellites, launchers, aerospace, and autonomous vehicles. In these high reliability applications, depending upon the use case, the system must be able to keep operating or gracefully and safely fail, should an error occur.

Developing high reliability FPGAs is a complex task which must be considered holistically as part of the wider system. One common step deployed in high reliability flows is the enforcement of RTL development guidelines. These guidelines will contain rules which ensure key elements of the designare setup correctly, such as:

  • All flip flops are reset – Relying on the initialised state at power up can lead to unpredictable behaviour which can result in loss of the mission. One example of this was the NASA Wide-Field Infrared Explorer lost due to reliance on the power-on default state
  • Vectors are of correct sizes and types – This ensures overflow of incorrect translation does not occur as was the case with Arianne 5 initial launch, in which a 64-bit floating-point number was translated as a 16-bit signed number.
  • State machines and counters cannot enter an incorrect state due to a single event effects (SEE)
  • Clock domain interactions are safe and data crosses without the potential for corruption.
  • Naming conventions and coding styles are complied with to ensure readability and portability across projects.
  • Coding structures which are likely to cause safety issues are not used. For example, latches, not full defining if statements, gated clocks etc.
  • Mismatches between simulation and synthesis interpretations of RTL


One example of a bad coding structure is demonstrated below in a state machine reset example. While technically correct, the state machine relies upon the position of the state declaration for the reset state. Changes made later to the state machine may result in a change to the behavior. If left as is, this could cause system issues as well.

Image 1

So how would you check for coding issues like this? There several different coding standards which can be used. An example is the D0254 working group, Centre National d’Études Spatiales (CNES) VHDL coding standards.

Image 2

Mapping of DO-254 VHDL working group coding practice rules to BPS Checks

Image 3

Mapping of DO-254 VHDL working group safe synthesis rules to BPS Checks


Blue Pearl’s Visual Verification Suite provides several hundred of built in checks which can be used to validate high-reliability guidelines. Some rule checks like the DO-254 coding standards are implemented already within the suite as a package.

Image 4

Alternatively, if a different guideline standard is to be used, e.g. CNES, a separate package can be implemented by defining a custom package. This custom package takes the formof a TCL file and can define a custom BSP package.

Image 5

Defining a Custom Rule Set

Image 6

Custom Rule Set Loaded into BluePearl

Once the packages are defined, they can be used to check the RTL source files.The maturity of the design can be assessed by tracking the warnings over time. This capability is provided by the suite’s Management Dashboard. Using thedashboard, you can see the number of errors and warnings received as the development progresses. Of course, this should be trending down over time as the issues are addressed.

Using the Management Dashboard in this manner also provides metrics on the impact of requirement changes as the development progresses. In the image below you can see the initial development errors and warnings being corrected before a change of requirements leads to additional increased effort. Metrics such as this are very useful for project management and change impact assessment.

Image 7

Blue Pearl solutions provide developers of high reliability systemsthe ability to verify and debug their FPGAs prior to implementation, leveraging automated industry standard verification rules and guidelines. Only with such analysis can designersensure the RTL which enters synthesis and simulation is of the highest quality. In addition, the Management Dashboard enables the maturity of the RTL development to be established, providing great metrics on the project for the project management team.

Issue 7: Five Capabilities You Might Not Know About Visual Verification Suite

The capabilities for Blue Pearl’s Visual Verification Suite are well known for Lint, Clock Domain Crossing Analysis and Design Management. However, there are several capabilities in the tool which are easily overlooked but nevertheless provide the designer with significant benefits, let’slook at five of these.

  1. 1. Text Reports – Along with the linting and messages which result from the structural analysis checks. The suitealso enables designers to generate additionaltext reports on the design. These text reports provide significant detail on the objects structure, design resources, generic and parameter settings and so on aboutthe design. This information is particularly useful if you are trying to understand a legacy design, especially when combined with the dependency viewer. However, usefulness of the text reports is not limited to just information which helps us understand the design. It also includes information which can help us gain better performance in the final design. One example of this being the IF/THEN/ELSE length report.Understanding the IF/THEN/ELSE depth enables the designer to identify areas of the design where optimizations can be made to ensure timing performance is achieved.

    Enabling Text Reports
    Enabling Text Reports

    IF/THEN/ELSE Depth
    IF/THEN/ELSE Depth
  2. 2. Schematic Viewer – The schematic viewer is ideal when we are trying to isolate issues raised in the linting structural checks, CDC and SDC analysis. The schematic viewer can also be used to visualize a legacy design to understand the interconnection between modules and most importantly clocking and reset structure.
    Clock Tree View
    Clock Tree View

    Reset Tree View
    Reset Tree View
    Within the schematics viewer we are also able to cross probe to the RTL, highlight nets and trace cones of logic to help understand the design and track down issues.

    Schematic Actions for a selected element
    Schematic Actions for a selected element
  3. 3. Path Analysis – Timing closure is one of the most time-consuming elements of the logic design process. Often,when using programmable logic, we need to wait for the vendor design tool to complete its implementation before we know of any timing issues. This of course, can take several hours and is often an iterative process. One of the key design structures which impacts timing performance is the path length, that is the number of logic elements between flip flops. The Visual Verification Suite’s Analyze RTL tool elaborates the RTL design and indicates the long paths between flip flops. This allows the designer to act, to correct before implementation. Using such analysis can save the design engineer significant time in the implementation stages of the project.
    Path Analysis between two registers
    Path Analysis between two registers
  4. 4. Design Scenarios – When we design our RTL modules, we want them to be as reusable as possible, saving design time. To make our designs as flexible as possible we often use generics or parameters in our RTL to enable different final implementations of the IP core in the FPGA or ASIC. Within the suite, design scenario enables us to create solutions with a different setting of the generics and parameters within our designs.
    Using design scenarios enables us to ensure that changes to the generics/parameters does not result in additional or new violations of the enabled packages and checks. Or indeed if the parameter or generic results in errors.
  5. 5. Analysis Scenarios – Similar to the design scenario, analysis scenarios allow us to change the settings currently used by Analyze. The benefit of changing Analyze settings in this manner is the original settings remain unchanged while we observe the impact of making the changes to the checks.If they are accepted, we can add them into the main settings. Alternatively, we can use scenarios to run different checks on files depending upon the required level of check.

    Both the Design and Analysis scenarios, once completed, create a new option under the design scenarios menu which can be used to enable that scenario. If you need to change the configuration of the scenario once it is enabled,just use the “design settings” as we would do for a normal scenario.

    Hopefully, you can see the benefits these five capabilities of Blue Pearl Software’s Visual Verification Suite can bring to your ASIC and FPGA verification.

Blue Pearl Software’s continued commitment to customers

Individuals and businesses alike are taking steps to reduce the risk associated with the spread of coronavirus (COVID-19). Our foremost concern is that everyone takes the appropriate precautions for the safety of themselves, their families, and co-workers.

Blue Pearl Software wants to enable the productivity of our current and potential customers in this challenging environment.

We will grant current customers node locked license(s) or dongle(s) equal to the amount of floating licenses they have purchased to enable verification and debug their designs at home. This will be for an initial period of two months or as long as the Covid-19 crisis lasts.

We will grant prospective customers copies of node-locked licenses for two months to use on their home computers to enable verification and debug at home, and we will train those customers via Webex. This is subject to company verification.

Blue Pearl’s Visual Verification Suite provides a comprehensive set of verification tools for development and debug of high reliability RTL and runs on both Linux and Windows.

As always customers can email for prompt support of issues that may come up. Our entire workforce is able to work remotely to support customers. Let us know if you have questions or concerns. We are here for you and we will get through this together!

Ellis Smith
Chairman and Chief Executive Officer
Blue Pearl Software

Issue 6: BPS Integration with Vivado and Vivado HLS

Modern FPGA designs are complex systems. They may include processor cores, RTL code and, increasingly, modules developed using High Level Synthesis (HLS).

Of course, we still want to analyse the custom RTL created and the overall design for compliance with design methodologies e.g. STARC, Reuse Methodology Manual and Xilinx UltraFast Design Methodologies. We may also want to analyse at the design level to ensure all Clock Domain Crossings (CDC) are safe, along with identifying Longest paths and False and Multi Cycle paths which will impact timing constraint creation.

When we are working with Xilinx devices, we can include the Blue Pearl TCL Store Add Ins. These enable us to create new projects, as well as load and update a design from Vivado directly into BPS.


Figure 1 – Blue Pearl TCL Store Add in

Once the BPS scripts have been installed, we can use the Tools menu to create three new custom commands: Create_BPS, Launch_BPS and Update_BPS.


Figure 2 – Defining the Custom Commands

We can find each of the TCL commands to be used for each custom command in the readme file installed with the TCL store add in. On my windows system this was available under the following location.



Figure 3 – Readme file with commands for Vivado Integration

You can also find a logo under the same directory that can be used to label the commands.

Figure 4 – Setting the BPS Commands

With the TCL store integrated we can then create our design. I used the following to demonstrate a design of sufficient complexity:

  • Zynq Processing System Configured for ZedBoard
  • HLS Callendar Van Dusen Equation – This design uses floating point representation.
  • RTL Implementation of the Callandar Van Dusen Equation – This design uses IEEE VHDL 2008 Fixed Point number representation.
  • AXI Interconnect – Connects the HLS and RTL blocks to the processor enabling a SW based solution.
  • Processor Reset Blocks

To create a sufficiently complex clocking scheme, the HLS and RTL blocks will be placed on different clock domains (FCLK0 and FCLK1).

The complete design looks as below.

Figure 5 – Vivado Design

Once the design has been completed in Vivado, we can generate the output products and use the Blue Pearl TCL store commands to create a new project, and then open the project in BPS.

This will contain all of the RTL files used within the design and represent not only the custom developed RTL but also the RTL created IP blocks and the HLS block.

Before we can get the design to successfully load for analysis, we need to make some changes to the design settings. This includes:

  • Setting the VHDL Language 2008 – this is due to the use of the fixed-point libraries in the RTL module
  • Set the Xilinx Libraries to the correct version – In this example I used Vivado 2019.1

I also defined the Clocks and the Reset from the Processing block. These are defined in the Design Settings -> Clocks and Design Settings -> Reset tab


Figure 6 – Setting the clocks


Figure 7 – Setting the design Resets

With these changes we can then successfully load in the design to BPS and start analysing and filtering the load messages.

By opening the results view and looking through the detailed messages, we can then assign waivers to the messages raised. These waivers indicate if the message needs to be addressed (Must Fix) or does not need to be fixed (Won’t Fix).

When we are working with large groups of messages, we can use regular expressions to waive several messages to either must or won’t fix at once, easing the analysis.

Once this analysis is completed, we will have several issues remaining in the design which are flagged as Must Fix.


Figure 8 – Report Viewer

We can also observe the design in the schematic viewer to ensure the design architecture looks like the block diagram in Vivado.


Figure 9 -Top Level Schematic

Within the schematic view we can double check to see that all the instances included in the Vivado design are visible.

We can also configure the schematic viewer to observe the clock and reset trees within the design using the Clock Tree Schematic and Reset Tree Schematic views.

Figure 10 – Clock Tree Schematic Diagram


Figure 11 – Reset Tree Schematic View

With the design loaded we are then free to explore the FSM viewer to analyse any issues raised in the load analysis.


Figure 12 -FSM Analysis listing of all FSM within the design

All this information is available as soon as the design loads. We can also then run design analysis to identify any issues such as clock domain crossing, path analysis and false / multicycle paths.


Figure 13 – Path Analysis

Finally, you can observe the maturity of the design as it passes through the load and analysis phases using management dashboard. This enables us to see the number of open issues and therefore the project maturity we progress through the design cycle.


Figure 14 – Management Dashboard

Wrapping up, we can see that we have been able to load in a complex design which consists of different elements e.g. processing system, HLS IP and Standard Xilinx IP into Blue Pearl Software and this enables us to check for design level issues.

You can find the example Blue Pearl and Vivado projects here.

Issue 5: State Machine Design & Analysis

State machines are at the heart of our designs. They enable us to implement sequential structures in a parallel programmable logic world. We use them to implement control structures and communication protocols, however complex state machines design can also significantly slow down our development due to the challenges associated in debugging issues, epically if only using simulation for verification.

Let’s look at some simple steps we can take when implementing state machines to reduce the number of potential issues introduced, along with how to analyze them using Blue Pearl’s Visual Verification™ Suite to accelerate debug before simulation.

When developing a state machine, it is good practice to ensure our design uses the following factors:

  • Implement all the functionality in a single clocked process. This prevents the implementation of latches or un-synthesizable combinatorial logic constructs. It also ensures all outputs from the state machine are clocked. A single process state machine also prevents mixed decoding of the present and next state in the design, as there is only one state. Single process state machines are also easier to debug if necessary.
  • Ensure the state machine has a clearly defined reset state. When defining this state, do not rely on positional association of the reset state in the state definition.
  • Decouple as much functionality as possible from the state machines. Do not decode large buses or counters within the state machine body. In place of this, pass single bit inputs and outputs from the state machine to start counters or indicate that the counter has reached its terminal value. This decouples large elements of logic from the state machine implementation, allowing for a better implementation and improved timing.
  • If the state machine does not use a power-of-two states and the application is a high reliability or mission critical implementation, ensure that the unused states are correctly addressed so the state machine does not lock up if an unused state is entered due to noise or single event effects. Correctly addressing unused states means ensuring that for each unused state there is a recovery to a known state so operation can continue.

Once we have implemented our state machine design, the next stage is to integrate it within the larger design and then analyze the design using Visual Verification Suite.

Analyzing our state machines in Visual Verification Suite is very simple and performed as part of the load process. Before we load our design and perform the FSM analysis, we need to first configure the analysis.

The first step is to define the FSM Analysis options. Here we can configure what analysis is performed. One of the crucial options is the conversion of implicit state machines to explicit state machines; without this an implicit state machine may not synthesize.

If you are not familiar with implicit state machines, they are the state machines which are defined in a more traditionally software style consisting of loop, branches and wait states.


Once the FSM analysis is correctly configured, we can define further checks on the FSM under Load Checks. Here we can define which rules we wish to use to check our state machine, such as checking that the state machine is implemented using a single or two process structure as required by our design rules (FSM_USE_SINGLE_PROCESS and FSM_USE_TWO_STATE_VAR).

We are also able to check to ensure there are no unreachable states or terminal states included within the design. For safety critical / high reliability applications, the ability to ensure that unused states are correctly addressed in the design is very important, since once entered they become terminal states if not correctly addressed.

Terminal states can occur if unused state states are incorrectly addressed, or due to design error where a state is entered but the logic to exit that state is not implemented correctly.

With the options configured in line with the design standards, the design settings window can be closed and the design loaded, which runs the analysis.


Once the design is loaded, we can view the FSM analysis results. These are available in both as messages in the results view, and graphically in the FSM Analysis View.

To demonstrate the capabilities of the FSM analysis we will use the unmapped state example, which can be found under the help menu.


This will load in an example Verilog file which contains a state machine which has a design issue.

Before the design is loaded and analyzed, click on the design settings to see how the FSM analysis for this example is configured.


Loading the design will perform the FSM Analysis, and results will be available under the “View Results” option and the FSM Analysis Viewer.


Looking at the FSM Analysis Viewer we will notice that this design has a terminal state for state five, which results in state six being unreachable. Both have colors (brown and red respectively) to show the states where issues exist.

Having identified this issue in the FSM Analysis Viewer we are then able to correct the RTL source to behave as intended.

This ability to enforce good design practice and analyze the FSM behavior quickly enables us to identify issues earlier in the RTL source code, which can save time in development process as issues are identified before simulation and synthesis.

Issue 4: Creating our own Packages

One of the reasons we use Blue Pearl’s Visual Verification™ Suite is to enter simulation and synthesis with a better quality of code. Improved code quality means we have identified and addressed coding standard violations, structural logic issues, long combinatorial paths and of course, clock domain crossing issues.

To ensure the same quality across several modules and projects we need to ensure each project and module is subject to the same design checks. This is where creating a “custom package” comes in very handy.

Within a custom package we can group together all the relevant design checks and then use the package each time Analyze RTL™ or CDC is run. Typically, we will base the custom package on our own development rules and guidelines, also known as coding standards.

Let’s look at how we can create and use a custom package using Blue Pearl Software Tcl commands. The Tcl script will be loaded when Visual Verification Suite starts, configuring the packages and checks we desire to be run.

Creating a script is easy and can be achieved in just a few lines of code as you can see in the completed code snippet below.

The Tcl script will initially clear all the existing packages and design signoff checklists such that the only package which appears in the Design Checks window is the one we are going to create in a few lines time. To do this we use the Tcl commands BPS::clear_packages and BPS::clear_all_design_signoff_checklists.

The second step is to define the new package and design signoff checklist, though to run the design signoff checklist a Management Dashboard license is required. In this case I am creating a package called Adiuvo Package using the Tcl commands BPS::add_package {Adiuvo Package} and a check list called Adiuvo CL with the command BPS::create_design_signoff_checklist -checklist {Adiuvo CL}.

Once the new package and checklist have been declared we can enable the design checks, while also adding these checks to the newly created checklist. In this example, for simplicity the package contains only a single check so there is only a single command on each line.

The completed Tcl is shown below:


Tcl Script

To use the Tcl script that we have just created, we need to rename it to bps_setup.tcl, and set the startup search path to include the directory where our bps_setup.tcl script is contained.

We set the startup search path in the preferences, once we set this to our Tcl file, we can restart.


When suite restarts up, you will see in the message window the new Tcl script being loaded.


Once it has finished loading, if we open the design settings window, viewing the load checks will show the Adiuvo Package and the check which was enabled as part of it.


Running this check package against, a test case will result in the warning below being issued, as you would expect.


You will notice that there are no extra warnings associated with the Adiuvo Package. This is because we have not yet enabled the messaging and check package. We can do this in the Design Settings à Messaging page, from the drop-down tab select the ACS package which is the name of the extra info package we created in the Tcl script. We can also add this into the Tcl script using BPS::set_msg_check_package command.


We also need to enable the checklist we previously created. Enabling the checklist will provide a detailed design sign off report along with providing more information for Management Dashboard. This can be achieved via the Design Settings à Report Options à Design Signoff Options page.


When we rerun the design analysis again with this message package and check list enabled. In the main window we will see the design sign off report indicating a failure of the SLCC check.


If we open a Management Dashboard, we will see on the Design SignOff tab the Adiuvo checklist was enabled to run and all the checks contained within it were also enabled to run. While the actual results show, an issue was found.

Providing information on both the Design Signoff setup along with the actual results is very important. If a check is reported as having zero issues it can mean either the test found no issues, or the test was not enabled. As such the checklist setup information allows us to demonstrate the test was enabled preventing inadvertent indication that no issues are present.


Investigating further when we open the results view, we will see an additional column in the results with the exact ACS messages from our new package.


Now we know how we can create custom packages of checks which align with our design rules and are reported via custom checklists. We also know how to use the extra message info to add specific information about how the design check relates to our design rules easing any corrective actions.

You can find the example files here

Issue 3: Working with Xilinx Parameterized Macros for CDC

When it comes to crossing clock domains it is best, if possible, to implement the crossing using registers which are located close together and have small set up and hold windows. In short, our register structures used for clock domain crossing should be optimized for signals which may go metastable.

In our Xilinx designs this means we need to use either the HARD_SYNC primitive, or alternatively if our CDC issues are more complex, one of the Xilinx Parameterized Macros (XPM). Xilinx Parameterized Macros can be used to implement CDC, FIFO and BRAM solutions in your design. When it comes to working with BRAM and FIFO, unlike using the BRAM/FIFO generator which uses black boxes in synthesis, XPMs are not black boxed and therefore enable the synthesis tool to make better timing and resource estimates. They also allow for faster simulation than when using the BRAM/FIFO generator. We can use these libraries in 7 Series, UltraScale and UltraScale+ families.

Of course, we are interested in the seven-clock domain crossing (CDC) capabilities provided by XPM. These are:

  • Single Bit Synchronizer – Synchronizes a single bit vector between clocks.
  • Asynchronous Reset Synchronizer – Synchronizes an asynchronous reset to the destination clock. Reset assertion is asynchronous while the reset removal will always be synchronous and safe for the destination clock.
  • Gray Code Synchronizer – Synchronizes a data bus between source and destination clocks, using Gray coding. Using this implementation, the input can only increment or decrement by one between values, making it useful for counters.
  • Handshake Synchronizer – Synchronizes a data bus between source and destination clocks using handshaking of signals.
  • Pulse Synchronizer – Synchronizes a pulse of any width (one source clock cycle or wider) from the source domain to the destination domain.
  • Single Bit Synchronizer – Synchronizes a single bit from source to destination domain.
  • Synchronous Reset Synchronizer – Synchronizes a synchronous reset to the destination clock domain. This both asserts and de-asserts the reset synchronously, unlike the Asynchronous reset macro.

Let’s look at how we can create a simple example using XPM CDC functions and verify the crossings as safe using Blue Pearl Software’s Visual Verification™ Suite.

The code itself for this demonstration is quite simple and will contain two clock domains. The first clock domain will contain a simple counter which counts to a terminal value. This counter can be restarted by a restart signal and reset asynchronously.

Both the restart signal and asynchronous reset are contained within the second clock domain and as such require crossing from one clock domain to another. To perform the clock domain crossing I used the Single Bit Synchronizer and Asynchronous Reset Synchronizer.

Using the Xilinx Vivado™ Design Suite to simulate the design (available on my GitHub), you can see the asynchronous reset and start signals being retimed by the XPM CDC Macros.


When we load this design into the Blue Pearl Visual Verification Suite we can confirm that we have correctly and safely crossed the clock domain.

The first thing we need to do in VVS is the import the Vivado project. We can do this using design settings and selecting the external projects dialog and pointing VVS to our Vivado project.


We also need to select the version of the tool we are using on the FPGA Vendors dialog


Once that is complete, we can load the design. However, before we run the full CDC analysis, we may want to explore the Advanced Clock Environment which shows relationships between clocks and gives a preliminary indication of whether signals are synchronized or not. In this case we should see we have one signal which is passing from clock domain two to one and is synchronized.


To ensure the clock domain crossings are correct we run the CDC analysis. To do this we need to first ensure that the CDC analysis checks are enabled in the analysis settings.


Running this analysis and then opening the Clock Domain Crossing Viewer will show three crossings. If you only see two, ensure the “only show improperly synchronizes CDCs?” check box is NOT checked.

You will then be able to see three crossings, the first a correctly implemented crossing from clock domain two to one. Cross probing to the source code will highlight the XPM instance.

The remaining two are associated with the input and output signals as the clock is not defined for those signals.


There are two ways we can address this issue. We can use an SDC file to associate the inputs with a clock domain. Alternatively, we can uncheck the “Find CDC Violation on Primary Input/Output ports” check box option.


When we rerun the analysis now, we will see only one properly synchronized crossing from clock two to clock one.

Now we understand how we can use XPM CDC structures to perform safe clock domain crossings in our Xilinx devices and that VVS will pick up and identify XPM CDC structures correctly. This enables us to focus on clock domain crossings which might have been missed in the VVS CDC environment.

You can obtain the Vivado project and design files here if you wish to experiment with XPM and VVS.

To read more about the Xilinx / Blue Pearl integration in our white paper.

Issue 2: Identifying & correcting difficult to find RTL problems earlier

All engineers know the earlier we identify an issue in our design, the easier and less costly it is to correct. We also know some issues are easier than others to identify. The worst kind are those which are intermittent and manifest late in the test regime or, even worse, in the field. These late arising issues lead to many long hours and stress in the engineering team as we try to address the root cause.

While these root causes may be varied, we can group them together into several likely classes which may be the root cause. These include:

  • Missing Assignments – Missing assignments arise from how we write the code, for example an IF check not having a corresponding ELSE or missing a CASE statement. Structures such as this will result in different behaviour depending on the synthesis tool, inferring either latches or registers. The latch will of course behave differently which impacts portability and may result in issues in corner cases, which are hard to track down.


  • Clocking – Modern designs contain several clock domains. Of course, information needs to be shared between these domains. Incorrect synchronisation of data and signals between clock domains can result in metastability and corrupted data. In some systems this incorrect data can be catastrophic. Most engineers will use two stage synchronisers and FIFOs to transfer data safely however, due to the complexity of designs, signals can slip through the net and be unsynchronised. One example which can be hard to find is using a FIFO status signal e.g. Full or Empty on the wrong clock domain. This will lead to intermittent behaviour which might not be found until late in the product life cycle.


  • Reset – Incorrect handling of asynchronous reset release or de-assertion can lead to metastable events if reset release changes during the flip flop’s hold or set up time. As the relationship between the reset and clock is asynchronous, this relationship will change each time the board is powered. We also need to consider the internal routing delays of the reset signal; what may look good at the pins is still an issue at the flop as delays in routing can also introduce metastability.


  • Finite State Machine (FSM) Behaviour – FSM are the heart of our designs; they are how we implement sequential control structures in our FPGA and ASICs. The more complex the FSM, the harder it is to visualise and ensure all states are reachable and that a transition to a state is not terminal. If state machines have inadvertent terminal states, the state machine will lock up and be unrecoverable unless power cycled or reset.


  • Longest Path – Long combinatorial paths between registers impacts the maximum frequency with which we can achieve timing closure. This can also cause issues during the place and route when paths which fail timing are incorrectly reported as being the longest path (In reality they are the longest paths failing timing).


When we generate our designs, we are of course aware of these issues and attempt to mitigate these using independent code reviews and coding standards. However, as designs get larger and more complex it is hard to detect and verify them all.

This is where tools such as Blue Pearl Software’s Visual Verification Suite comes into their own. Let’s take a quick look at how we can use the suite of tools to identify and address these issues.

When we load a design into the suite, the design is subject to several (configurable) load checks, which check for missing assignments and reset behaviour along with several other checks. These load checks enable us to identify issues such as asynchronous reset synchronisation, missing assignments and undriven logic.


To ensure our FSMs behave as expected, we can use the FSM viewer to visually verify the behaviour of the state machine. This is to ensure that each state has entry and exit points and that no state becomes a terminal state from which once entered there is no exit.


Of course, at the heart of suite is the Clock Domain Clocking (CDC) analysis capability, which enables us to identify Clock Domain Crossings which are not correctly synchronised. Once identified we can quickly and easily implement a solution which addresses the identified issue. As in the example below where the empty flag is used in conjunction with the write clock without synchronisation, this will at times result in a very hard to find intermittent metastability issue.


Now we have outlined some of the key design challenges which can impact our design late in the development cycle or even worse in the field and how we can identify and correct these. Over the next few blogs we are going to take a deeper look at how we can use the suite to identify and correct these issues.

If, however, you cannot wait, why not join me at DAC 2019 in Las Vegas where I am running a lunch and learn on Monday at the Blue Pearl Software booth #345.  I will be demonstrating how we can use Visual Verification Suite to find and correct these design issues and more.

Getting Started with Blue Pearl Issue One: Introduction

Our FPGA and SoC designs are increasingly complex and used for a wide range of applications from autonomous driving to image processing, machine learning, defence, aerospace and space applications.

Of course, while complexity has increased the available development time has been static or reduced. Indeed, both the AspenCore embedded survey 2017 and 2019 indicate the two largest challenges in delivering a project are meeting schedule and debugging the application[1].

When it comes to developing our FPGA and SoC based solutions, just like in any engineering endeavour the earlier we can identify issues the easier, timelier and less costly they are to address.

Early identification of issues within our FPGA or SoC design is where Blue Pearl Software comes into its own. If this is the first time you have come across Blue Pearl, their suite of verification tools enables us to Visualize the design, Verify the structure and Validate the design.

In this series of blogs, we are going to explore how we can use Blue Pearl’s Visual Verification Suite™ and leverage its capabilities to assist in our FPGA/SoC designs.

In this first blog we are going to start at the very beginning and look at what design visualisation features = the suite offers to use as FPGA/SoC Designers.

Blue Pearl’s visualisation of the design enables us to perform the following:

  • Analyze RTL™ linting and debug – This enables us to ensure coding standards are followed, analyse the design for several structural issues, verify the design complies with manufacturer coding standards e.g. Xilinx Ultrafast Methodology, run path analysis and explore finite state machines.
  • Clock Domain Crossing – Analyse design and clocking structures to ensure CDC is implemented correctly in the design.
  • Automated SDC generation – Identified false paths and multi-cycle paths in your design and generated the appropriate SDC file.

To provide visibility of the results of the analysis and verification checks the Management Dashboard is provided.

In the remainder of this blog we are going to look at where in the development cycle we should use the Blue Pearl suite, and how we can get started with our first design.

As I mentioned previously, the earlier we can identify issues the easier and less costly they are to address. As such we should be using Blue Pearl throughout the development of the HDL prior to starting simulation.

Of course, the following stages of development simulation, synthesis and place and route can result in RTL changes. If there are RTL changes, we should re run the Analyze RTL to ensure no issues have been introduced.


Once we have the Visual Verification Suite  Installed (you can get a evaluation copy here) the next step is to open the suite and then open the getting stated design example.

To open the getting started example we should select Help->Open Example Project -> Getting Started and then select your preferred language VHDL or Verilog.  As I am a VHDL user I will open the VHDL design entry example.


To load in the design files, we need to select the Design Settings button


To actually add RTL files, we need to click on the green add file option under the Design Files option


Once all the source files are added, click on OK and the click on load design back on the suites start page. After a few second you will see the design has loaded and that there are no errors but some warnings.


With the design loaded we can start examining the RTL design analysis. The first step of which is to open the Real Time Analysis and Dependency viewer.

We can open the Real Time Analysis viewer by clicking on the highlighted button below.


This will open the Real Time Analysis and Dependency viewer. The dependency viewer does not outline the hierarchy instead it outlines how the files are interrelated.


Understanding this interrelationship is very useful when we come across issues during design loading.

Now we have our design loaded we are ready to start exploring our design space using the suites analysis and design checking options.

We will start looking at these in the next blog soon!

Improving the quality of spacecraft RTL using HDL linting

If you have ever aspired to write out-of-this-world RTL, there’s never been a better time as satellites, spacecraft, landers, and rovers are increasingly using FPGAs and ASICs in their sub-systems.

Some recent peer-reviews have highlighted poor coding techniques that have resulted in space-electronics failures, e.g. a $1M CubeSat becoming inoperable by getting trapped in a finite state machine’s dead state. HDL linting, including structural static analysis, can check the quality of RTL before simulation, synthesis, and implementation, and has proven to be so effective in identifying bad practices for high-reliability applications that some satellite manufacturers now mandate their HDL programmers lint files before they are formally checked-in. The run time is significantly shorter than logic simulation and it can be performed early in the design cycle, where mistakes are less expensive, and while RTL is being developed, without requiring an exhaustive testbench.

Linting parses RTL identifying issues such as race conditions, register conflicts, bus contention, implied latches, redundant logic, X-propagation, long paths, and dead states. The analyses allows company-specific standards to be set up to enforce coding clarity and naming conventions.

Structural static analysis can find false paths directly from the RTL where no sequence of inputs results in an event propagating along the path and can thus be ignored for timing analysis and optimising performance. For example, the path from Register B to C shown below can never be sensitised because the output from the cloud of logic is de-selected at MUX2.

Figure 1 Example of single-cycle false path

Some false paths require multiple cycle across many levels of hierarchy to complete their function such as pulse generators or pipelined structures. For example, Select1 and Select2 shown below cannot be high at the same time resulting in a false path.


Figure 2 Example of multi-cycle false path

Structural static analysis can find the longest path critical to achieving timing closure and device fit: identifying false and multi-cycle paths directly from the RTL helps synthesis and implementation avoid unnecessary effort to meet timing or other optimisations on those nets. Needlessly placing and routing false paths can cause critical logic to miss closure!

Linting improves the quality of reliability (QoR) of RTL by identifying poor coding early in the development cycle when engineers are under less pressure to finish. It reduces design risk, accelerates IP verification, increases productivity, and reduces debugging effort and test time spent in the lab to meet time-to-market deadlines.

An example of linting and structural static analysis increasingly being adopted by the space industry to improve the quality of RTL and sign-off IP is Blue Pearl’s Visual Verification Suite. By using this software, Orbital ATK working on a NASA project recently detected 24 clock-domain crossing (CDC) errors in production SpaceWire IP that were not picked up by traditional formal-verification methods.

The Visual Verification Suite parses RTL before simulation and synthesis checking for quality and reliability problems followed by CDC investigations. Code is analysed in a sequence where the first issues addressed are either those whose solution will also fix other faults or may cause or reveal other types of problems that can then be examined separately. The diagram below illustrates where HDL linting and structural static analysis fits within the standard FPGA/ASIC design flow.


Figure 3 Blue Pearl’s HDL linting flow

Spacechips peer-reviews space electronics and RTL for many satellite and spacecraft manufacturers and we have started evaluating Blue Pearl’s Visual Verification Suite to check the quality of third-party IP. Given that we do not always know the original design intent, HDL linting has proven to be useful in debugging and verifying the functionality of code. A very useful feature of the software is its ability to automatically detect and quickly validate the behaviour of finite state machines using bubble diagrams to display all states and transitions between them, as well as identifying unreachable ones. Previously, we would have written exhaustive test benches, which is time consuming.

The software also analyses CASE statements reporting duplicate, overlapping, or missing items, as well as absent assignments or the default clause. The linter can be extended, allowing custom checks to be created using Tcl or SDC (timing constraint) commands. During linting and structural static analysis, the tool can be controlled using its interactive GUI or run automatically in batch mode using Tcl.

As digital space electronics complexities increase, avionics engineers are increasingly using commercial or existing IPs to meet time-to-market deadlines. Typically, these come in various formats, (e.g. synthesizable RTL, encrypted IP, simulation models, or non-synthesizable HDL), often from disparate sources, and operate with independent clocks with different frequency and phase relationships, i.e. separate domains.

With multiple domains containing non-integer-related or drifting clocks, one has to verify the synchronicity of signals going between them. CDC occurs when data is transferred from a flip-flop driven by one clock to another triggered by a different clock. Setup and hold violations can result in metastability, which can propagate through a design as an erroneous state causing functional failure. Traditional simulation and static-timing analysis cannot model this behaviour and are unable to confirm if data is transferred consistently and dependably across domains.

If third-party IP is delivered as synthesizable RTL, then CDC analysis can be performed on these. However, for other formats, instantiated blocks have traditionally been imported as black boxes, containing sensitive, proprietary IP, and the analysis has been unable to use any knowledge of their internals nor information regarding the interaction of ports with clocks.

The Visual Verification Suite supports the concept of a grey cell that provides clocking and register information for third-party IP, allowing for accurate CDC analysis beyond what is possible using the traditional black-box methodology. A grey cell is a representation of a module that excludes all internal register-to-register logic, including only all logic from each input up to and including the first register, and all logic from each output back to and including the last register. Grey cells preserve the confidentiality of third-party IP as shown below.


Figure 4 Black-box IP vs. grey-cell IP

For users of space-grade FPGAs, Blue Pearl’s Visual Verification Suite is supported by Microsemi’s Libero SoC and Xilinx Vivado IDEs. To help the space industry manage increasingly complex designs instantiating IPs from many different sources, e.g. FPGA/ASIC providers, space agencies, OEMs and third-parties, I recommend that all providers of high-reliability FPGAs and ASICs include linting and structural static analysis within their design environments to allow HDL programmers to improve the quality of RTL.

HDL linting, including structural static analysis, improves the quality of spacecraft RTL and reduces risk earlier in the design cycle, allowing IP to be signed-off with confidence. I intend to continue the discussion by presenting a webinar sharing examples of poor coding and demonstrating how Blue Pearl’s Visual Verification Suite improves QoR of RTL, accelerates IP verification, decreases development time, and increases productivity to help meet time-to-market deadlines.