Category Archives: Blog

Issue 19: A slogan is just that, a slogan

A slogan is just that, a slogan or sometimes referred to as a tag line. Something catchy, something fresh and, of course, something we hope you don’t forget. So, with Blue Pearl Software’s slogan, ‘verify as you code’, we hope it conjures up a feeling that as you code, a smart editor is keeping watch. Making sure no mistakes sneak into the design, be it syntax, structural and even security issues.

So, what’s behind our slogan? Twenty-four years of technology to start with. Simply put, we have been helping HDL (VHDL / SystemVerilog) developers for quite some time. Over these years, we have refined the Visual Verification Suite to help FPGA and IP developers find critical issues up front in the design process, saving both time and money. We can honestly say, when you write code using the Visual Verification Suite’s HDL Creator smart editor, your HDL is verified as you code.

HDL Creator is ideal for developers coding both RTL and test benches who are seeking productivity, predictability and code quality for complex FPGAs and IP. HDL Creator provides real-time syntax and style code checking inside an intuitive, easy-to-use full featured editor. Unlike standard editors, HDL Creator provides advanced real-time file analysis to find and fix complex issues as you code, such as compilation dependencies and missing dependencies.

HDL Creator is a full-featured source code editor that provides all the normal features you would expect from a modern code editor such as autocomplete and error fix suggestions. HDL Creator provides over 2000 real time syntax and customer specific coding standard checks to streamline code development, saving time and effort all while averting common coding mistakes that could result in downstream design iterations. HDL Creator also provides advanced design views to help understand, verify, and debug as you code.

In addition to HDL Creator, the Visual Verification Suite also provides advanced static and formal RTL analysis to identify coding style and structural issues up front. While not real-time, like HDL Creator, the suite’s RTL Analysis points out 100’s of additional potential structural issues 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 analyze 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 analyzed to ensure there is no clock gating or generation of internal clocks.
  • Safe Counters – Checks counters to 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 or unused code – Analyzes and warns about unused or dead code in the design. This can be removed prior to functional simulation and reduces head scratching when code coverage cannot be achieved.
  • Clock domain crossing – Ensuring clock domain crossing are synchronized to avoid metastability issues.


Figure 1: Visual Verification Suite’s CDC Viewer

So, what is it that makes the Visual Verification Suite such a powerful debugging environment? It runs on Windows or Linux, and lets you easily move back and forth between command line mode and a straightforward, understandable graphical user interface. It can quickly generate reports that show aspects of your design in general, like your highest fanout nets, or your longest if-then-else chains, and an easy-to-filter report window showing the specific issues it has found. The suite also includes numerous checks to catch violations of company specific naming conventions.


Figure 2: Finite State Machine Viewer

Design teams that leverage static verification as part of their functional verification methodology are proven to reduce hardware security risks, as well as expensive and time-consuming simulation, synthesis and place and route runs and reruns, freeing up expensive licenses as well as improving overall design productivity.


Find and fix issues as you code, not late in the design cycle

Blue Pearl’s Visual Verification Suite, used early and often in the design process as opposed to as an end of design/sign-off only tool, significantly contributes to design security, efficiency, and quality, while minimizing chances of field vulnerabilities and failures.

We hope our slogan, ‘verify as you code’ comes to mind the next time you or your team develops an FPGA. To learn more, we encourage you to sign up for a demonstration to learn more how the Visual Verification Suite can ensure quality code for high reliability FPGAs.

Issue 18: So, what’s a Grey Cell anyway…

They say with a chain, it is only as strong as its weakest link. The same can be said about an EDA tool chain for developing and verifying FPGA and ASIC designs. In fact, one of the most significant challenges in the development of a design is verification, and surprisingly it is not the home-grown portions of code, it’s typically the verification of 3rd party IP cores in the context of the overall design.

On average, most designs bring together between 50 to 100 different IP cores that must be integrated as part of the overall chip. In many cases, designers who are doing the integration neither have access to the core source code or if they do, do not have a deep understanding as to how it works. This adds tremendous difficulty during integration and verification.

It thus becomes incumbent upon EDA providers to alleviate verification bottleneck with new methodologies and functionality. This is exactly what Blue Pearl Software has done for Clock Domain Crossing (CDC) analysis with its patented User Grey Cell technology.

CDC analysis involves finding issues which will result in metastability within Flip Flops (FFs) because of data crossing clock boundaries. Unsynchronized CDCs represent the bulk of the problem for FPGA and ASIC failures in the field according to recent studies. The Visual Verification Suite identifies unsynchronized CDCs with source clock, destination clock and target FFs information so they can be quickly found and fixed.

So, what’s a Grey Cell?

A Grey Cell, as depicted in Figure 1 below, is a representation of a module which excludes all register-to-register logic. A grey cell model is an abridged version of a piece of IP that allows for CDC analysis of the interface to the IP while simplifying the overall system analysis, significantly reducing run times while concealing the proprietary content of the IP. It’s in essence one step beyond a black box, with only one clock cycle’s worth of circuitry inside. It consists of all the ports of the IP (which is where a black box stops), plus all the logic between the input ports and the output of the first register, and the last register plus all the logic from there to the output ports.

Any combinational paths through the block are also preserved, as well as all logic driving the clocks and resets of those input and output registers. Everything else is removed from the model. Thus, the only information required is the names and directions of the I/O ports, which ports are clocks and resets, and which clock and reset are associated with each I/O port’s register.

There are several ways to create a Grey Cell model. You could write it from scratch in RTL using the information outlined above. You could also start with the entire module, proprietary parts and all, analyze it, and throw away everything not needed for the grey cell model. This second method is used when a module is given a grey cell attribute, so the tool ignores the detailed model. Lastly is the creation of a “User Grey Cell”, which is an XML library file, readable by the Visual Verification Suite, that contains only the necessary information. The Visual Verification Suite’s Grey Cell editor streamlines this process.

To streamline CDC analysis for FPGAs, Blue Pearl is integrated with and ships with Grey Cell libraires for many of the AMD/Xilinx and Intel cores provided in the Vivado ML Editions and Quartus Prime design software suites.

A Grey Cell differs from a black box in that a black box has no logic inside. With a black box, you can analyze connectivity only. Grey cells enable the analysis of CDCs in module-to-module connections while masking the details and preserving the trade secrets of the original IP provider.


Figure 1: Grey cell vs. Black Box

Accelerating CDC Analysis with a dramatic reduction in runtime

To illustrate how Grey Cells improves CDC analysis accuracy while dramatically reducing runtimes, consider the diagram shown in Figure 2 where the entire RTL descriptions of “module1” and module2” are available. It is apparent that both outputs of module1 should be synchronized, since ck1 is connected as the input clock and ck2 as the output clock. Also, synchronization is required at the d2 input of module2, since ckb is connected to ck2. There are no CDCs within module2. Since all the details are known, a CDC analysis will reveal whether synchronization has been properly implemented, but the analysis may take a long time if both modules are large and complex.


Figure 2: CDC Detected during RTL Analysis

In Figure 3, both module1 and module2 have been replace by black boxes. All information about which clock is associated with which data pin has been lost. In fact, it’s only by guessing based on the signal names that you might infer that each module has two clocks. In this example, CDC analysis is not possible.


Figure 3: Modules have no details when defined as Black Box

Now with a Grey Cell version shown in Figure 4, the interior details of both modules are unavailable, but the identity of the clocks and their relationships to the data inputs and outputs are known. With this, you can infer the need for synchronization within module1 given that all the inputs have a different clock than all the outputs, but you need to trust that this has been done properly. Within module2, synchronization may or may not be needed; there is no way to tell. The truth is, if these modules are both 3rd party IP, you couldn’t make the necessary changes to fix any issues that did exist. Those issues remain the responsibility of the vendor.

However, the CDC at the d2 input of module2 can be detected and dealt with despite not having full details about the interior design of each module. In addition, the analysis will not be slowed by analyzing interior details that can’t be fixed anyway.


Figure 4: Modules have fewer details when defined as Grey Cell

The Visual Verification Suite also supports the IEEE 1735 encryption standard, however encrypted information can be decrypted by bad actors, absent information can’t. This makes a User Grey Cell model inherently more secure with the added benefit of significantly improved run times.

If your CDC analysis tool is taking too long and is no longer handling complex designs or is just so hard to use that it doesn’t get used, then it just might be the weakest link in your tool chain. If so, it’s time for a change! We would be happy to show you why Blue Pearl customers have chosen to our Grey Cell technology along with the Visual Verification Suite for tackling CDC issues in the most complex designs.

Request a demo to learn more.

Issue 17: Code Quality Essentials for High Reliability FPGAs – Part 3

When designing FPGAs, code quality is essential to staying on schedule, avoiding design iterations and worse, bugs found in production. This is especially true when it comes to high reliability applications such as automotive, space and medical devices where bugs can be extremely expensive or impossible to fix. But just what makes RTL (VHDL or SystemVerilog) quality code? The answer is, well, there isn’t just one thing that makes for quality code. It’s a combination of considerations from readability to architecture choices.

In Part 1 of this blog series, I focused on readable and maintainable RTL code, highlighting some best practices. In Part 2, I deep dived into Finite State Machine (FSM) architectures and coding guidelines. Finally in Part 3, I will focus on the challenges concerning multiple Clock Domains.

Clock Domains

Modern design, used in high reliability applications, often contains several clock domains. Of course, information needs to be shared between these domains. Incorrect synchronization of data and signals between clock domains can result in metastability and corrupted data. In some systems this incorrect data can be catastrophic. The understanding of Clock Domain Crossing (CDC) origins boils down to a few simple truths. There is clock drift from separate sources. As digital designers, we must plan for this.

At its most basic level, metastability is what happens within a register when data changes too soon before or after the active clock edge; that is, when setup or hold times are violated. A register in a metastable state is in between valid logic states, and the process of settling to a valid logic state takes longer than normal. It will eventually fall into a stable “1” or “0” state, but there is no way to predict which way it will fall or how long it will take. Think of it as tossing a coin millions of times. There are actually three possibilities: heads, tails, or once in a great while the coin just might stick the landing and end up on its edge, if only for a while. The question is, will that while be longer than a clock cycle? That’s metastability.

When data is transferred between two registers whose clocks are asynchronous, metastability will happen. There is no way to prevent it. All you can do is to minimize its impact by placing the two clocks in different clock domains and using a clock synchronization technique at the crossing point. Hence the name “clock domain crossing”.


Figure 1 Data Metastability

Putting two clocks into the same clock domain is a declaration that these two clocks are synchronous to each other, and crossings between them do not need to be synchronized. If the clocks are from the same source, or one is derived from the other, then they are synchronous and can be placed into the same clock domain.

Clocks that are asynchronous to one another should always be placed in different clock domains, and any CDCs between them need to be synchronized. Even two clocks of the same frequency should be placed into different domains if they come from independent sources. Unfortunately, two independent clock sources of the same frequency will drift relative to one another over time and cause metastability problems.

Synchronizers

The simplest synchronization method for a single bit is to have two consecutive registers in the receiving domain. This is known as double-register synchronization. By requiring any metastable state that occurs to pass through two registers, it reduces the chance of metastability from 1/r to 1/r2, which is acceptable for most purposes. Data integrity is maintained only by coincidence. Since it’s only one bit, the only two possibilities are that it will happen to match either the preceding clock cycle or the subsequent clock cycle.

One of the most popular methods of passing data between clock domains is to use a FIFO. A dual port memory is used for the FIFO storage. One port is controlled by the sender, which puts data into the memory as fast as one data word (or one data bit for serial applications) per write clock. The other port is controlled by the receiver, which pulls data out of memory; one data word per read clock.

Two control signals are used to indicate if the FIFO is empty, full, or partially full. Two additional control signals are frequently used to indicate if the FIFO is almost full or almost empty. In theory, placing data into a shared memory with one clock and removing the data from the shared memory with another clock seems like an easy and ideal solution to passing data between clock domains. For the most part it is, however generating accurate full and empty flags can be challenging.


Figure 2 FIFO Bus Synchronization

Another CDC issue that must be addresses is that of data reconvergence, when two data signals are combined after being independently synchronized between the same two clock domains. This is a problem because synchronization is inherently an arbitration to avoid metastability. A new value will be correctly clocked, without metastability, on one of two successive receiving clock cycles. There’s no way of knowing which. The two signals in question can be arbitrated differently and can end up being clocked into the receiving domain on different clock cycles when correct operation depends upon their remaining in step. Think again of the coin toss. With a single bit, it’s all but certain that the coin will end up either heads or tails, but with multiple bits, you’d need either all heads or all tails. That’s a losing bet.


Figure 3 Signal Reconvergence

The implication is that, for a data bus that crosses clock domains, having individual synchronization on each of the bits will not work reliably. One solution is to generate a single bit “data valid” flag which indicates that the data is stable. Synchronize that flag across domains, and then use it to enable the clocking of the data bus into the new domain.

Another solution is to ensure that the data itself is “gray” (only one bit changing on any given clock cycle) with respect to the receiving clock. This is easier when crossing from a slower to a faster domain because you can be sure there will not be multiple changes from the perspective of the receiving domain. The handshake synchronizers use two m-flip-flop synchronizers to generate request and acknowledge signals.

How to identify CDC Issues:

Blue Pearl Software’s Advanced Clock Environment (ACE) provides a graphical representation summarizing data paths between clocks and can make recommendations for grouping of clocks into clock domains. With ACE, designers can identify clocks to better understand how they interact with synchronizers in the design. This allows users to quickly identify improper synchronizers or clock domain groupings that cause CDC metastability.


Figure 4 Advanced Clock Environment

ACE addresses a fundamental chicken-and-egg problem with automated CDC analysis. To perform a CDC analysis, you first must properly define your clock domains, but in order to automatically define clock domains, you need to perform a CDC analysis. ACE does this by performing a quick-and-dirty CDC analysis that recognizes only double-register synchronization, and then by explicitly assuming that two clocks are in the same domain if a high percentage (80% by default) of CDCs are unsynchronized. Then the clock domains, whether defined automatically or by the user, are analyzed and graphically displayed.

The overall goal of ACE is to enable engineers to find metastability issues in designs by properly grouping clocks into clock domains. Design and Verification engineers use ACE to ensure the clock domains are properly specified before running a CDC analysis. ACE will quickly find errors in clock domain groupings or find/recommend appropriate clock domain groupings for a circuit that is synchronized. Only then can a correct and comprehensive CDC analysis be performed.

Next, the Visual Verification Suite’s CDC Analysis understands FPGA vendor clocking schemes, saving enormous resources to set up designs. The CDC analysis has built-in intelligence that helps set up the CDC run and rapidly debug issue found using the built-in cross-probing and schematic display.


Figure 5 Visual Verification Suite CDC Analysis

One of the strengths of the Visual Verification Suite’s CDC analysis is that it flags all CDCs, whether unsynchronized, properly synchronized, or improperly synchronized. For example, using a double-register scheme on a single bit is perfectly appropriate, but a multi-bit bus requires a more robust synchronization technique. The user even has the option to find what we call “Clock Equivalent” crossings, which are clock-to-clock interactions within the same clock domain.

Visual Verification Suite, used early and often in the design process as opposed to as an end of design/sign-off only tool, significantly contributes to design security, efficiency, and quality, while minimizing chances of field vulnerabilities and failures.

To learn more about the Visual Verification suite, please request a demonstration.

Issue 16: Code Quality Essentials for High Reliability FPGAs – Part 2

When designing FPGAs, code quality is essential to staying on schedule, avoiding design iterations and worse, bugs found in production. This is especially true when it comes to high reliability applications such as automotive, space and medical devices where bugs can be extremely expensive or impossible to fix. But just what makes RTL (VHDL or SystemVerilog) quality code? The answer is, well, there isn’t just one thing that makes for quality code. It’s a combination of considerations from readability to architecture choices.

In Part 1 of this blog series, I focused on readable and maintainable RTL code, highlighting some best practices. Part 2 will now deep dive into Finite State Machine (FSM) architectures and coding guidelines. Finally, part 3 will focus on the challenges concerning multiple Clock Domains.

FSM Architectures and Coding Guidelines.

Before we focus on a specific architecture, let’s recap the different methods or protections we might use on our state machine and what we are protecting against. If a single-event upset (SEU, a radiation- induced change in the bit in one flip-flop) occurs in a state register, the FSM that contains the register could go into an erroneous state or could “hang,” by which is meant that the machine could remain in undefined states indefinitely or requiring a reset of the FSM as the only way to recover.

Obviously, in many applications, this is not acceptable or is completely impractical. We want the state machine to be able to either continue operating (tolerance) or detect a failure and fail safe (detection).

To ensure reliability of the state machine, the coding scheme for bits in the state register must satisfy the following criteria:

  1. 1. All possible states must be defined
  2. 2. A SEU brings the state machine to a known state
  3. 3. There is no possibility of a hang state
  4. 4. No false state is entered
  5. 5. A SEU exerts no effect on the state machine

Tolerance

When it comes to tolerance there are two mechanisms we can use:

  • Triple Modular Redundancy (TMR) — With TMR three instantiations of the state machine are created, and the output and current state are voted upon clock cycle by clock cycle. TMR is a good approach, but it does require three implementations and ensuring physical separation of the three implementations to ensure only one FSM is corrupted. For more on TMR I recommend that you view Xilinx Isolation Design Flow. This documented flow can be especially useful for ensuring physical separation in the chip.
  • Hamming Three Encoded — With a Hamming three encoded state machine, each state is encoded with a hamming distance of three between them. This prevents a SEU from changing between valid states, as the SEU can only flip a single bit. In a Hamming three, each state has several adjacent states which also cover the possible states to which a SEU could change the Hamming three state. This adjacent state behaves the same as the original state, hence allowing the state machine to tolerate the SEU and keep operating. It does, however, mean the number of states declared is large. For a 16 state FSM encoded sequentially, seven bits are needed to encode the 16 states separated by a Hamming distance of three. This means there are N * (M+1) states required, where N is the number of states and M is the register size.

Both the TMR and Hamming three structures require considerable effort from the design engineer unless the structure can be implemented automatically by the synthesis tool.

Detection

When it comes to detection, the structures used are considerably simpler:

  • Hamming Two (sequential + parity) — This method encodes the state with a Hamming distance of two. Should a SEU occur, the error can be found using a simple XOR network and the state machine can be recovered to a safe state to recommence operation.
  • Default Case / When Others —This method uses the Verilog default or VHDL when others to implement a recover state. This does require that the synthesis tool does not ignore the default case or when others, and that the user does not define them as null or do not care.

Hamming Two is the best compromise in terms of size, speed, and fault-tolerance and is preferred over both binary and one-hot state machine encoding for high reliability designs. Hamming Three encoding is the best fault-tolerant to single faults and, therefore, preferred when ultimate reliability is required in a critical application, however it is slower and larger than other implementations.

Static Verification of FSMs

As mentioned earlier, for highly reliable FSMs, all possible states must be defined and there must be no possibility of a hang state.

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 behavior 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. The Visual Verification Suite provides an FSM viewer and reports that help pinpoint any issues, up front, as you code.


Figure 1 Visual Verification Suite FSM Viewer

Many of the suite’s predefined rules focus upon the structural elements which may be incorrect in the design 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 analyze 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 analyzed 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 or unused code – Analyzes and warns about unused or dead code in the design. This can be removed prior to functional simulation and reduces head scratching when code coverage cannot be achieved.

Visual Verification Suite, used early and often in the design process as opposed to as an end of design/sign-off only tool, significantly contributes to design security, efficiency, and quality, while minimizing chances of field vulnerabilities and failures.

To learn more about the Visual Verification suite, please request a demonstration, and check back for Part 3, the challenges around multiple Clock Domains.

Issue 15: Code Quality Essentials for High Reliability FPGAs – Part 1

As a young hardware engineer, I started using programmable logic. What could be better, aside from maybe the price and power. You didn’t have to be too disciplined during the design phase because you could just reprogram the device if you had a bug or two. Heck your boss didn’t even have to know, just fix it in the lab. No PCB rework needed.

Even though this was years ago, and devices were no where near as complex as today’s FPGAs, this mindset still separates FPGA from ASIC design. With ASICs there can be a large non-recurring engineering cost and no forgiveness for design bugs, therefore up-front verification is not an option.

The “I can just fix it” FPGA attitude is a major reason a recent study showed that 68% of FPGAs are behind schedule and 83% of projects have a significant bug escape into production. On top of that, code that’s developed this way and at the time was deemed “good enough” has a habit of sticking around to become what’s knows as “legacy code” that no one wants to touch because it’s so poorly written that no one on the team today has any chance of understanding what it’s really doing.

When designing FPGAs, code quality is essential to staying on schedule, avoiding design iterations and worse, bugs found in production. This is especially true when it comes to high reliability applications such as automotive, space and medical devices where bugs can be extremely expensive or impossible to fix. But just what makes RTL (VHDL or SystemVerilog) quality code? The answer is, well, there isn’t just one thing that makes for quality code. It’s a combination of considerations from readability to architecture choices.

Over this series of blogs, we will investigate and do a deep dive into specific aspects of “quality code”. Part one will focus on readable and maintainable RTL code, highlighting some best practices. Part two will be a deep dive into Finite State Machine architectures and coding guidelines and part three will focus on the challenges around multiple Clock Domains.

Readable and maintainable code

During a code review, early in my career, my lead engineer had the audacity to take my code printout and throw it in a garbage can. Of course, as a young engineer I was flabbergasted because I had simulated the code and it worked like it was supposed to, or so I thought. He then said, in a reassuring voice, “now let me show you how to code so someone else can figure it out.”

What I learned next was that readable and maintainable code took some common discipline, starting with the basics such as naming conventions. It’s not so much whether the organization prefers big endian or little endian, spaces or tabs, prefixes or suffixes, underscores or hyphens or camel case, the important thing is to have a standard and stick to it. By standardizing on naming conventions for architectures, packages, signals, clocks, resets, etc. my code became clearer and as a side benefit, it reduced the code complexity. Going through code by hand to uphold those standards is incredibly tedious, but the task can be easily automated with a static analysis tool.

A simple and common mistake I made was to use hard coded numbers, especially in shared packages. While as the original coder I may understand exactly why I hard coded that specific number, 10 years down the line, when it’s time to update the device or functionality, the use of a hard coded number will add to confusion and delays.

Back to my code simulating, what I didn’t see lurking in my code were things that made it ripe for simulation vs synthesis mismatches. For example, variables that are used before they’re assigned might be unknown or might retain a previous value, which means possible mismatches between the simulation and actual functionality after synthesis. This simple mistake can mean the design works in simulation but then later fails in the lab or, worse, in the field.

Another common example of code quality issues is missing assignments in IF and Else blocks and case statements that will cause most synthesis tools to create latches in the design along with the registers. Implied latches can cause issues with timing, and different synthesis tools will do this in different ways, so change vendors, change implementations.


Figure 1 Latch vs Flip Flop

The goal of any tool is to succeed, and synthesis tools want to synthesize successfully, so they may give your code the benefit of the doubt, and assume your code is right until it’s proven wrong. Many tools will even accept common poor practices and “fix” them for you. Again, different tools, different “fixes.”

Another code quality issue is synchronous de-assertion of asynchronous resets. Some people pay little attention to how their reset will work in the real world. They just throw in a global reset just so the simulation looks “tidy” at Time Zero, but this isn’t enough. That reset must work in the real world. Keep in mind, a global reset is just that, global, so it has a large fanout and may have a significant delay and skew, so you need to buffer it properly. And because this reset is asynchronous, by definition it can happen at any time, and it forces the flip-flops to a known state immediately. That’s not a problem, but the de-assertion issue comes not when your reset pulse begins, but when it ends relative to the active clock edge. The minimum time between the inactive edge of your reset and the active edge of your clock is called recovery time. Violating recovery time is no different than violating setup or hold time. The easiest way to avoid this issue is to design your reset as shown here. The active edge can happen at any time, but the inactive edge is synchronous with the clock.


Figure 2 Asynchronous Reset

Finding and addressing code quality issues, such as naming conventions, reset issues, excessive area, low frequency and meantime between failures up front, as you code can significantly reduce the number of iterations through synthesis and place and route, improving productivity, reducing development costs and improving the reliability of a design.

When designing FPGAs, code quality is essential to staying on schedule, avoiding design iterations and worse, bugs found in production. The Visual Verification Suite from Blue Pearl Software provides RTL Analysis to identify coding style and structural issues up front. The RTL Analysis points out naming conventions as well as structural issues such as long paths and if-then-else analysis as you code, rather than late in the design cycle.


Figure 3 Visual Verification Suite

So, what is it that makes the Visual Verification Suite such a powerful debugging environment? It has a straightforward, understandable graphical user interface that runs on Windows or Linux, and quickly generates reports that show aspects of your design in general, like your highest fanout nets, or your longest if-then-else chains, and an easy-to-filter report window showing the specific issues it has found. The suite also includes numerous checks to catch violations of company specific naming conventions.


Figure 4 Finite State Machine Viewer

From these reports, or from the main window, you can open the schematic viewer directly to the area of interest, and with just a few mouse clicks you can turn that into a path schematic to isolate the issue even further. On top of that it provides views that help you with finite state machine analysis, CDCs, and long combinational paths. To learn more, we encourage you to sign up for a demonstration to learn more how the Visual Verification Suite can ensure quality code for high reliability FPGAs.

Check back for Part 2, A deep dive into Finite State Machine architectures and coding guidelines and Part 3, the challenges around multiple Clock Domains.

Issue 14: Accelerated Verification of Block-Based FPGA Designs

FPGA designers face increasing challenges with time-to-market due to the combination of increased FPGA complexity and performance. This often moves the engineer away from hand crafting each element of the design and toward using IP cores provided by device vendors and other third-party suppliers. Using off the shelf IP frees the engineer to focus on the development of custom blocks, which are critical for the application and where their special value-added knowledge is applied.

Blue Pearl’s Visual Verification™ Suite helps developers address these time-to-market and complexity challenges. The suite enables the engineer to achieve tighter development time scales, by identifying issues with custom developed RTL, such as FSM errors, bad logic or design elements which may impact performance in simulation or implementation. With the suite, issues are found early in the design cycle, as you code, not late in the design or worst, in the lab.

In addition, the Visual Verification Suite can analyze the complete design to ensure there are no accidental Clock Domain Crossings (CDCs) introduced between custom IP blocks and vendor or third-party IP.

Working with vendor and third-party IP can be a challenge, especially when interfacing with tools like Intel® Quartus® Prime and its Platform Designer (formerly Qsys). This challenge can occur as the architectural diagram is created visually and pulls together several RTL files, typically encrypted, to correctly describe the IP modules and the overall architecture. If not handled correctly the engineer could be swamped by messages when using static analysis tools like the Visual Verification Suite. These messages/warnings result from coding structures within the vendor and third-party IP encrypted blocks so the user can do nothing about them.


Example Quartus Platform Designer Block Diagram.

Here Blue Pearl’s patented Grey Cell™ technology saves significant time. As the project loads, the Visual Verification Suite is aware of the vendor’s IP libraries and loads a Grey Cell model in place of the IP Core. This model contains only the first rank of input flip flops and the last rank of output flip flops. Knowing this allows the suite to perform a clock domain crossing analysis at the top level of the design without the need to look in depth into the vendor or third-party IP. This also reduces the number of messages and warnings to only the ones of interest to the developer. (Learn more about Grey Cell technology www.bluepearlsoftware.com/files/GreyCell_WP.pdf)


Grey Cell Representation of a FIFO

To be able to pull in the top-level design from Intel’s Platform Designer, Blue Pearl provides Tcl scripts in the installation directory which can be used in the Quartus Tcl window to extract the project and create a Tcl script which can be opened by the Visual Verification Suite.


The scripts directory of the Visual Verification Suite installation

Creating a Blue Pearl project Tcl script is as simple as copying the QuartusToBluePearl_sh.tcl script to the Quartus project area and then sourcing it in the Tcl console.

This will create a LoadBluePearlFromQuartus.tcl Tcl script which can then be opened by the Visual Verification Suite, and which contains all the elements and files required to get started with analysis.

Alternately, Quartus users can use the LoadBluePearlFromQuartus.sh or LoadBluePearlFromQuartus.bat Linux or Windows script to start Quartus in non-graphical mode and source the same script.

A similar flow is available for Xilinx® Vivado® users. Copy the VivadoToBluePearl.tcl script into the project directory and source it from the Vivado Tcl console to produce a LoadBluePearlFromVivado.tcl Tcl script.

Blue Pearl’s Visual Verification Suite, used early and often in the design process with Quartus Prime or Vivado, as opposed to as an end of design/sign-off only tool, significantly contributes to design efficiency, and quality, while minimizing chances of field vulnerabilities and failures.

To learn more about the Visual Verification suite, please request a demonstration https://www.bluepearlsoftware.com/request-demo/

Issue 13: Hardware Security: Risk Mitigation Requires a Security Focused Verification Methodology

Issue 13 image 1

In most SoC and FPGA designs, hardware security is now as important as power, area, and cost. In fact, the National Institute of Standards and Technology (NIST) reported a record number of Common Vulnerabilities and Exposures (CVEs) in 2021, and the year is not over yet. Given the difficulty of patching hardware, architecture choices along with an established security focused verification methodology must be in place to circumvent weakness in the logic that, if exploited, results in a negative impact to the chip’s security triad (confidentiality, integrity, or availability).

To help remediate security risk in hardware devices, in Feb. 2020, the MITRE Corporation released version 4.0 of their (CWE) list. The new version, for the first time, provides a valuable list of common hardware weaknesses, in addition to its software weaknesses, that are the root causes of many vulnerabilities.

The hardware list is categorized into major themes such as Security Flow Issues, Debug and Test Problems, Memory and Storage Issues, General Circuit and Logic Design Concerns, and so on. The CWE list has been developed to help design teams as they quantify risk exposure. In addition, it provides a valuable guide for threat modeling and secure design. By identifying potential issues early, the projected cost of a security incident can be significantly lowered or eliminated.

Over the last year, the list has continued to expand and as of version 4.6 (Oct. 28, 2021), it contains 98 common hardware weaknesses. While many of these vulnerabilities can be avoided with good architectural choices, others can be avoided with a mature design verification methodology that takes advantage of RTL static analysis.

Take for example, CWE-1245: Improper Finite State Machines (FSMs) in Hardware Logic. This CWE highlights that FSMs, if not constructed correctly, can allow an attacker to put a system in an undefined state, to cause a denial of service (DoS) or gain privileges on the victim’s system.

Many secure data operations and data transfers rely on the state reported by a FSM. Faulty FSM designs that do not account for all states, either through undefined states (left as don’t cares) or through incorrect implementation, might lead an attacker to drive the system into an unstable state from which the system cannot recover without a reset, thus causing a DoS. Depending on what the FSM is used for, an attacker might also gain additional privileges to launch further attacks and compromise the security guarantees.

With simulation alone, it is difficult to verify a complex FSM as it requires complex test vectors with both positive and negative testing to check all combinations of possible states. Fortunately, a mature RTL static verification tool such as Blue Pearl Software’s Visual Verification Suite provides without any need for test vectors, finite state machine analysis that automatically extracts the FSM from surrounding code, then checks for dead or unreachable states as well as generating an easy-to-read bubble diagram to better visualize the FSM and its potential vulnerabilities.

In addition, the suite also provides checks for coding style conformance, structure, race conditions (CWE-1298), resets (CWE-1271), as well as specific checks for functional safety protocols such as DO-254 conformance.

Issue 13 image 2

Complex Finite State Machine

Design teams that leverage static verification as part of their functional verification methodology are proven to reduce hardware security risks, as well as expensive and time-consuming simulation, synthesis and place and route runs and reruns, freeing up expensive licenses as well as improving overall design productivity.

Issue 13 image 3

Find and fix issues as you code, not late in the design cycle

Blue Pearl’s Visual Verification Suite, used early and often in the design process as opposed to as an end of design/sign-off only tool, significantly contributes to design security, efficiency, and quality, while minimizing chances of field vulnerabilities and failures.
To learn more about the Visual Verification suite, please request a demonstration https://www.bluepearlsoftware.com/request-demo/

Issue 12: Moore With Less

Moore’s law foresaw the ability to pack twice as many transistors onto the same sliver of silicon every 18 months. Fast forward roughly 55 years, some experts now think Moore’s law is coming to an end. Others argue that the law continues with a blending of new innovations that leverage systemic complexity such as 2.5D and 3D integration techniques.

FPGA vendors and their customers have taken advantage of Moore’s law for decades and reaped the benefits of innovations such as 2.5D interposer technology as well as hardened processors and application specific subsystems.  However, with these features came new hardware design challenges. According to the 2020 Wilson Research study of FPGA designs:

  • The FPGA market continues to struggle with non-trivial bug escapes into production
  • The FPGA market is rapidly maturing its verification processes to address this growing complexity
  • FPGA teams that are more mature in their functional verification methodology are likely to experience fewer bug escapes

As an example of this complexity, the study indicates that 92% of FPGA designs contain two or more asynchronous clock domain crossings (CDC). This class of metastability bugs cannot be found in RTL simulation. To simulate CDC issues requires a gate-level model with timing, which is often not available until late in the design flow, if at all.  Even if such a gate-level model is available, it would still require a detailed set of test vectors to fully exercise the area of the circuit where the CDC exists, a daunting task at best.

The study also pointed out that 68% of designs miss their schedule! While there are several reasons for this, with static verification tools such Blue Pearl’s Visual Verification Suite, project teams avoid costly and time-consuming design spins due to simulation versus hardware mismatches, invalid timing constraints and CDC issues that can cause metastability problems.

In addition, with static verification, 63% of trivial human errors or typostypically not found until simulation (sourceDVCon U.S. 2018) can instead be identified early as the design is being created. By “shifting verification left”, design teams have been proven to save time along with delivering on a much more predictable schedule.

Mature RTL static verification tools such as Visual Verification Suite provide coding style conformance, structural, path, reset, and finite state machine analysis, as well as specific checks for DO-254 and STARC conformance.


Find and fix issues as you code, not late in the design cycle

FPGA teams that leverage static verification as part of their functional verification processes are proven to reduce expensive and time-consuming simulation, synthesis and place and routeruns and reruns, freeing up expensive licenses as well as improving overall design productivity.

As an example of the return on investment of adding static verification to an FPGA design methodology, let’s take an example of five FPGA designers working on a 12-month FPGA project. If each person worked 200 days per year, the project would take approximately 1000 person days. Let’s assume each designer spends about 50% of their time focused on one project that is 500 person days.

The Wilson study showed that approximately 51% of the design time is spent in simulation (250 person days). By adding static verification to the design methodology, if 50% (63% derated for simplicity)  of the issues are trivial human errors or typos that can caught up front, this could save as much as 128 (250 x 51% x 50%) person days in simulation alone.

Next, if you add the impact of CDC issues, where ~37% of High Reliability designs have clock related issues, project teams could eliminate another possible 3 month delay due to additional simulation and/or lab debug to find a CDC issue, or 90 person days. Finally, if you add the project management efficiencies, the project team could save as much as 240 person days (1.2 person years).

To put this into real numbers, at a loaded cost of $150K/year/engineer, the net savings would be around $180K per year. This is not inclusive of other unratifiable savings, such as reduced simulation and synthesis license needs, project overrun costs/penalties, lab debug equipment and lab time as well as a significantly reduced risk of field failures. These savings far outweigh the costs of adding static verification as part of a complete functional verification methodology.

Whether you believe Moore’s law is coming to an end or not, one thing is clear: Most project teams are required to increase productivity just to keep up with FPGA complexity, often with smaller and smaller design teams. Blue Pearl’s Visual Verification Suite, used early and often in the design process as opposed to as an end of design/sign-off only tool, significantly contributes to design efficiency and quality, while minimizing chances of field failures.

To learn more about the Visual Verification suite, please request a demonstration.

Issue 11: Accelerating Verification for Satellite Applications

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.

Are FPGA Vendor Provided Tools All I Need?

Anyone who has designed with the latest breed of FPGAs, complete with scalar, RF, and DSP engines, your choice of hard and soft processors along with custom and standard interfaces, understands why most FPGA projects are behinds schedule.  In fact, according to a recent Wilson Research study, responders reported that 68% of FPGAs designs are delivered behind schedule.

When talking with design teams about this, the typical response boils down to, ‘we are too busy being productive to be more productive’. Meaning, we have a current flow, we use the FPGA vendor provided tools, and we don’t have the time nor the people to evaluate new tools and methodologies. This said, with today’s FPGA complexity and need for high-reliability designs and systems, this can be a costly mistake.

To convince FPGA development teams that change is needed, EDA companies have come up with cute marketing slogans such as “Shift Left” and “Verify as you Code”. The benefit proposed is if you can catch issues sooner, the faster and less costly they are to fix. While this would seem obvious, it typically takes management’s commitment to high-reliability and streamlined design practices to realize the true benefit of adding additional tools into the flow.

While FPGA vendor provided tools are necessary, by themselves, they are not sufficient when it comes to streamlining high-reliability FPGA design. So why adopt a 3rd party Lint tool like Visual Verification Suite’s Analyze RTL? To answer this question we asked Adam Taylor, Founder and Lead Consultant at Adiuvo Engineering & Training Ltd. for the top 10 reasons his team adopted the Visual Verification Suite for their work with the European Space Agency (ESA) aimed at improving the usability of the ESA soft-core IP. 

For background, the ESA soft-core IP (ESA IP portfolio) was developed to promote and consolidate the use of standardized functions, protocols and/or architectures such as SpaceWire, CAN, TMTC, and more. Adam and his team have been reviewing the cores to ensure they are clean of syntax, structural, and clock domain crossing issues.

Here is Adam’s response…

  1. Ease of use – No steep learning curve to using and becoming proficient with the tool.
  2. Focuses in on issues – Provides filtered reports, path-based schematics, and cross probing to quickly find issues and then assign waivers to fix or not.
  3. Design Enablement – Low ‘noise’ text reports provide significant information on the structure of the design to help optimise if necessary – they also help designers understand legacy designs and pre-existing IP blocks.
  4. Find issues earlier in the design cycle – Enter simulation and synthesis with a better quality of code. The later issues are found the more costly they are to fix.
  5. Design Scenarios – Ensure the configuration of generics does not introduce any corner cases when developing IP e.g. one generic resulting in an overflow which is not caught until much later.
  6. FSM viewer – Ensure no illegal /deadlocked/unmapped states are in the FSM – simulation requires you ask the right question to find it, or worse you find it after hours of simulation, which then must be done again.
  7. Design metrics – Tracking of warnings, errors, and ‘Must Fix / Won’t fix’ waivers over time allows assessment of the maturity of the code and the engineering effort to fix it. This results in more accurate program management estimations as to the state of the design.
  8. Design Sign off – You know required tests were actually run – good for “goods in inspection” of code as well as to understand the impact of code changes.
  9. Easy creation of custom packages for company design rules – Automates the design review process by enabling design reviews to be consistent and focus on assigning must/won’t fix waivers.
  10. Built in safety packages (DO-254), industry standard checks (STARC), FPGA specific libraries on your choice of Linux and Windows to streamline setup and deployment.

The Visual Verification Suite augments FPGA vendor tools by generating complete timing constraints for false and multicycle paths and reporting on functional design, FSM and clock domain crossing issues that can be fixed before simulation, synthesis and physical implementation, reducing the number of iterations in the flow considerably. To find out how your team can benefit by verifying as they code, request a demo from the Blue Pearl team.