ads mdx semiwiki building trust gen 800x100ai
Semiconductor Expert Forum

Posted on

S2C Advances RISC-V Ecosystem, Accelerating Innovation at 2025 Summit China

S2C Advances RISC-V Ecosystem, Accelerating Innovation at 2025 Summit China
by Daniel Nenni on 08-13-2025 at 10:00 am
Categories: EDA, Prototyping, RISC-V, S2C EDA

pic 1 (1)

Shanghai, July 19, 2025 — S2C, a leader in functional verification, showcased its latest digital EDA solutions and key partnerships with BOSC, Xuantie, and Andes Technology at RISC-V Summit China 2025, highlighting its contributions to the ecosystem. The company also played a leading role in the EDA sub-forum, with VP Ying J Chen co-chairing and Senior Engineer Dehao Yang delivering insights on accelerating RISC-V adoption through practical strategies.

Showcasing Diverse RISC-V Applications with Ecosystem Partners

Leveraging its comprehensive digital EDA portfolio, S2C delivers matching verification solutions across the RISC-V ecosystem—addressing verification needs ranging from IP validation to system-level verification. Through close partnerships with leading RISC-V vendors, S2C provides high-performance, scalable prototyping solutions that accelerate time-to-market from early design bring-up to full-system deployment.

At the summit, S2C showcased its FPGA prototyping solutions with live demos across multiple RISC-V applications – including the Xiangshan processor running a graphical Linux interface. S2C has collaborated with Beijing Open Source Chip Research Institute (BOSC) since the first-generation Xiangshan CPU. In the recent validation of its third-generation Kunminghu processor – a 16-core RISC-V design with NoC interconnect running on two S8-100Q Logic Systems (each with 4 VP1902 FPGAs) were deployed and achieved a static timing closure at 12MHz. BOSC recognized S2C as a “Strategic Contributor” for its critical role in accelerating Xiangshan’s development cycle.

Additionally, Xuantie R908—a high-efficiency processor designed for real-time performance—was demonstrated live running on S2C S7-19P Logic System. The demo effectively demonstrated its low-latency operation and field-ready reliability.

Equally notable was Andes Technology’s 64-bit RISC-V vector processor IP core, the AX45MPV – running Linux and large language models easily efficiently on S2C’s S8-100 Logic System through the Andes Custom Extension (ACE) framework.

Overcoming Simulation Bottlenecks with Transaction-Based Acceleration

The RISC-V Verification Interface (RVVI) provides a standardized framework to ensure ISA compliance and functional correctness. Yet, as RISC-V designs grow in complexity—especially with custom extensions—traditional simulation methods encounter challenges like slow execution speeds, limited debug visibility, and difficulties scaling to full system-level verification.

To address these challenges, the keynote by Yang Dehao focused on Transaction-Based Acceleration (TBA), a verification methodology that enhances RVVI by decomposing test scenarios into reusable transaction flows. TBA leverages co-simulation between virtual prototyping platforms and hardware emulators—using tools such as S2C’s Genesis Architect and OmniArk/OmniDrive—to significantly improve verification speed and observability at scale, while maintaining RVVI compliance.

This approach exemplifies how advanced verification methodologies, combined with powerful prototyping tools, can accelerate the path from RTL validation to full-chip system verification.

Building on this, VP of marketing Ying J Chen highlighted S2C’s continued commitment to ecosystem collaboration and innovation:

“It is exciting to see thousands of engineers at the summit, and the manifestation of our partners’ RISC-V cores drawing a large crowd to our booth,” stated Ying J Chen, VP of Marketing at S2C. “We don’t just see ourselves as tool providers—we’re also an advocate for innovation and customers’ success. We’re committed to deepening our effort in the RISC-V community and broaden the ecosystem.”

S2C Inc. is a global provider of FPGA prototyping solutions for SoC (System on Chip) and ASIC (Application-Specific Integrated Circuit) designs. They offer hardware, software, and system-level design verification tools to accelerate the development process. S2C’s solutions are used for design exploration, IP development, hardware verification, system validation, software development, and compatibility testing. 

Also Read:

Double SoC prototyping performance with S2C’s VP1902-based S8-100

Enabling RISC-V & AI Innovations with Andes AX45MPV Running Live on S2C Prodigy S8-100 Prototyping System

Cost-Effective and Scalable: A Smarter Choice for RISC-V Development

Posted on

Breaking the Sorting Barrier for Directed Single-Source Shortest Paths

Breaking the Sorting Barrier for Directed Single-Source Shortest Paths
by Admin on 08-13-2025 at 8:00 am
Categories: EDA

Dijkstra's Algorithm

Problem & significance.
Single-source shortest paths (SSSP) on directed graphs with non-negative real weights is a pillar of graph algorithms. For decades, the textbook gold standard has been Dijkstra’s algorithm with good heaps, running in the comparison-addition model (only comparisons and additions on weights). Because Dijkstra effectively maintains a total order of tentative distances, many believed its  “sorting cost” was an inherent barrier on sparse graphs. The new paper “Breaking the Sorting Barrier for Directed Single-Source Shortest Paths” overturns that belief with a deterministic algorithm for directed graphs—strictly on sparse inputs and the first to beat Dijkstra’s bound in this model.

Model & setup.
The result holds in the comparison-addition model with real, non-negative edge weights. The authors adopt standard simplifications that preserve shortest paths: (i) make the graph constant-degree via a classical vertex-expansion gadget ensure uniqueness of path lengths by a lexicographic tie-breaking scheme that can be implemented with some overhead. These choices streamline the analysis without changing correctness.

Core idea in one line.
Blend the ordering discipline of Dijkstra with the bulk-relaxation power of Bellman–Ford, but never fully sort the frontier. Instead, shrink the frontier so only a fraction of “pivots” need attention at each scale, thereby skirting the sorting bottleneck.

From barrier to breakthrough: two levers.

  1. Frontier reduction via “pivots.”
    At any moment, Dijkstra’s priority queue reflects a frontier SS of vertices whose outgoing edges can unlock progress. If one naively kept selecting the minimum, sorting resurfaces. The paper instead introduces a FindPivots subroutine that runs kk rounds of bounded relaxations (Bellman–Ford style) and classifies vertices according to whether their shortest path crosses at most kk frontier-interval vertices. Those that finish become complete. The others are “covered” by root vertices whose shortest-path subtrees are large. Only these roots—the pivots—must persist.

  2. Recursive bounded multi-source SSSP (BMSSP).
    Rather than run one monolithic Dijkstra, the algorithm performs a divide-and-conquer over distance scales.

A partial-sorting data structure.
To orchestrate sources across recursive calls without full sorting, the authors design a block-based structure supporting: Insert, BatchPrepend (efficiently add a batch of strictly smaller keys), and Pull (extract up to MM smallest keys plus a separating threshold). This lets the algorithm “sip” from the smallest distance ranges as needed, while updates from relaxations are appended efficiently, avoiding global reordering.

Context & novelty.
Earlier, it was shown that Dijkstra is optimal if one insists on outputting the full ordering of vertices by distance. This paper sidesteps that constraint: it outputs distances without maintaining a total order, breaking the “sorting barrier.” It also delivers the first deterministic improvement even relative to prior randomized gains on undirected graphs, strengthening the case that the barrier is not fundamental.

Takeaways:

Theory: A clean, deterministic path past nlog⁡nn\log n for directed SSSP in a realistic algebraic model.

  • Technique: A reusable template—bounded multi-source recursion, pivot selection, and partial sorting—that may inform faster routines for other path problems under comparison constraints.

  • Outlook: Extending these ideas to richer weight domains or dynamic settings could unlock further speedups where sorting once seemed inevitable.

The full paper:  Breaking the Sorting Barrier for Directed Single-Source Shortest Paths 

Posted on

Samtec Practical Cable Management for High-Data-Rate Systems

Samtec Practical Cable Management for High-Data-Rate Systems
by Admin on 08-13-2025 at 6:00 am
Categories: Samtec, Semiconductor Services

Samtec cable management SemiWiki

According to a recent Samtec whitepaper, in high-data-rate (HDR) architectures, where signals traverse tens to hundreds of gigabits per second, “cable management” isn’t a housekeeping chore, it’s a first-order design variable. The mechanical path a cable takes directly influences channel loss, crosstalk, reliability, rework costs, and even thermal performance. The most successful programs treat cable routing, bend strategy, strain relief, and labeling as part of early architecture, co-optimizing them alongside signal integrity (SI), thermals, and assembly. That mindset unlocks cleaner channels, faster bring-up, and fewer surprises in environmental or HALT testing.

Figure 1. Samtec High-Data-Rate Cable Assemblies can be used in mid-board, front panel, and backplane flyover applications.

Bend control is foundational. Every cable has a static minimum bend radius below which impedance discontinuities, jacket damage, or conductor fatigue become likely. Minimums vary with construction and gauge; designers should consult product-specific data rather than assume generic rules. As one illustrative datum, 34-AWG twinax/coax commonly specifies a 3.1 mm (0.125″) minimum bend radius—tight by eye, but still large enough to demand discipline in dense layouts. Two practical rules follow: avoid bunching (it effectively increases the required minimum), and allow cables to splay as they leave the connector so the first bend is gentle and not levering the termination. When routing along the connector’s length, the best practice is “bend, then twist”: first introduce the desired bend, then apply a controlled 90° twist over ~1.5″ to re-orient the exit without over-stressing the bundle.

Sleeving is valuable when used judiciously. Its role is protective—guarding jackets from nicks, abrasion, and errant edges—while offering light organizational benefits in cable-rich builds. Oversized, stretchable sleeves are preferred because they let strands splay naturally at bends and turns; tight sleeves (or large labels placed on them) add stiffness right where compliance is needed. Keep sleeves away from tight-radius regions, and use edge tape only where necessary. Strain is the other half of the story: always design for slack. Select lengths to accommodate both the final mated condition and the act of insertion/removal, short cables (<10 in / 25 cm) are especially sensitive. Where slack cannot be guaranteed, consult qualification data on allowable normal and side loads and, if needed, transfer load paths from the connector into the chassis or PCB via brackets or tie-downs. If compressive forces are unavoidable, preserve degrees of freedom so cables can splay and dissipate stress rather than prying at the interface.

Labeling and identification deserve more attention than they usually get. In production, field service, and RMA workflows, smart labels pay for themselves, yet they can become unintended stiffeners if applied indiscriminately. Keep labels minimal, place them on individual strands rather than wrapped around a bundle, and keep them clear of bend zones. Color coding can accelerate assembly while reducing handling time (and the handling damage that comes with it). Surround these mechanical practices with a robust set of enablement tools: full-channel SI models and evaluation kits for pre-layout what-ifs; thermal analysis to compute pressure drops and airflow interaction in cabled systems; and physical mock-ups to validate touch-labor ergonomics before freezing the design. Mature vendors also offer application-engineering support, custom sleeves and labels, and solution finders that map needs to qualified assemblies, particularly relevant for mid-board, front-panel, backplane, and Flyover® use cases.

In sum, HDR cable management is about treating the cable path as part of the channel, not an afterthought to be “neatened up” at the end. Respect bend radius by design; route to avoid bunching and leverage bend-then-twist to re-orient without stress; use sleeves for protection, not constriction; preserve slack and manage loads into structures that can bear them; label intelligently without adding stiffness; and anchor the whole effort with SI, thermal, and assembly analyses up front. Do these things, and you’ll ship systems that are faster to validate, more robust in the field, and easier to service—outcomes that matter just as much as the headline data rate.

Read the full Samtec white paper here

Also Read:

How Channel Operating Margin (COM) Came to be and Why It Endures

Visualizing System Design with Samtec’s Picture Search

Webinar – Achieving Seamless 1.6 Tbps Interoperability with Samtec and Synopsys

 

Posted on

A Quick Tour Through Prompt Engineering as it Might Apply to Debug

A Quick Tour Through Prompt Engineering as it Might Apply to Debug
by Bernard Murphy on 08-13-2025 at 6:00 am
Categories: AI
3 Comments

Prompt ENgineering example

The immediate appeal of large language models (LLMs) is that you can ask any question using natural language in the same way you would ask an expert, and it will provide an answer. Unfortunately, that answer may be useful only in simple cases. When posing a question we often implicitly assume significant context and skate over ambiguities. Then we are surprised when the LLM completely misses our expectation in the answer it provides.

The reason for the miss is that initial guidance was insufficient. Rather than trying to stuff all the necessary context into a new prompt, standard practice is to refine initial guidance through added prompts, as in the following (fake) example. No longer a simple prompt, this looks more like an algorithm, though still expressed in natural language. Welcome to prompt engineering, a new discipline requiring user training and familiarity with a range of prompt engineering techniques in order to craft effective queries for LLM applications.

Techniques in prompt engineering

This domain is still quite new, as seen in the great majority of papers reported in Google Scholar which appear from 2023 onwards. Outside of Google Scholar I have found multiple papers on use of LLMs in support of software debug and to a lesser extent hardware debug, but I have found very little on prompt engineering in these domains. There are also Freemium apps to help optimize prompts (I’ll touch on these later) though I’m not sure how much these could help in engineering debug given their more likely business-centric client base.

Lacking direct sources, I will synthesize my view from a variety of sources (list at the end), extrapolating to how I think these methods might apply in hardware debug. It would love to see responses to disprove or confirm these assumptions.

In debug, context is important even though in conventional algorithmic debug it is unclear how this might play a role. LLM-based debug could in principle help bridge between high-level context and low-level detail, for example, requiring that the LLM answer with an expert engineering viewpoint. Yes, that should be a default but isn’t when you are starting with a general-purpose model, trained on a wide spectrum of expertise in many domains. Less obvious is value in including information about the design function. This might narrow context somewhat within general training, maybe more so through in-house fine-tuning/legacy in-context training. Either way providing this information might help more than you expect, even though your prompt suggestion may appear very high level.

Chain of Thought (CoT) prompting, telling the LLM to reason through a question in steps, has proved to be one of more popular prompting techniques. We ourselves don’t reason through a complex problem in one shot and LLMs also struggle when faced with a simple question/prompt addressed to a complex problem. We humans break such a problem down into simpler steps and attack those steps in sequence. The same approach can work with LLMs. For example, in trying to trace to a failure root-cause we might ask the LLM to apply conventional (non-AI) methods to grade possible fault locales, then rank that list based on factors like suspiciousness, and then provide a reasoning for each of the top 5 candidates. One caution is that this method apparently doesn’t work so well on the more advanced LLMs like GPT4-o which apparently prefer to figure out their own CoT reasoning.

Another technique is in-context learning/few-shot learning, learning from a few samples provided in a prompt. I see this method mentioned often in code creation applications, but I’m yet to find a published example for verification except for code repair in debugging. However, there is recent work on code summarization driven by few-shot learning which I think could be a starting point for augmenting prompts with semantic hints in support of fault localization.

There are other techniques such as chain-of-tables for reasoning on table-structured data and tree-of-thoughts to explore multiple paths, but in this brief article it is best next to touch on methods to automate this newfound complexity.

Automated prompt engineering

A general characteristic of ad hoc prompt engineering seems to be high sensitivity to how prompts are worded/constructed. I can relate. I use a DALL-E 3 tool to generate images for some of my blogs and find that beyond my initial attempt and a few simple changes it is very difficult to tune prompts predictably towards something that better matches my goal.

Leading AI providers now offer prompt generators such as this one for ChatGPT which will tell you what essentials you should add to your request, then will generate a new and very detailed prompt which has the added benefit of optimizing to the host model’s preferences (e.g. whether to spell out step-based reasoning or not). I tried this for image generation. It built an impressively complex prompt which unfortunately was too long to be accepted by my free subscriptions to either of 2 image generators. Google/Deepmind OPRO has a somewhat similar objective though as far as I can tell it directly front-ends the LLM, optimizing your input “meta-prompt”, then feeding that into the LLM.

There is also an emerging class of prompt engineering tools, though I wonder how effective these can be given rapid evolution in LLM models and the generally opaque/emerging characteristics of those systems. In prompt engineering perhaps the best options may still be those offered by the big model builders, augmented by your own promptware.

Happy prompting!

References

CACM: Tools for Prompt Engineering

Promptware Engineering: Software Engineering for LLM Prompt Development

Prompt Engineering: How to Get Better Results from Large Language Models

Empirical Evaluation of Large Language Models for Novice Program Fault Localization

Automatic Semantic Augmentation of Language Model Prompts (for Code Summarization)

Also Read:

What is Vibe Coding and Should You Care?

DAC TechTalk – A Siemens and NVIDIA Perspective on Unlocking the Power of AI in EDA

Architecting Your Next SoC: Join the Live Discussion on Tradeoffs, IP, and Ecosystem Realities

Posted on

Chiplets and Cadence at #62DAC

Chiplets and Cadence at #62DAC
by Daniel Payne on 08-12-2025 at 10:00 am
Categories: Cadence, EDA

SoC Cockpit Concept min

Using chiplets is an emerging trend well-covered at #62DAC and they even had a dedicated Chiplet Pavilion, so I checked out the presentation from Dan Slocombe, Design Engineering Architect in the Compute Solutions Group at Cadence. In a short 20 minutes Dan managed to cover a lot of ground, so this blog will summarize the key  points.

The need for IC design automation and chiplet automation is driven by the steady growth in the number of 5nm, 3nm and smaller nodes along with the goal of mixing and matching them as part of heterogeneous package-level, multi-die systems. Overcoming manual design challenges requires automation for: preventing stale documentation, reducing the number of human errors, abstracting low-level implementation details, preventing duplication of information sources, handling the proliferation of IPblocks used, having an automated verification strategy to reduce the number of time-consuming verification cycles, and minimizing development times.

At Cadence they are using an internal automation flow “SoC Cockpit” to meet these SoC challenges through:

  • Capturing system-level specifications
  • Using Cadence IP and partner IP libraries
  • Configuration of IP library components
  • Taking feedback from downstream flows
  • Automating verification with simulation, emulation and virtual platforms
  • Providing customer chiplet platforms and reference software

This approach aims to improve design efficiency from an executable spec through GDS II production. Here’s the basic correct-by-construction automation flow, where the specification is an executable spec; construction is the RTL with floor planning and database; software framework is the reference framework and drivers; design collateral is the testbenches, emulation and models; physical design encompasses RTL to GDS.

Design intent captured includes many details:

  • Functional specification
  • Top-level pinout
  • I/O cell selection
  • Pin multiplexing
  • Clock tree definition
  • Reset tree definition
  • Voltage domain definitions
  • Power domain definitions
  • System maps
  • Infrastructure and IP definitions

The SoC Cockpit flowchart encompasses multiple file formats and transformations.

Zooming into the SoC Builder there is SoCGen which starts with an executable spec, creates intermediate files, then finally passes the data to IPGen to create instances of IP. AI agents can be used to select which IP blocks meet the specifications. There are both built-in generators for Verilog RTL and plugin generators to work with a variety of formats: IP-XACT, SDC/UPS/USF, virtual platform, testbench, C/C++ header files.

Users work with a front-end GUI to guide through the specification capture process, enforcing the correct-by-construction approach. Cadence has been able to create this automated flow by harnessing their own tools and IP, like:

Front End 
Conformal Technologies
Jasper Apps
Joules RTL Solutions
Cadence Modus DFT Software Solution

Back End  
Genus Synthesis Solution
Innovus Implementation System
Cadence Cerebrus Intelligent Chip Explorer

Verification
Palladium Emulation
Protium FPGA-Based Prototyping Platform
Helium Virtual and Hybrid Studio
Xcelium Logic Simulator
Verisium AI-Driven Verification Platform
Perspec System Verifier

IP
Tensilica Processors
System IP, Partner IP
Interface IP – UCIe, PCIe
Memory – DDR, LPDDR, Flash

Summary

Cadence has adopted industry standards, including UCIe , Arm’s Chiplet System Architecture (CSA) and AMBA C2C protocols to ensure systems are built based on known standards. With the SoC Cockpit, the new automation features bring together architecture, design and implementation tasks resulting in faster availability of correct by construction designs. This automation reduces time to market and engineering efforts.

Partner with Cadence to help you realize your chiplet and SoC ambitions.

Related Blogs

Posted on

What XiangShan Got Right—And What It Didn’t Dare Try

What XiangShan Got Right—And What It Didn’t Dare Try
by Jonah McLeod on 08-12-2025 at 6:00 am
Categories: IP, RISC-V

XiangShan

An Open ISA, a Closed Mindset — Predictive Execution Charts a New Path

The RISC-V revolution was never just about open instruction sets. It was a rare opportunity to break free from the legacy assumptions embedded in every generation of CPU design. For decades, architectural decisions have been constrained by proprietary patents, locked toolchains, and a culture of cautious iteration. RISC-V, born at UC Berkeley, promised a clean-slate foundation: modular, extensible, and unencumbered. A fertile ground where bold new paradigms could thrive.

XiangShan, perhaps the most ambitious open-source RISC-V project to date, delivers impressively on that vision—at least at first glance. Developed by the Institute of Computing Technology (ICT) under the Chinese Academy of Sciences, XiangShan aggressively targets high performance. Its dual-core roadmap (Nanhu and Kunminghu) spans mobile and server-class performance brackets. By integrating AI-focused vector enhancements (e.g., dot-product accelerators), high clock speeds, and deep pipelines, XiangShan has established itself as the most competitive open-source RISC-V core in both versatility and throughput.

But XiangShan achieves this by doubling down on conventional wisdom. It fully embraces speculative, out-of-order microarchitecture—fetching, predicting, and reordering dynamically to maintain high instruction throughput. Rather than forging a new execution model, it meticulously refines well-known techniques familiar from x86 and ARM. Its design decisions reflect performance pragmatism: deliver ARM-class speed using proven playbooks, made interoperable with an open RISC-V framework.

What truly sets XiangShan apart is not its microarchitecture but its tooling. Built in Chisel, a hardware construction language embedded in Scala, XiangShan prioritizes modularity and rapid iteration. Its open-source development model includes integrated simulators, verification flows, testbenches, and performance monitoring. This makes XiangShan not just a core design, but a scalable research platform. The community can reproduce, modify, and build upon each generation—from Nanhu (targeting Cortex-A76 class) to Kunminghu (approaching Neoverse-class capability).

In this sense, XiangShan is a triumph of open hardware collaboration. But it also highlights a deeper inertia in architecture itself.

Speculative execution has dominated CPU design for decades. From Intel and AMD to ARM, Apple, IBM, and NVIDIA, the industry has invested heavily in branch prediction, out-of-order execution, rollback mechanisms, and speculative loads. Speculation once served as the fuel for ever-increasing IPC (Instructions Per Cycle). But it now carries mounting costs: energy waste, security vulnerabilities (Spectre, Meltdown, PACMAN), and ballooning verification complexity.

Since 2018, when Spectre and Meltdown exposed the architectural liabilities of speculative logic, vendors have shifted focus. Patents today emphasize speculative containment rather than acceleration. Techniques like ghost loads, delay-on-miss, and secure predictors aim to obscure speculative side effects rather than boost performance. What was once a tool of speed has become a liability to mitigate. This shift marks a broader digression in CPU innovation—from maximizing performance to patching vulnerabilities.

Most recent patents and innovations now prioritize security mitigation over performance enhancement. While some performance-oriented developments still surface, particularly in cloud and distributed systems, the dominant trend has become defensive. Designs increasingly rely on rollback and verification mechanisms as safeguards. The speculative execution model, once synonymous with speed and efficiency, has been recalibrated into a mechanism of trust and containment.

This is why XiangShan’s adherence to speculation represents a fork in the road. RISC-V’s openness gave the team a chance to rethink not just the ISA, but the core execution model. What if they had walked away from speculation entirely?

Unlike dataflow machines (Groq, Tenstorrent) or the failed promise of VLIW (e.g., Itanium and its successors in niche DSP or embedded markets), Simplex Micro’s predictive execution model breaks from speculative architecture—but with a crucial difference: it aims to preserve general-purpose programmability. Dataflow and VLIW each delivered valuable lessons in deterministic scheduling but struggled to generalize beyond narrow use cases. Each became a developmental cul-de-sac—offering point solutions rather than a unifying compute model.

Simplex’s family of foundational patents eliminates speculative execution entirely. Dr. Thang Tran—whose earlier vector processor was designed into Meta’s original MTIA chip—has patented a suite of techniques centered on time-based dispatch, latency prediction, and deterministic replay. These innovations coordinate instruction execution with precision by forecasting readiness using cycle counters and hardware scoreboards. Rather than relying on a program counter and branch prediction, this architecture replaces both with deterministic, cycle-accurate scheduling—eliminating speculative hazards at the root.

Developers can still write in C or Rust, compiling code through standard RISC-V toolchains with a modified backend scheduler. The complexity shifts to compilation, not programming. This preserves software portability while achieving hardware-level predictability.

XiangShan has proven what open-source hardware can achieve within the boundaries of established paradigms. Simplex Micro challenges us to redraw those boundaries. If the RISC-V movement is to fulfill its original promise—not just to open the ISA, but to reimagine what a CPU can be—then we must explore roads not taken.

And Predictive Execution may be the most compelling of them all: the fast lane no one has yet dared to take.

Also Read:

Podcast EP294: An Overview of the Momentum and Breadth of the RISC-V Movement with Andrea Gallo

Andes Technology: Powering the Full Spectrum – from Embedded Control to AI and Beyond

From All-in-One IP to Cervell™: How Semidynamics Reimagined AI Compute with RISC-V

Posted on

The Critical Role of Pre-Silicon Security Verification with Secure-IC’s Laboryzr™ Platform

The Critical Role of Pre-Silicon Security Verification with Secure-IC’s Laboryzr™ Platform
by Kalar Rajendiran on 08-11-2025 at 10:00 am
Categories: EDA, Secure-IC, Security

Pre Silicon Security Verification (Hardware SCA)

As embedded systems and System-on-Chip (SoC) designs grow in complexity and integration, the risk of physical attacks has dramatically increased. Modern day adversaries no longer rely solely on software vulnerabilities; instead, they exploit the physical properties of silicon to gain access to sensitive data. Side-channel attacks (SCA) and fault injection attacks (FIA) have emerged as some of the most potent threats, targeting the physical behavior of chips through power analysis, timing discrepancies, or induced faults. While cryptographic algorithms remain mathematically sound, their hardware implementations often betray subtle leakages that attackers can exploit.

To confront these risks proactively, Secure-IC has developed Laboryzr™, a pre-silicon security verification platform that enables hardware and software teams to simulate real-world threats and validate countermeasures during design—long before tape-out.

Why Pre-Silicon Security Matters

The financial and operational impact of discovering a security flaw post-silicon is enormous. Fixes at this stage involve redesign, re-fabrication, and potentially even product recalls. In contrast, pre-silicon verification allows vulnerabilities to be detected and resolved when the cost of change is still low. For industries such as automotive, defense, medical devices, and critical infrastructure, early detection is not only practical—it’s imperative.

Through pre-silicon security verification, organizations can align more easily with demanding security certifications like FIPS 140-3, ISO/IEC 19790, and Common Criteria. Just as importantly, they can ensure that devices are robust against real-world threats like differential power analysis or electromagnetic glitching.

Introducing Laboryzr™: A Platform for Security Sign-Off

Laboryzr™ is Secure-IC’s comprehensive platform for pre-silicon security verification. With Laboryzr, teams can measure and validate the effectiveness of security countermeasures before tape-out, transforming security sign-off from a concept into a measurable reality.

One of Laboryzr’s most powerful attributes is its ability to provide traceability from specification to silicon. By linking threat models directly to RTL and attack simulations, it ensures that security coverage is both complete and verifiable. Laboryzr™ integrates with industry EDA tools used across the SoC design flow, enabling it to catch vulnerabilities early and help reduce the need for costly post-silicon fixes.

Laboryzr’s Pre-Silicon Verification Components

Virtualyzr™ focuses on the hardware layer. It simulates and emulates side-channel and fault injection attacks at various abstraction levels—from RTL to post-synthesis—leveraging existing EDA workflows. Through the use of Value Change Dump (VCD) files, it reconstructs signal activities that mimic power or electromagnetic emissions, enabling leakage detection and exploitation analysis. It also supports fault injection modeling, including clock glitches, electromagnetic interference, and laser attacks. Originally limited to analyzing small IP blocks like AES cores, Virtualyzr™ has evolved to support full-chip and chiplet-scale analysis through advanced parallelization and optimization.

Catalyzr™ addresses the software layer, where it analyzes source code and binaries to detect vulnerabilities such as timing side channels, cache-based leakages, and improper cryptographic API usage. It performs both static and dynamic analysis to evaluate masking countermeasures, cryptographic integration, and execution behavior. With over seven years of field use, Catalyzr™ has matured into a key component of pre-silicon software security assessments.

Designed for the Modern SoC Design Flow

Laboryzr™ has been under development for more than a decade, evolving through constant customer feedback. One of the earliest challenges faced by Secure-IC was how to create a user interface that seamlessly fit into the existing SoC design flow. Originally offering only a graphical interface, Laboryzr later added a command line interface (CLI) to support CI/CD workflows and accommodate power users seeking integration into automated verification environments.

As customer demands shifted toward larger and more complex designs—including SoCs and chiplets—Laboryzr™ underwent fundamental architecture changes. Secure-IC optimized the platform for speed and scalability, enabling high-throughput simulations that could handle full-chip assessments. These improvements, along with robust support for Place and Route (PR) phases, positioned Laboryzr™ as a go-to solution for teams that require both depth and breadth in their security analysis.

Built for What’s Next: PQC, Chiplets, and Beyond

Secure-IC continues to future-proof Laboryzr™ by expanding support for post-quantum cryptography (PQC) and emerging chiplet-based architectures. The platform is being extended to validate PQC algorithm implementations and to analyze interactions between chiplets, especially as heterogeneous integration becomes more common in next-generation SoC design.

Secure-IC’s upcoming acquisition by Cadence also positions Laboryzr™ for even deeper integration into mainstream EDA workflows. With Cadence as an internal customer, Laboryzr™ will gain access to more complete design environments, allowing further validation of its capabilities on complex, multi-chip systems.

Market Context and Differentiation

Unlike solutions focused on software security or information flow analysis or security verification post-silicon, Secure-IC has long focused exclusively on physical attack emulation at the pre-silicon stage. Laboryzr’s tight integration with EDA flows, real-time emulation capability, and multi-layered approach make it uniquely positioned to address the needs of design teams working from RTL to place and route.

Summary

As hardware security threats continue to evolve, the need for comprehensive, early-stage verification is greater than ever. Security must be engineered with the same rigor and traceability as functional requirements. Secure-IC’s Laboryzr™ platform represents a significant advancement in how security is implemented, validated, and signed off in the silicon lifecycle. It empowers chip developers to simulate threats, validate defenses, and certify hardware security—before silicon is produced.

By enabling early detection of physical vulnerabilities, linking threat models to design data, and providing automation-ready interfaces for hardware and software teams, Laboryzr™ delivers a true shift-left security solution. Its continued development in areas like PQC and chiplet support ensures that it remains at the cutting edge of security verification.

To learn more, you can visit the following pages:

Laboryzr brochure page

Laboryzr product page

Catalyzr product page

Virtualyzr product page

Also Read:

Secure-IC at the 2025 Design Automation Conference #62DAC

Anirudh Keynote at CadenceLIVE 2025 Reveals Millennium M2000

A Timely Update on Secure-IC

Posted on

Should Intel be Split in Half?

Should Intel be Split in Half?
by Daniel Nenni on 08-11-2025 at 6:00 am
Categories: FinFET, Foundries, GAA, Intel Foundry
10 Comments

Intel Should Not Be Split!

A recent commentary from four former Intel board members argue that Intel should be split into two separate companies with separate CEOs and separate board of directors. Charlene Barshefsky, Reed Hundt, James Plummer, and David Yoffie wrote that Intel shareholders should insist on a split which would create a new, independent, manufacturing entity (foundry) with its own CEO and board that would position Intel Foundry as an alternative to TSMC. This is what I call the NOT TSMC market which is companies who want 2nd and 3rd source manufacturing to keep competition alive and well in semiconductor manufacturing. This is a very good thing as we all know.

The semiconductor industry had a thriving NOT TSMC market down to 28nm. At 28nm customers could tape-out to TSMC then take the design files (GDSII) to SMIC, UMC, Chartered, or Samsung for competitive manufacturing. Qualcomm for example routinely used multiple foundries for a given design. At 14nm we switched to FinFETs and customers no longer had the ability to multisource manufacturing due to technical differences between FinFET processes, so chip designers had to choose one foundry for a given design. The other problem with FinFETs is that they are were very difficult to manufacture so we lost GlobalFoundries, UMC and SMIC as alternatives. Even more daunting, Samsung Foundry started having yield problems at 10nm which continue down to 3/2nm which uses the new GAA devices.

As a result TSMC has 90%+ market share at 3nm FinFET and will again dominate at 2nm which is GAA. Clearly this is well deserved as TSMC has executed in a fashion no other foundry, or semiconductor company for that matter, has ever before, absolutely.

The four people mentioned above did serve on the Intel board. Charlene Barshefsky served for 14 years (from 2004 to 2018) she is 75 years old. Reed Hundt served for 19 years (2001 to 2020) and is 77 years old. Jim Plumber served 12 years (2005 to 2017) and is 76 years old. David Yofie served for 28 years (November 1989 until May 2018), he is 71 years old. I certainly respect their service but they come from a different world than what we are dealing with today.

Now let me offer you my opinion on what Intel should do. This comes from a semiconductor professional working in the trenches for the past 40 years. I do not believe Intel should be split. Intel Design needs to be closely integrated with manufacturing. This collaborative recipe has succeeded in the past and can succeed in the future under Lip-Bu Tan.

You can use the AMD split as an example. The design side of AMD is wildly successful while the manufacturing side (GlobalFoundries) is stagnated. What saved AMD is the close relationship they have with TSMC (manufacturing). In fact, I would argue that the relationship between AMD and TSMC is even closer than Apple, TSMC’s top customer. The other close customer relationship TSMC has is with Nvidia, another big Intel competitor.

Unfortunately, Intel will not have this close of a relationship with TSMC anytime soon, even if they split the company. We can argue this in the comment section if you would like but let me tell you it will not happen. Those days have passed. Can Intel effectively compete with AMD and NVIDIA without having a super close relationship with manufacturing? No, they cannot.

The other thing you must know is that TSMC would not be in the dominant position they are in today without close customer collaboration. Intel Foundry needs Intel Design for that collaboration in addition to other customers that are willing to step up and vote for Intel Foundry to be successful.

The other question that needs to be considered: Can the United States stay competitive in the world without homegrown leading edge semiconductor manufacturing?

No, we cannot. We can argue this as well but let me tell you it will not happen and the security of our nation is at risk.

Should it be left up to the Intel Shareholders to decide? Of course it should. The current and former Intel board members got Intel to where they are today so I would definitely not leave it up to them.

Bottom line: I am not am not currently an Intel shareholder but I have been in the past. If I were a shareholder I would vote to keep Intel as a whole while lobbying the government and top US fabless semiconductor companies to invest in Intel and make sure the United Sates maintains our technology leadership and stays secure.

“POTUS and DoC can set the stage, the customers can make the necessary investments, the Intel Board can finally do something positive for the company, and we stop writing opinion pieces on the topic.” Crag Barrett, former CEO of Intel 8-10-2025.

Also Read:

Making Intel Great Again!

Why I Think Intel 3.0 Will Succeed

Should the US Government Invest in Intel?

 

Posted on

XTCO: From Node Scaling to System Scaling

XTCO: From Node Scaling to System Scaling
by Admin on 08-10-2025 at 10:00 am
Categories: 3D IC

imec XTCO Image SemiWIki

imec XTCO (Cross-Technology Co-Optimization) is the natural successor to DTCO and STCO in an era where no single layer of the stack can deliver scaling alone. Instead of optimizing devices, interconnect, packaging, architecture, and software in isolation, XTCO treats them as one tightly coupled system with a shared budget for performance, power, area, cost—and increasingly, embodied energy. The premise is simple but powerful: you don’t “win” PPAC by improving a transistor or a router hop in a vacuum; you budget PPAC across layers, guided by real workloads and realistic manufacturing constraints.

The XTCO loop starts with workload-anchored targets. Latency, throughput, perf/W, power envelopes, and cost per good system are stated up front, often with thermal and reliability ceilings. From there the program explores architectural partitioning—monolithic die versus a graph of chiplets; how many HBM stacks; whether to place last-level cache as 3D SRAM; what fabric topology and link widths to adopt. Each partition implies different stress on the power delivery network, different heat flux patterns, and different yield arithmetic. XTCO keeps those implications visible while decisions are still cheap.

Next, teams pick technology option sets: device flavors (nanosheet, forksheet, CFET), BEOL stacks and via rules, backside power delivery, and 2.5D/3D packaging choices such as silicon interposers, bridges, hybrid bonding, or fan-out panel flows. Thermal solutions—air, vapor chamber, cold plate—are treated as first-class technology knobs, not afterthoughts. The method insists on co-simulation: timing with realistic interconnect RC, SI/PI with package parasitics, thermal fields with activity factors from the actual software, and yield/cost with compounded probabilities across dice, interposers, and assembly. What emerges isn’t a single “answer” but a ranked set of feasible corners with quantified risk.

XTCO’s most practical contribution is hierarchical budgeting. Instead of over-guardbanding everywhere, the program assigns tight margins where models are confident and reserves slack where uncertainty is high. For example, you might trade a denser BEOL option for a cooler that shaves 10–15 °C at the hotspots, which in turn relaxes voltage guardbands and timing derates. Or you might accept a slightly larger die if a simpler PDN flattens IR drop and shortens schedule. XTCO surfaces these trades transparently in a techno-economic dashboard: energy per task (or per token), perf/W, cost per good module, thermal headroom, schedule risk, and supply-chain sensitivity.

The approach shines in chiplet programs. Reticle limits and yield realities push large systems toward multi-tile logic with multiple HBM stacks. But chiplets aren’t a free lunch: link power, latency, synchronization, and package routing all tax the budget. XTCO asks whether links can move from SerDes-like PHYs to short-reach die-to-die fabrics; whether hybrid bonding eliminates energy per bit enough to justify process complexity; whether a glass substrate or panel flow reduces warpage and improves assembly takt time. Crucially, it forces known-good-die and known-good-interposer assumptions into the cost model, preventing surprises at bring-up.

Organizationally, XTCO is as much process as it is technology. It demands shared data models between device, package, and system teams; early availability of packaging/cooling PDKs; and a steady cadence of risk burndown vehicles—small test chips or thermal coupons that retire the riskiest assumptions first. It also calls for decision hygiene: which metrics decide, who owns the budget, and how often the stack is re-balanced as software or supply conditions change.

XTCO is not without friction. Model fidelity can lag exploration speed. Packaging toolchains are less standardized than front-end flows. And the supply chain—from foundry to OSAT to cooler vendors—must be synchronized so a single slow takt doesn’t cap the whole program. Yet the payoff is decisive: predictable delivery of systems that meet PPAC targets with fewer late-stage pivots, and a roadmap where scaling comes from coordination, not just shrink. In short, XTCO turns optimization into a contract across the stack—and that contract is how modern systems ship on time and on budget.

Posted on

CEO Interview with Karim Beguir of InstaDeep

CEO Interview with Karim Beguir of InstaDeep
by Daniel Nenni on 08-10-2025 at 8:00 am
Categories: CEO Interviews

unnamed

Karim Beguir is InstaDeep’s Chief Executive Officer. He helps companies get to grips with the latest AI breakthroughs and deploy these in order to improve efficiency and ROI. As a graduate of France’s Ecole Polytechnique and former Program Fellow at NYU’s Courant Institute, Karim has a passion for teaching and using applied mathematics. He is also a mentor at Google for Startups Accelerator and is a steering committee member of Deep Learning Indaba. Karim is on a mission to democratise AI and make it accessible to a wide audience.

Tell us about your company?

InstaDeep delivers AI-powered decision-making systems for enterprises, at scale, thanks to expertise in Artificial Intelligence research, software development, and high-performance computing. InstaDeep has a track record in several industries such as biotechnology, logistics, and electronics. In 2024, InstaDeep launched the Pro version of DeepPCB, a cloud-based AI Place & Route solution.

What problems are you solving?

DeepPCB addresses the time-consuming and complex process of manual placement and routing for printed circuit boards (PCBs). DeepPCB is not an EDA solution, it’s complimentary to EDA companies that have PCB design tools. Its AI-powered approach leverages reinforcement learning to deliver high-quality routing that meets modern PCB design requirements beyond the capabilities of traditional auto-routers. DeepPCB accelerates design cycles, produces DRC-clean layouts, and optimizes routing paths to eliminate violations. By overcoming the limitations of manual and traditional PCB design methods, DeepPCB provides engineers and designers with a more efficient, accurate, and scalable solution, ultimately reducing time-to-market, overall design effort and faster product deployment.

What application areas are your strongest?

DeepPCB is built for companies designing complex PCBs, especially in areas like consumer electronics, automation, and industrial tech, where quality control isn’t optional. If speed, precision, and efficiency matter to your business, our automated PCB placement and routing will save you significant time, deliver higher-quality boards, and make your team more productive.

What keeps your customers up at night? Engineering teams are focused on meeting aggressive tape-out schedules by working backward from final deadlines through prototyping and the entire PCB design process. They are seeking ways to leverage new technologies to streamline this workflow and manage increasing complexity. With growing demand and limited resources, simply adding headcount may not resolve these challenges, prompting the need for smarter, more automated solutions to ensure timelines are met without compromising quality.

What does the competitive landscape look like and how do you differentiate?

DeepPCB faces competition from established players who are integrating AI into their existing solutions, as well as from specialized AI-focused startups and even community-driven initiatives. DeepPCB distinguishes itself by transforming the PCB design process from a manual, time-consuming endeavor into an efficient, AI-driven, and cloud-based workflow, resulting in faster development cycles, optimized designs, and greater accessibility for engineers and businesses of all sizes.

What new features/technology are you working on?

DeepPCB is actively working on adding new features to its offering, with the goal to support more use-cases and serve more enterprise customers. The team is also focusing on scaling the solution to bigger and more complex boards. The online platform is also constantly evolving, with fresh new interfaces and interactivity features.

How do customers normally engage with your company?

Customers typically engage with DeepPCB in several ways. Companies involved in PCB design often approach DeepPCB to address current design challenges, while many are also planning for future projects and seeking a competitive edge. Organizations with existing PCB design technology turn to DeepPCB to enhance their capabilities beyond traditional tools. Additionally, resellers look to expand their offerings by partnering with DeepPCB, and research groups engage to stay updated on the latest advancements in AI for PCB design.

DeepPCB offers multiple engagement models, including its cloud-based platform and API integration. The company remains active in the PCB design community by publishing blogs, providing free trials, and offering flexible pricing options to meet diverse customer needs.

Also Read:

CEO Interview with Dr. Avi Madisetti of Mixed-Signal Devices

CEO Interview with Andrew Skafel of Edgewater Wireless

CEO Interview with Jutta Meier of IQE