Arteris 推出可重复性硬件安全保障框架

搜索最新SoC解决方案
关于汽车电子...物联网...安全...音频...视频

www.design-reuse.com – May. 19, 2026 –

As the complexity of microelectronics accelerates across commercial and government systems, security assurance and trust is becoming a defining requirement rather than a secondary consideration. This complexity growth has also expanded the role of third-party intellectual property (3PIP) used in today's chip designs allowing for a faster, more scalable path to complex system design. To fully realize these benefits, system developers need a standardized, repeatable process that improves visibility into 3PIP design and behavior. This visibility is critical to hardware security, helping teams detect misconfigurations, unintended access paths, and other vulnerabilities that can emerge when third-party IP becomes part of the full system. Security does not automatically carry across combined components, making system-level security practices essential. As a result, design teams are shifting to an executable, robust, and end-to-end structure that ensures performance gains do not come at the expense of security.

The adoption and openness of the RISC-V instruction set architecture has driven innovation, flexibility, and rapid ecosystem growth. This has put a larger emphasis on adopting standardized tools and approaches to ensure the functionality and security of RISC-V designs are complete and correct especially in safety critical systems.

Defining a Systematic Approach

To support this shift, Cycuity, recently acquired by Arteris, has developed a four-step security assurance methodology, recognizing that a structured and repeatable framework is needed to evaluate and verify third-party IP at scale.

• Scope inclusion: Identify relevant Common Weakness Enumeration (CWE) categories from the MITRE-maintained database for IP under review.
• Security requirements: Translate identified weaknesses into concrete, design-specific security requirements.
• Verification development: Create security properties and corresponding tests to validate those requirements.
• Evidence collection: Gather artifacts to support, document, and validate the results.

Most of the engineering effort is concentrated in Steps 3 and 4, where security requirements are implemented as security properties and rules, tests are executed in the security analysis environment, and the resulting evidence is reviewed, collected, and archived. This process establishes hardware security as a structured verification workflow supported by repeatable artifacts.

Rather than treating verification as a single effort, the methodology is designed to scale across the third-party ecosystem. Reusable security properties in the form of security rule templates, reduce non-recurring engineering costs while maintaining flexibility for different implementations. Scope definitions can be reused, requirements standardized, and both properties and tests made portable, enabling consistency across designs while formalizing the process. For example, pairing a template rule with a portable C-based test that can run with any RISC-V processor with minimal modifications ensures that security intent is validated through both formal analysis and execution-based testing.

Producing Traceable Results

A central part of this approach is the use of formalized security rule templates that translate requirements into machine-checkable logic directly on the register transfer level (RTL) source code. These rules can be adapted to specific implementations through configurable parameters, allowing the same underlying structure to be applied across multiple designs.

Equally important is the focus on evidence, or the data generated during verification that supports security results. This evidence includes structured artifacts such as rule evaluations, test outputs, and coverage data, each providing traceable support for the reported security outcome. By grounding results in reviewable evidence, the process ensures that security findings are not only produced but can also be assessed and interpreted with confidence.

This method leverages multiple verification techniques depending on the type of security concerns being evaluated. Rule-based analysis and testing form the core, serving as the primary methods for verifying how a design behaves and enforces security requirements. Static analysis is used where appropriate to examine issues such as register initialization directly in the design. Traditional simulation-based verification can also be used for functional use cases.

The approach also helps bridge the gap between hardware design teams and system-level stakeholders. Organizing results into clear, standardized outputs enables integrators, auditors, and program managers to understand the security posture of an IP block without requiring deep access to the underlying design. That transparency is especially important when third-party IP is incorporated into a larger system.

Conclusion

With third-party IP gaining momentum, the need for hardware security practices is only increasing. The hardware security assurance products from Arteris play a critical role. Cycuity Radix enables the creation and execution of formalized security rules that map directly to design behavior. Cycuity Radix-ST extends this capability through static analysis, examining RTL directly to identify issues such as improper initialization or unintended behavior without requiring simulation. Together, these capabilities provide both dynamic and static visibility into design security.

Read the whitepaper here.

 Back