John Cooley’s Deepchip.com web-site likes to publish end-user experience with various EDA tools. On May 6, he published a posting on why a designer switched from Atrenta SpyGlass to Real Intent for CDC, Lint, and X-propagation analysis. His report details the reasons for converting to our best-in-class tool suite.
Here is the first part of the posting:
We had been using SpyGlass from Atrenta, and it worked OK for us, but we
were told by our local Real Intent sales guy that “there would be fewer
iterations for Lint, easier setup for CDC, lower-noise reporting, and
faster runtimes” — if only we evaled his tools.
REAL INTENT MERIDIAN CDC VS. ATRENTA SPYGLASS CDC
I spent one work week (5 days) evaluating Meridian CDC. We used different
designs to evaluate this tool. The first was 850K gate design that had
3 asynchronous clock domains. For the analysis setup, Meridian CDC
automatically detected all the clock/reset candidates correctly at block-
level as well as the top-level. No additions were needed for the setup
file, while our Spyglass run did require manual editing of the setup.
The Meridian runtime for this block was ~5 minutes.
The second design was 4 million gates and had 5 asynchronous clock domains.
Again the automatic clock/reset detection worked as expected. The runtime
was ~15 minutes.
Read the rest of the report on CDC, lint and X-propagation here.
Have you switched EDA tools recently? How was that experience?
With acquisitions, customers get nervous and for good reason. The support and responsiveness they get changes. Five respondents said they were considering possibly replacing SpyGlass with Real Intent. One user reported the following conversation:
“Your SpyGlass customer support won’t change as a result of the SNPS acquisition.” They actually said that to me with a straight face.
The article also reported a customer evaluation of our Ascent Lint and Meridian CDC (clock-domain crossing) tools. Here is a quick snippet: (more…)
At the Design Automation Conference in San Francisco, Real Intent did a survey of 201 visitors to our booth. We focused on RTL and gate-level verification issues. Below is a brief introduction and you can see the entire survey on the DeepChip.com web-site.
These numbers are very similar to what was reported in 2012 on DeepChip. With half of the future design starts occurring in the next 3 months, this leads me to think design activity is remaining strong despite any EDA user consolidation we might have seen with the big mergers of various chip companies, and the slowing of the Chinese economy. However, the latest IC forecast from Gartner has 2015 growth falling from 5.4% at the beginning of 2015 down to 2.2% in July. (more…)
The great thing about a standard is that once you decide to use it, your life as a designer is suddenly easier. Using a standard reduces the long list of choices and decisions that need to be made to get a working product out the door. It also gives assurance to the customer that you are following best practices of the industry.
A standard for the world of aviation electronics (avionics) is the RTCA/DO-254, Design Assurance Guidance For Airborne Electronic Hardware. It is a process assurance flow for civilian aerospace design of complex electronic hardware typically implemented using ASICs or big FPGAs. In the USA, the Federal Aviation Administration (FAA) requires that the DO-254 process is followed. In Europe there is an equivalent standard called EUROCAE ED-80.
At first glance the standard seems daunting. It defines how design and verification flows must be strongly tied to both implementation and traceability. In DO-254 projects, HDL coding standards must be documented, and any project code must be reviewed to ensure it follows these standards. They address the following issues: (more…)
One trend we’re seeing in Asia is the number of FPGA design starts — now counting in the thousands. Getting a functionally correct design is the first goal for designers. It is easy to think that once that is achieved FPGAs can shipped out in finished products. But that’s not a robust model. For example, we have had customers with failures in the field due to a subtle timing change between FPGA part lots.Larger FPGA designs have grown in complexity, resulting in an amalgamation of disparate IP that can lead to clock domain challenges. A robust model for FPGA designs requires advanced signoff tools, a design flow that works easily with Xilinx and Altera tools, and support for high-reliability standards like DO-254. This is where Real Intent’s Meridian and Ascent products excel. For high-performance, our CDC and Lint tools provide the confidence design teams need, with unsurpassed verification and sign-off support.
Come visit us in Booth #1422 at DAC in San Francisco, June 8-10 to see our latest technical presentations. To choose your technical presentation clickhere.
Can’t attend DAC? Check out some of our latest video interviews with Real Intent technologists or email us for a personal presentation to you or your team.
The last two weeks before the Design Automation Conference in San Francisco are a busy time. For us marketeers, it has been called “our Superbowl.” We want to get the word out that we have something new and important to show visitors to at our exhibit booth. But there is more going on which I will mention after I talk about our booth activities.
Real Intent is number two on the GarySmithEDA What to See @ DAC list. I know why we are number two on the list. But I don’t want to give the secret away. If you know the reason, then please let everyone know in the comments section at the end of the blog.
Here are the quick titles for our technical presentation in our demo suites.
Ascent Lint with 3rd Generation iDebug Platform and DO-254
Meridian CDC for RTL with New 3rd Generation iDebug Platform
Ascent XV with Advanced Gate-level Pessimism Analysis
Accelerate Your RTL Sign-off
Hierarchical CDC Analysis and Reporting for Giga-gate Designs
On February 25 we announced the 2015 release of Ascent Lint for comprehensive RTL analysis and rule checking. The new version for 2015 delivers enhanced support for the SystemVerilog language, DO-254 policy files for compliance testing of complex electronic hardware in airborne systems, deeper rule coverage and easy configurability. We believe it is the industry’s fastest-performance, highest-capacity and most precise Lint solution in the market.
Additional enhancements and new features for Ascent Lint include:
Enhanced VHDL finite state machine (FSM) handling for deeper analysis
17 new VHDL and 12 new Verilog lint rules that ensure design code quality and consistency for a wide range of potential issues
Lower noise in reporting of design issues
To read further details about the announcement, click here. For additional insights and comments from Srinivas Vaidyanathan, staff technical engineer, including his take on the Cricket World Cup, please watch the video interview below.
This article was originally published on TechDesignForums and is reproduced here by permission.
It’s tempting to see lint in the simplest terms: ‘I run these tools to check that my RTL code is good. The tool checks my code against accumulated knowledge, best practices and other fundamental metrics. Then I move on to more detailed analysis.’
It’s an inherent advantage of automation that it allows us to see and define processes in such a straightforward way. It offers control over the complexity of the design flow. We divide and conquer. We know what we are doing.
Yet linting has evolved and continues to do so. It covers more than just code checking. We begun with verifying the ‘how’ of the RTL but we have moved on into the ‘what’ and ‘why’. We use linting today to identify and confirm the intent of the design.
A lint tool, like our own Ascent Lint, is today one of the components of early stage functional verification rather than a precursor to it, as was once the case.
Recently, Real Intent put out a new release of our Ascent Lint tool, which checks your RTL to make sure it meets the standards for good coding practices. Linting has the advantages of delivering very quick feedback on troublesome and even dangerous coding style that causes problems that can show up in simulation, but will likely take a much longer time to uncover. With the right lint tool, you can catch the “low-hanging fruit” before tackling functional errors. In a recent blog, we discussed how a staged analysis starting with Initial checks, followed by Mature and Handoff checks, can very efficiently get you to ‘hardened’ RTL code that is ready to be integrated with the rest of the design.