- New 2014 Version of Ascent Lint HDL Analyzer and Rule Checker
- What is Driving Lint Usage in Complex SOCs?
- Ascent Lint Rule of the Month: OPEN_INPUT
- Ascent Lint HDL Rule of the Month: ZERO_REP
- When to Retool the Front-End Design Flow?
Early Verification Products
Ascent Lint is a state-of-the-art RTL linter and rule checker for full-chip SoC analysis. Designed from the bottom-up to deliver the highest performance, capacity and low-noise reporting, it is the best-in-class HDL linter available today with a comprehensive set of syntax and semantic checks.
Full-chip SoC capacity matches Ascent Lint’s runtime speed. There is no need to use hierarchical decomposition method when Ascent Lint can run your entire design flat. 500M+ gate SoCs take only minutes to be analyzed and reported.
Ascent Lint check reporting is the most efficient and generates the lowest noise in the industry. HDL designers no longer have to wade through erroneous, duplicate, and poorly organized analysis run reports. Ascent Lint rules have no overlap as found in older generation tools and eliminates duplicate reporting. Errors are prioritized so that fixes will produce the greatest improvement in the quality of the HDL.
Ascent Lint has a fast and powerful debugging capability that cross probes the RTL design source to pinpoint the exact source of design issues. This easy user interface guides rule selection, waiving, and customization as well as debugging the violations report. And Ascent Lint’s incremental analysis can show just the difference in analysis reports between different version of a design.
Ascent Lint supports the Verilog, VHDL, and System Verilog languages and gate-level netlists.
The built-in rules ensure that designs meet requirements for correct and efficient synthesis, simulation, test, reuse, and RTL/gate sign-off. Design reuse is enabled with rules for industry standards such as the Reuse Methodology Manual (RMM), STARC, and DO-254 for avionics.
Smart Rules for Verilog, VHDL, SystemVerilog, and Netlists detect:
- FSM state reachability and coding issues
- Legal but dubious modeling indicating probable errors
- Differences between simulation and synthesis semantics
- Naming and RTL coding conventions
- Subset restrictions to enforce modeling clarity and reduce complexity
- Opportunities to improve simulation performance
- Operations with hidden or expensive implementation costs
- Downstream tool flow issues
- Network and connectivity checks for clocks, resets, and tri-state-driven signals
- Module partitioning rules
- Design testability