Introduction

Today’s FPGA designs are typically developed by assembling between 50 to 100 unique IP blocks to form a complete System on Chip (SoC) including embedded processors, high speed serial interfaces, analog, signal processing and control logic. These systems are large, complex and partitioned into multiple clock domains and reset structures required to interface and control the various subsystem and reduce overall system level power. FPGA designers, developing these advance SoCs, must not only develop functionally correct RTL, they must also meet conditions for downstream interoperability within the overall system.

To reduce design risk and schedule slips, RTL code must be free of design errors, adhere to industry and corporate best practices, be free of dead code and unreachable finite state machine (FSM) states, in addition to having synchronized clock domains crossings to ensure metastability. Failure to use high reliability RTL can result in difficult and time consuming system level debug as well as design iterations late in the design process when iteration times are at their longest.

High reliability RTL is best achieved through a structured development environment that incorporates design automation for static design verification. While FPGA vendor supplied synthesis and place and route tools do identify many design rule violations, more sophisticated checks are needed earlier in the design processes. Two separate analysis environments are required; RTL Analysis for for bus contention, register conflicts, race conditions and CDC (clock domain crossing) analysis to identify asynchronous clock domains and their crossings.

Without automation, finding and remedying design errors that affect interoperability turns into a random manual exercise. Automation enables an agile design process where developers continuously identify and address design errors while writing the RTL making it easier to develop, easier to test, and more reusable for future designs.

Analyze RTL incorporates a suite of technologies into a single RTL analysis environment to help developers find bugs earlier in the design processes. Super-lint tools are combined with the power of formal verification to provide a single, high capacity design checking environment that identifies poor coding styles, improper clocks, simulation and synthesis problems, poor testability and other source code issues. FSM analysis automatically extracts and analyzes finite state machines for dead or terminal states and provides a visual representation. X-propagation analysis will detect unknown states, often introduced into designs to implement soft resets or to implement power management schemes that are masked during RTL simulation.

Clock Domain Crossing Analysis with Grey Cell Technology

Blue Pearl delivers the industries most advanced clock domain crossing analysis that incorporates over a decade of experience to find errors other tools fail to identify. Analyzing RTL for a single block of a system in isolation is not sufficient to detect all CDC violations but rather the entire system must be considered and analyzed to perform a thorough CDC analysis. However, this can be a challenge when using 3rd party encrypted IP. Blue Pearl addresses this challenge using a patented technology called “Grey Cell” that enables a representation of a protected IP block for CDC analysis of module-to-module connections while preserving the trade secrets of the original IP provider.

Architected for Ease of Use Ensures Fastest Bug Find/Fix Rate.

Even the best static verification technology can be severely hampered by poor usability as potentially thousands of errors may be detected and flagged to the user for resolution. The Visual Verification Environment addresses the static verification usability problem in three key ways. First it includes a graphical user interface that incorporates state of the art EDA “ease-of-use” concepts that is proven to make new users productive in under 2 days. Tool options and settings are progressively displayed to the user with quick links to documentation. Second, a powerful set of message filters have been developed that lets users quickly identify only those messages that need attention. Design teams can focus on issues requiring direct attention and not be distracted by items of limited or no importance. And third, the environment provides a schematic view of the RTL with cross probing back to the warning or error message and RTL source code that lets users quickly understand and resolve each message that requires attention.

Summary

The Blue Pearl Visual Verification Suite enables developers to turn functionally correct RTL into high reliability RTL that supports interoperability into IP based system designs. Over a decade of experience is incorporated into industry leading technology that is uniquely optimized for the ease of use with the fastest bug find / fix rate and provides design rules checks required for FPGA design. For more information, please visit www.bluepearlsoftware.com to download an evaluation today.

]]>Tcl scripts and managing messages in ASIC & FPGA debughttp://www.bluepearlsoftware.com/tcl-scripts-and-managing-messages-in-asic-fpga-debug/
Thu, 28 Apr 2016 07:43:28 +0000http://www.bluepearlsoftware.com/?p=4194Our previous Blue Pearl post looked at the breadth of contextual visualization capability in the GUI to speed up debug. Two other important aspects of the ASIC & FPGA pre-synthesis workflow are automating analysis with scripts and managing the stream of messages produced. Let’s look at these aspects in the latest Blue Pearl 2016.1 release. […]

]]>Our previous Blue Pearl post looked at the breadth of contextual visualization capability in the GUI to speed up debug. Two other important aspects of the ASIC & FPGA pre-synthesis workflow are automating analysis with scripts and managing the stream of messages produced. Let’s look at these aspects in the latest Blue Pearl 2016.1 release.

An important aspect to regression testing is to run exactly the same tests as a design is iterated. The solution is scripting, automating the types and sequence of analysis with a saved file for execution. Tcl is a powerful scripting language popular in EDA circles, and rather than stay with their own syntax Blue Pearl has chosen to migrate their tools entirely onto Tcl. However, instead of providing only a command line interface usually associated with Tcl, they’ve taken the idea farther.

Both the GUI and the CLI are Tcl-based in the new release of the Blue Pearl suite. Set up can be done in the GUI and it can launch tests in the Core Analysis engine. For more complete test runs typically performed overnight, a Tcl script can be created and kicked off in the command line. Upon returning the next day, the CLI run can be loaded back into the GUI to allow the full visualization capability we discussed in our previous installment. This level of integration allows customized scripts for control, comparison of results from current and past runs, and rapid debug.

Those results are fundamentally a list of messages. With a well-designed message syntax, regular expressions can be used to process the list. In a sizable design with a long list of analysis messages, users will typically want to filter the list by different criteria. The Blue Pearl GUI allows some quick filtering capability via check boxes. More powerful message waiver capability now exists, including wild carding and string matching, which can be applied to a result set or removed – the results themselves are unmodified, only the managed view with waivers applied. This is handy where there are stylistic differences in code reviews; what one team considers a warning may be a mandatory fix for another.

Messages can also be customized and grouped. Since the messages are stored in a SQL database – as are many other EDA tool messages – scripts can read text from other sources such as synthesis tools and add those messages into the Blue Pearl database. (Note in the image below the Xilinx Vivado messages have been incorporated.) The GUI can then sort, filter, waive, and compare messages accordingly. When developing with unique internal coding standards, this user-extendable capability is essential to ensuring consistency and efficiency.

Our focus in these Blue Pearl posts has been on usability of the tools rather than specifics of results in RTL and CDC analysis. The pre-synthesis checks Blue Pearl performs are extensive. Designers adopting these kinds of tools are generally not looking for something that generates a huge list of issues to sort through – they are looking for actionable items. The real need is tool that brings attention to the most urgent issues, and allows less interesting results to be kept in the background.

The idea behind “continuous integration” of chip designs is to provide a gate, a quality check difficult to implement with manual methods. The twist is that gate is not cleared once, but has to be cleared every time the design goes back for synthesis with any change. A process leveraging the Blue Pearl suite delivers more predictability in designs with automated checking and efficient debug.

Great news for ASIC & FPGA designers in their daily tasks, but what about that dreaded project review when engineers have to show management what is happening with the schedule? Next, we’ll explore what Blue Pearl is doing in the area of metrics, leading up to their big announcement at DAC in Austin.

]]>We introduced the philosophy behind the Blue Pearl Software suite of tools for front-end analysis of ASIC & FPGA designs in a recent post. As we said in that discussion, effective automation helps find and remedy issues as each re-synthesis potentially turns up new defects. Why do Blue Pearl users say their tool suite is easier to use than other linting and CDC tools?

An effective ASIC & FPGA design flow integrates analysis tools with the main EDA environment, minimizes jumping back and forth between tools, but allows flexibility in how results are obtained. In what Blue Pearl terms “continuous integration”, code review is automated to a manageable rule set so coding standards are enforceable across teams and projects. While automated testing is fast and thorough, the key to productivity is how debug information is managed and resolved. Analysis tools that present accurate results quickly and clearly soon become part of a designer’s trusted environment.

All debug results produced by the Blue Pearl testing suite – including Analyze RTL, Clock Domain Crossing (CDC) analysis, and a Synopsys Design Constraints (SDC) management tool – are presented in a GUI with cross-linked viewers. Tcl scripts are also supported via a command line interface (CLI), and analysis jobs run from the CLI can have their results viewed in either the GUI or the CLI.

The power of the Blue Pearl GUI is its cross-viewing capability. Most linting tools spit out endless lists of text messages, usually linked to a view of source code. CDC tools typically provide text messages with a link into a schematic window illustrating the problem. Messages are often cryptic, and without context sometimes determining the exact severity of a problem is difficult.

One of the Blue Pearl customer presentation slides starts out with this: “Getting an error message is only part of fixing problems.” Unique to the Blue Pearl suite is how everything is tied together and manageable, allowing the user to visualize any issues and see in what context they occur. The obligatory text message window is at the center, but reimagined with meaningful messages linked to a line of code and cross-linked to several other viewer windows.

Messages from the main window can be narrowed down by grouping or user-defined filtering in the message viewer window. This is critical to any linting system; some errors are really warnings, others are severe and require design changes. Users can find what errors demand action quickly, rather than sifting through a long list with eyeballs and hoping to catch everything.

More powerful contextual capability is represented in several other windows.

Finite state machines (FSMs) have their own viewing window, clearly showing terminal or unreachable states.

Clocks and domains have their own window, under the presumption that some issues are related to how clocks and domains are set up.

CDCs also have their own window to view the synchronizer constructs in detail.

Pruned schematics and highlighted paths have windows so errors can be visualized in their context, and tracing can follow a signal forward or backward in the code to help identify the source of the problem.

Cross-viewing capability in the Blue Pearl suite allows errors to be understood and solved quickly. RTL issues can be uncovered pre-synthesis, and CDC problems difficult to detect at all in simulation can be identified and handled. Compare this approach to post-synthesis debug that has to go all the way around the loop and may still not completely resolve the actual source of the error, requiring another debug and synthesis pass.

We’ll discuss the Tcl script interface and message filtering and waiver system more in our next post describing the Blue Pearl 2016.1 release features.

]]>FPGA tools for more predictive needs in criticalhttp://www.bluepearlsoftware.com/fpga-tools-for-more-predictive-needs-in-critical/
Tue, 01 Mar 2016 07:35:25 +0000http://www.bluepearlsoftware.com/?p=4188“Find bugs earlier.” Every software developer has heard that mantra. In many ways, SoC and FPGA design has become very similar to software development – but in a few crucial ways, it is very different. Those differences raise a new question we should be asking about uncovering defects: earlier than when? Structured development methodology was […]

]]>“Find bugs earlier.” Every software developer has heard that mantra. In many ways, SoC and FPGA design has become very similar to software development – but in a few crucial ways, it is very different. Those differences raise a new question we should be asking about uncovering defects: earlier than when?

Structured development methodology was a breakthrough in computing, leading to the idea of structured programming and modular approaches to code. Systems engineers banished “goto” statements and embraced data flow diagrams, defining system inputs and outputs that can in turn be exploded into more detailed low-level functions with their inputs and outputs defined. Functions are decoupled such that a change in one does not affect others, and abstracted so that its design details are kept from the rest of the system. They are coded and tested stand-alone, then connected into subsystems, then the system, and everything usually works as expected.

The results of structured programming are rather spectacular. Code is easier to develop, easier to test, more reusable, and more manageable. Initial development time shrank, but a bigger impact is on the lifecycle – enhancements and maintenance tasks went from huge problems to achievable objectives. Capturing and understanding programming metrics brings predictability to the software development lifecycle (SDLC). Once requirements are determined, teams can accurately size a project, load resources, and estimate a schedule.

Those all sound like great things, especially for teams working on anything labeled “-critical”. Whether the job is mission, life, or safety, the approach is similar. Teams in mil/aero, medical, and industrial segments usually seek structured processes and procedures to reduce schedule and risk through planning, visibility, and predictability. Requirements are usually carefully bounded and traceable, and once frozen even minute changes come under intense scrutiny.

In contrast, more modern agile methods can produce stunning results where requirements are more dynamic. Defects are more of a continuous stream, popping up quickly and receiving immediate attention. Agile teams tend to value working software over documentation, and often have difficulty accurately projecting completion dates. Adaptive methods are often just too much entropy for risk-adverse teams and customers in the critical realm.

Tension between adaptive and predictive methods shows up prominently in FPGA design. FPGAs are the ultimate in adaptive hardware, taking shape around a user-defined design. The process at first appears structured, with high-level hardware description languages and reusable blocks of IP and automated synthesis tools. Entropy creeps in as a virtual representation of a design – even one heavily simulated – is translated into physical constructs in the FPGA. What were known good functional blocks can suddenly break down at integration and hardware debug, victims of a variety of rule violations and anomalous behavior.

Without effective automation, finding and remedying those behavioral issues turns into a random manual exercise. The problems worsen incrementally, as new changes and re-synthesis can result in new unforeseen defects. The question of “earlier than when” becomes causal, with the schedule clock and expectations for a predictable result restarting as changes are planned and integrated. The job is finding critical bugs right now, prior to beginning each synthesis run, quickly verifying the entire FPGA design through accurate testing and regression analysis.

What kind of things crop up in an FPGA? Most vendor-supplied synthesis tools weed out the simple design rule violations, but more sophisticated checks are needed for bus contention, register conflicts, and race conditions. Another issue is related to clock domains and what happens when logic crosses them, resulting in potential metastability issues. High-performance tools can check and insert synchronizer constructs and re-timing logic, an area where FPGA design teams often become mired without automation assistance. Re-timing and synchronization are excellent examples of things that can change at each iteration, and unchecked can lead to problems.

Automating critical manual processes in FPGA verification is the entire mission for Blue Pearl Software. Using a TcL shell, a graphical front end for all Blue Pearl tools manages results from advanced analysis engines and presents information visually. Analyze RTL provides static design and rule checking, a CDC tool analyzes clock domain crossings (CDCs) using patent-pending User Grey Cell modeling and other techniques, and an SDC tool handles Synopsys Design Constraints – all before time-consuming synthesis, improving result quality and shortening the overall design cycle with fewer iterations. Integration with industry-standard tools and flows on either Windows or Linux means the FPGA design process is enhanced, not completely altered.

Perhaps just as important as finding more actual errors quickly is sorting and filtering them by severity, up to and including not reporting items that do not present an actual problem – often the case in CDC analysis. By managing reporting within the Blue Pearl suite, design teams are led to issues requiring direct attention, and not bothered by items of limited or no importance. Results are presented in an executive-friendly dashboard and a design cycle manager, improving visibility and aiding teams used to higher levels of predictability.

Some applications are overtly declared -critical, but as I’ve been sharing lately, applications such as the connected car, the IoT, and wearables are also taking on increasing expectations. Accelerating verification is really about finding bugs right now, before declaring an FPGA design ready for synthesis – at every iteration of the design. Predictability is worth an extra step. In future posts, we will drill down into the capability of the Blue Pearl Software suite of tools and how they support industry-standard FPGA design flows including integration services.

]]>Where Does RTL lint tool fit in my design flow?http://www.bluepearlsoftware.com/where-does-rtl-lint-tool-fit-in-my-design-flow/
Tue, 20 Oct 2015 05:17:06 +0000http://www.bluepearlsoftware.com/?p=4118Working with ASIC and particularly FPGA designers, I’m frequently asked if finding bugs using existing simulation or emulation tools is sufficient. The short answer is “Yes”,but it’s not always the most efficient. As design sizes increase but schedules do not expand to match, designers find themselves frustrated by spending too much time looking at simulation […]

]]>Working with ASIC and particularly FPGA designers, I’m frequently asked if finding bugs using existing simulation or emulation tools is sufficient. The short answer is “Yes”,but it’s not always the most efficient. As design sizes increase but schedules do not expand to match, designers find themselves frustrated by spending too much time looking at simulation results or on bench testing to find bugs. Recently a mil aerospace customer lamented that, aside from enduring the process of re-planning and resetting schedules, and the risk of having a project cancelled for being 2+ weeks late, it’s very embarrassing to explain to management that the mistake turned out to be just some unconnected nets that could easily have been found by a lint tool in mere minutes.

We analyze the Verilog or VHDL and looks for situations that can cause design failures, such as a net that is undriven. This could cause an unknown state that would have to be debugged through a simulation wave forms viewer. A CDC crossing without a synchronizer will cause design failures that simulators might never catch at all.

Naturally, the next question I’m frequently asked is how and where Blue Pearl fits in one’s design flow:

Before Simulation –Blue Pearl can be used after initially writing the code. By using Blue Pearl to find design errors in the code, the designer can quickly check the language compliance and look for errors that can cause simulation failures. These errors can be found before developing a testbench.

Before Synthesis – Blue Pearl looks for code that could be un-synthesizable or could cause post-synthesis simulation results that are different from pre-synthesis simulation.

When generating constraints – After clock domain crossing synchronization has been added,Blue Pearl shows a visualization of the clocks and clock domains to help the user generate correct clock and clock domain constraints.

After CDC Synchronization Insertion –Blue Pearl looks for Clock Domain Crossing Synchronizers and determines where they are missing.

After Synthesis–Once it has been implemented,Blue Pearl can be used to visualize the RTL that caused a violated timing path. This can be done using a timing report that identifies the violated timing paths.

Blue Pearl can be used to easily and quickly find bugs that can hold up the design process. This is done early in the flow, when code is just being written, and after it has been implemented and when ECOs changes have to be made.

]]>Nice to be back, especially at DAC 52http://www.bluepearlsoftware.com/nice-to-be-back-especially-at-dac-52/
Mon, 24 Aug 2015 04:40:22 +0000http://www.bluepearlsoftware.com/?p=3920Did you stop by booth # 832 and check out Blue Pearl Software’s awesome new and improved RTL debugging environment version 9.1? If not, hopefully you took a spin down Central Park on our big screen, won an Apple watch, or at least picked up our tchotchke for your little ones at home. As for […]

]]>Did you stop by booth # 832 and check out Blue Pearl Software’s awesome new and improved RTL debugging environment version 9.1? If not, hopefully you took a spin down Central Park on our big screen, won an Apple watch, or at least picked up our tchotchke for your little ones at home.

As for me, attending Design Automation Conference 2015 (52nd DAC) was a nostalgic but exciting trip down the memory lane. Can you name the company that boasted the largest, over 10,000 installed base of EDA users in 1988? It was Personal CAD Systems (P-CAD), where my EDA career began, and where I first worked with Blue Pearl Software’s fearless CEO, Ellis Smith. Yeah, I was 12 at the time (ha, ha), and I answered a newspaper ad for a sales support manager position (for real).

When P-CAD was acquired by CADAM, an IBM subsidiary in 1990, my job shifted from sales supportto marketing following the rebranding of CADAM that became ALTIUM, an IBM Co. in the spring of 1993. Somewhere around 1995 I think, IBM signed an exclusive agreement to have ALTIUM market and distribute its high end EDA tools that were previously proprietary and highly coveted by the commercial EDA community. I was the ALTIUM marketing manager who was lucky enough to launch the announcement at DAC in Dallas. It made DAC’ headline news, and boy, was the party fun at the Dallas World Aquarium!

When I reconnected with Ellis and Blue Pearl in May, I couldn’t wait to see the growth and changes that have taken place since I left EDA in the mid-90s. Overall, DAC seems to have gotten smaller, although still lively, because the industry has consolidated so much. Many exhibitors including Blue Pearl continued to host our own private demo booths, which is not typical of most shows nowadays. I was just at the RSA Conference, a security show in April, for example. There, you only saw cool tools, lots of tchotchkes, and enough free food to justify skipping dinner and going straight to the bars.

Enough looking back, I’m amazed to see so many EDA colleagues who are still in the industry, including the late, long time industry analyst Gary Smith whose loss will be missed. No more mandatory attendance at DAC’s kick off reception where Gary shares his annual EDA predictions.No more listening to Gary playing his bass to some good old blues.

I’m grateful to have met lots of new faces that stopped by our booth. Big thank you to the VIPs who booked private demos. Hopefully, the time you got to spend with our VP of R&D Scott Bloom provided insights and food for thought.Big congrats to our three Apple Watch winners: Johnny Kwei of Broadcom, Richard Cheung of Oracle, and Duncan Halstead of Western Digital!.

Thanks for reading my first blog post since coming back to EDA. I’m looking forward to contributing to Blue Pearl Software’s growth by sharing relevant info that will help you accelerate your RTL design and debug. So, how about showing a little love and connect with us on LinkedIn, Facebook and Twitter?

]]>Brian Daellenbach, President of Northwest Logichttp://www.bluepearlsoftware.com/brian-daellenbach-president-of-northwest-logic/
Thu, 28 Jun 2012 21:45:40 +0000http://www.bluepearlsoftware.com/?p=2583“Using Analyze, we have identified and resolved coding issues that help us maximize the quality of our IP Cores”