Posts Tagged ‘SystemVerilog’
Thursday, June 30th, 2016
Most functional verification is done before the RTL is handed off for digital synthesis. Gate-level simulations take longer and are hard to debug, but still needed to verify some circuit behavior. Ideally, the output of the RTL simulation will match the output of gate-level netlist simulation after synthesis. But that is not typically the case. Besides the obvious things verified in your gate-level simulations, there are always unknown values (Xs). Some will not be seen in the RTL due to X-optimism, but there will be additional Xs in the gate-level simulations due to X-pessimism.
X-optimism in RTL and other generic issues around unknown states are discussed in more detail in the paper ‘X-Propagation Woes – A Condensed Primer‘. Some basic familiarity with the concept is assumed here.
This paper focuses on X-pessimism at the netlist level. It discusses some current techniques and their limitations, and then describes a more efficient X-pessimism strategy based on Real Intent’s Ascent XV. (more…)
Thursday, November 12th, 2015
A few weeks ago I attended the “10 Years of IEEE 1800™ SystemVerilog Celebration” lunch at an IEEE Standard Association symposium. One of the Verilog/SystemVerilog world’s luminaries sat next to me, and he started talking to other luminaries about how his son, as part of a general engineering degree, was using SystemVerilog.
I had to ask: “With more of a software background, what’s his reaction to SystemVerilog? It must seem like a godawful mess.”
He said, “He used those same words.”
Several months ago, I wondered whether SystemVerilog was the most complex computer language yet invented, and I found this page on StackOverflow. The number of keywords may not be the best metric of language complexity, but it is simple and easy to calculate. According to this answer, COBOL (the Common Business-Oriented Language invented in 1959) has 357. SystemVerilog has 323. C#, Microsoft’s answer to C++ and JAVA, is a distant third with 102. If this answer is complete, nothing competes with COBOL and SystemVerilog. (more…)
Thursday, March 12th, 2015
Last week I attended the Design and Verification Conference in San Jose. It had been six years since my last visit to the conference. Before then, I had attended five years in a row, so it was interesting to see what had changed in the industry. I focused on test bench topics, so this blog records my impressions in that area.
First, my favorite paper was “Lies, Damned Lies, and Coverage” by Mark Litterick of Verilab, which won an Honorable Mention in the Best Paper category. Mark explained common shortcomings of coverage models implemented as SystemVerilog covergroups. For example, because a covergroup has its own sampling event, that may or may not be appropriate for the design. If you sample when a value change does not matter for the design, the covergroup has counted a value as covered when in fact it really isn’t. In the slides, Mark’s descriptions of common errors were pithy and, like any good observation, obvious only in retrospect. More interestingly, he proposed correlating coverage events via the UCIS (Unified Coverage Interoperability Standard) to verify that they have the expected relationships. For example, a particular covergroup bin count might be expected to be the same as the pass count of some cover property (in SystemVerilog Assertions) somewhere else, or perhaps as much as some block count in code coverage. It struck me that some aspects of this must be verifiable using formal analysis. You can read the entire paper here and see the presentation slides here.
I was also impressed by the use of the C language in verification — not SystemC, but old-fashioned C itself. Harry Foster of Mentor Graphics shared some results of his Verification Survey, and there were only two languages whose use had increased from year-to-year: SystemVerilog and C. For example, there was a Cypress paper by David Crutchfield et al where configuration files were processed in C. Why is this, I wondered? Perhaps because SystemVerilog makes it easy via the Direct Programming Interface (DPI): you can call SystemVerilog functions from C and vice-versa. Also, a lot of people know C. I imagine if there were a Python DPI or Perl DPI, people would use those a lot as well! (more…)
Thursday, February 26th, 2015
New Ascent Lint with DO-254 Compliance Testing
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.
Thursday, December 4th, 2014
The IEEE announced in September that is was launching working a on a new power standard called P2415. This blog gives the background for this new effort.
The current low power design and verification standard (IEEE 1801-2013 and IEEE P1801) is focused on the voltage distribution structure in design at Register Transfer Level (RTL) description and below. It has minimal abstraction for time (having only an interval function for modeling clock frequency), but depends on other hardware oriented standards to abstract events, scenarios, clock trees, etc. which are required for energy proportional design, verification, modeling and management of electronic systems. The necessary abstractions of hardware, as well as layers and interfaces in software are not yet defined by any existing standards. (more…)