Forem: WIOWIZ Technologies

RVP - Reusable Verification Platform

WIOWIZ Technologies — Tue, 14 Apr 2026 12:03:32 +0000

Introducing the Reusable Verification Platform (RVP) from WIOWIZ, designed to expedite the chip Design verification process. RVP generates the environment and simulates it on FSiMX, our proprietary functional simulator, eliminating the need for any third-party dependencies throughout the verification chain.

YAML in → UVM environment out → compiled, elaborated, simulated → coverage reported. The entire flow is WIOWIZ, end to end.

Key features include:

Describe your SoC's bus architecture (APB, AHB-Lite, AXI4) and peripherals (UART, SPI, I2C, CAN FD, Timer, PWM, ADC, DMA, etc.), and RVP generates a complete testbench.

Environment that includes:

Per-IP agents with driver, monitor, and sequencer
Protocol-specific VIP checkers and coverage collectors
Auto-generated functional coverpoints, cross-coverage bins, and SVA assertions per IP
A comprehensive coverage plan for review before simulation begins

We are sharing this in beta to address the verification infrastructure challenge, the extensive time spent wiring environments before the first real test.
The free tier allows you to build a simple microcontroller-class SoC, view the complete generated architecture, review the coverage plan, and run simulations. Templates and UVM structure are visible, and full VIP source is licensed. ( Soon we will add complete test suite )

The methodology focuses on functional coverage-driven tests to ensure code coverage, with every test created to meet a coverage bin requirement.

Please share your feedback on what’s missing.

Our roadmap extends to ADAS, SensorFusion, DPU, TCON/DDI, and application processor-class SoCs featuring high-speed interfaces and memory subsystems.

WIOWIZ Technologies | FSiMX Cloud v0.6.0 Beta

Semiconductor #UVM #EDA #ChipDesign #Verification #SoC #VLSI #WIOWIZ #RVP

FSiMX: Building a Verification Simulator as a Platform

WIOWIZ Technologies — Sun, 15 Mar 2026 05:37:10 +0000

We are releasing the beta version of FSiMX, a Functional Verification Simulator developed by WioWiz Technologies.

WIOWIZ Technologies / fsimx_beta · GitLab

Simulation is the backbone of modern chip verification.

Every design iteration, regression cycle, and debugging session ultimately flows through a simulator. Yet most verification environments still treat simulators as fixed tools — something you run, observe results from, and move on.

But as silicon systems become more complex, that model begins to break down.

At WIOWIZ, we started exploring a different question:

What if the simulator itself were treated as a platform?

That exploration led to FSIMX.

When Simulation Becomes Infrastructure

In small projects, simulation feels straightforward:
run tests, inspect waveforms, debug failures.

But as designs scale, simulation environments quickly grow into something much larger:

Regression Orchestration
Waveform Analysis Pipelines
Debugging Infrastructure
Performance Monitoring
Coverage Collection

Over time, the simulator stops being just a program and becomes the core execution engine of verification.

At that point, treating it as a closed tool starts to limit what teams can build around it.

The Platform Perspective

Thinking of a simulator as a platform changes the architecture of verification workflows.

Instead of only executing HDL code, the simulator becomes an extensible environment where engineers can layer additional capabilities such as:

Runtime Inspection Tools
Debugging Instrumentation
Custom Verification Flows
Analysis Frameworks

This shifts the mindset from:

“Run simulation and analyze results.” to “Build verification infrastructure on top of simulation.”

That difference becomes increasingly important as chip complexity grows.

Why Modern Systems Demand This Shift

Today’s silicon designs combine multiple domains:

Heterogeneous Compute Engines
Accelerators and AI workloads
High-speed Memory Interfaces
Chiplet-based Architectures

Verifying these systems requires more than functional checks. Engineers need deep visibility, scalable regressions, and flexible debugging environments.

Traditional simulator usage models were never designed for this level of infrastructure.

The Idea Behind FSIMX

FSIMX explores what happens when simulation is built with this platform mindset from the start.

Rather than focusing solely on executing HDL, the idea is to enable a verification environment where new tooling, analysis layers, and experimental capabilities can evolve around the simulation core.

It’s less about replacing existing simulators and more about enabling a different way to build verification infrastructure.

The architectural thinking and motivations behind FSIMX are explained in detail in the canonical article from WIOWIZ.

👉 FSiMX: Building a Verification Simulator as a Platform - WIOWIZ Technologies Pvt Ltd

A Larger Trend in EDA

Across the semiconductor ecosystem, engineering teams increasingly want tools that behave like systems they can extend, not black boxes they must work around.

Simulation is one of the most natural places for that shift.

When the simulator becomes a platform, verification teams gain the ability to build their own infrastructure — tailored to their design complexity and workflows.

Final Thought

Verification is already the most resource-intensive part of chip development.

Improving simulation infrastructure can have a massive impact on how efficiently teams debug, iterate, and validate silicon.

Treating the simulator as a platform might be one of the most important shifts in how verification environments evolve.

To explore the full engineering perspective behind FSIMX, read the original article from WIOWIZ:

👉 FSiMX: Building a Verification Simulator as a Platform - WIOWIZ Technologies Pvt Ltd

DFT: The Crucial Gap in Open-Source Chip Design

WIOWIZ Technologies — Sun, 22 Feb 2026 02:37:53 +0000

The Gap That Blocks Tapeout

As we neared tapeout, a hard reality set in.

Our RTL was verified.
Synthesis ran clean through Yosys.
Place-and-route was handled by OpenROAD.

But none of that gets you a testable chip.

The Problem Nobody Talks About

Generating a layout is not the same as producing testable silicon.

After fabrication, real chips must:

Detect manufacturing defects
Measure fault coverage
Load tester-ready patterns
Diagnose failures

Without proper DFT infrastructure:

Internal state elements are inaccessible
Fault coverage cannot be quantified
Automated test equipment (ATE) cannot validate the die
Yield analysis becomes guesswork

You can fabricate a chip.

But you cannot confidently prove it works.

Why This Gap Is Structural — Not Cosmetic

DFT is often misunderstood as “just adding JTAG.”

In production silicon, it involves:

Structural scan integration
Fault modeling and simulation
Automatic Test Pattern Generation (ATPG)
Coverage measurement
Tester-compatible vector export
Built-in self-test strategies

Open RTL-to-GDSII stacks do not yet provide a production-grade solution for this layer.

And that gap becomes painfully visible as tapeout approaches.

What WIOWIZ Discovered in Practice

While building a practical open silicon pipeline, WIOWIZ encountered a critical truth:

The missing layer wasn’t synthesis.
It wasn’t routing.
It wasn’t timing closure.

It was testability.

Certain fault coverage ceilings, modeling inconsistencies, and structural limitations only become visible when pushing toward manufacturing-grade validation.

These aren’t issues that show up in simulation demos.

They show up when silicon is already fabricated.

The detailed engineering observations — including why coverage plateaus occur and what actually resolves them — are covered in the canonical article:

👉 DFT: The Crucial Gap in Open-Source Chip Design

The Bigger Question for Open Silicon

Open-source hardware is advancing rapidly.

But unless the ecosystem solves:

How to insert scalable scan reliably
How to model faults correctly
How to measure meaningful coverage
How to generate tester-ready outputs

…it remains incomplete for production silicon.

DFT is not an enhancement layer.

It is the bridge between “design complete” and “silicon validated.”

Canonical source:
DFT: The Crucial Gap in Open-Source Chip Design

Bridging Digital and Photonic Verification

WIOWIZ Technologies — Mon, 09 Feb 2026 13:36:19 +0000

Silicon photonics is rapidly moving from research labs into production silicon — especially in high-speed networking, AI infrastructure, and next-generation interconnects.

Yet most verification flows are still built for a world where everything is electrical.

That gap is becoming a real risk.

When digital controllers and photonic devices interact in closed loops, verifying them in isolation is no longer sufficient.

At WIOWIZ, this problem surfaced not as theory, but as a practical verification challenge while building real mixed-signal, mixed-physics systems.

Why Traditional Verification Breaks Down

Digital verification has matured over decades:

RTL → gate-level simulation
coverage-driven regressions
fault injection and corner analysis

Photonic design tools, on the other hand, focus on:

optical behavior
waveguide loss and coupling
resonator response
thermal effects

Each domain works well on its own — but modern photonic chips depend on digital control loops to remain functional.

That interaction is where bugs hide.

The Real Problem Is the Boundary

In silicon photonic systems:

Digital logic drives DACs
DACs tune photonic devices
Photodiodes feed signals back
Controllers react cycle by cycle

This is not a static interface — it’s a feedback system.

Verifying digital logic without realistic photonic behavior (or vice versa) creates blind spots that only appear late in silicon or lab bring-up.

A Mixed-Domain Verification Approach

The approach described by WIOWIZ treats the system as one integrated entity:

Digital controllers simulated at RTL / gate-level
Photonic devices represented as behavioral models
DAC/ADC boundaries connecting both domains
Clock-driven co-simulation across domains

This allows engineers to observe:

system-level convergence and stability
calibration logic behavior under drift
timing, noise, and fault scenarios
bit-error trends before tape-out

Importantly, this runs fast enough for regression-level verification, not just one-off experiments.

Why Behavioral Photonic Models Matter

Full optical physics simulations are accurate — but too slow for system verification.

Instead, behavioral photonic models capture:

loss and coupling effects
resonator response curves
photodiode current behavior
thermal drift and noise

These are the effects that digital controllers actually see.

By modeling what matters — not everything — verification becomes both practical and predictive.

This Is Where Most Teams Get Stuck

Many teams still verify:

digital logic separately
photonic behavior separately

But real systems don’t fail in isolation.

They fail when:

calibration loops oscillate
control FSMs mis-handle drift
noise pushes systems out of lock
feedback timing assumptions break

Those failures only show up when both domains are simulated together.

The full explanation, diagrams, and flow details are covered in the canonical article on WIOWIZ:
👉 Bridging Digital and Photonic Verification

Why This Matters Going Forward

Silicon photonics is no longer optional for:

hyperscale networking
AI accelerators
disaggregated computing
next-gen chiplet architectures

Verification methodologies must evolve with it.

Mixed-domain co-simulation is not a “nice to have” — it’s becoming a baseline requirement for reliable silicon.

Read the Full Canonical Article

This dev.to post intentionally avoids deep implementation details.

If you want:

system diagrams
verification flow structure
fault injection examples
BER and eye-diagram methodology

Read the full article on WIOWIZ (canonical source):
👉 Bridging Digital and Photonic Verification

The Game of Imitation: A Way to Build Consciousness

WIOWIZ Technologies — Mon, 02 Feb 2026 01:54:08 +0000

Most AI systems today are impressive imitators — but poor learners.

They can reproduce patterns at scale, remix existing knowledge, and respond convincingly. Yet the moment context shifts or references disappear, they collapse back into dependency.

This raises a deeper engineering question:

Is intelligence something you program — or something that emerges through disciplined imitation and accumulation?

At WIOWIZ, this question didn’t start as philosophy. It started as a very practical engineering problem.

From Copying Code to Understanding Systems

In real engineering teams, learning doesn’t happen by memorizing outputs. It happens through repetition and abstraction:

Copy an existing implementation
Modify it to fit a new requirement
Recognize recurring patterns
Internalize structure
Create independently

That journey — from imitation to autonomy — is exactly how human engineers mature.

Most AI systems today stop at step 1 or 2.

Imitation Is Not the Problem — Shallow Imitation Is

The famous “imitation game” (often linked to the Turing Test) focuses on whether a system appears intelligent.

But appearance isn’t understanding.

True learning requires a system to:

extract structure from examples
store it internally
reproduce functionality without referring back to the original artifact

If you delete the output and the system can regenerate it from its internal model alone — something fundamental has changed.

That shift matters far more than conversational fluency.

Artifact vs Understanding

One distinction became critical in our work:

Artifact → the generated code, file, or output
Understanding → the internal representation that produced it

Artifacts are disposable. Understanding is reusable.

Most AI systems today preserve artifacts, not understanding. That’s why they struggle with transfer learning, long-term consistency, and true generalization.

This is also where discussions around “consciousness” quietly intersect with engineering reality — not as mysticism, but as accumulated internal state that influences future behavior.

Why Engineers Should Care About This

You don’t need to believe machines can be conscious to recognize this:

Systems that learn structurally outperform systems that retrieve statistically.

In domains like:

Hardware design
RTL generation
Verification flows
Safety-critical AI
Autonomous systems

…mere imitation isn’t enough. Systems must internalize rules, constraints, and intent — not just replay patterns.

The Full Engineering Context (Worth Reading)

This post intentionally avoids deep implementation details — validation loops, reconstruction control, iteration memory, and spec-to-RTL learning pipelines are discussed in the original article.

If you’re curious how these ideas emerge from real systems work (not theory), read the canonical version here:

👉 The Game of Imitation: A Way to Build Consciousness

Final Thought

Consciousness may remain a philosophical debate.

But learning through imitation, accumulation, and internal reconstruction is already an engineering requirement.

And systems that master it won’t just look intelligent —
they’ll behave intelligently when references disappear.

VAIDAS: Real-Time ADAS Inference on VAI Architecture

WIOWIZ Technologies — Mon, 02 Feb 2026 01:35:33 +0000

In ADAS systems, average performance is meaningless.

What matters is this single question:

What is the worst-case latency when multiple perception and control models must run together?

Most inference platforms optimize for throughput — TOPS, FPS, utilization. But for braking, steering, and collision avoidance, deterministic execution time matters far more than peak numbers.

This is the problem VAIDAS set out to solve.

The Hidden Cost of Model Reloading

A typical ADAS pipeline runs multiple models:

Lane detection
Object detection
Road edge estimation
Free-space detection
Control inference

On conventional NPUs or GPUs, each model switch involves:

Weight loading
Cache invalidation
Pipeline warm-up

Even when computation is fast, reload overhead dominates latency.

When you chain several models together, those costs add up quickly — and unpredictably.

VAIDAS Takes a Different Architectural Path

VAIDAS applies the VAI (Virtual AI Inference) principle to ADAS workloads.

Instead of treating model weights as reloadable data:

Each ADAS model lives in its own dedicated weight bank
Switching models is a one-cycle select, not a reload
All models remain resident during operation

This turns a sequential, memory-bound problem into a deterministic, compute-bound one.

Why Deterministic Cycles Matter More Than TOPS

With VAIDAS:

Multiple ADAS models execute back-to-back
Total execution completes in tens of cycles, not hundreds
Worst-case latency is fixed and bounded

At automotive clock speeds, this pushes inference latency into sub-microsecond territory — a regime where control loops can rely on guaranteed timing, not averages.

This distinction is why throughput-centric benchmarks fail to describe real ADAS safety behavior.

What This Post Intentionally Skips

This dev.to post does not cover:

Weight banking layout
Model graph structure
Cycle-accurate scheduling
Simulation and validation setup
Real ADAS scenario breakdowns

Those details are covered in the canonical article.

👉 Read the full technical deep dive here:
VAIDAS: Real-Time ADAS Inference on VAI Architecture

The Bigger Takeaway

VAIDAS isn’t about running AI faster.
It’s about running multiple AI models predictably.

For ADAS and safety-critical systems, that architectural shift matters more than raw performance numbers.

Canonical Source

This is a summarized adaptation.
Original article: VAIDAS: Real-Time ADAS Inference on VAI Architecture

Why In-House EDA and Chip Flow Intelligence Are No Longer Optional

WIOWIZ Technologies — Fri, 30 Jan 2026 02:56:34 +0000

For years, chip teams accepted a hard truth:
EDA tools are expensive, opaque, and unavoidable.

If you’re a startup or a lean silicon team, that usually means delaying real validation until licenses are affordable — and hoping no fundamental issue appears too late.

That approach no longer holds.

Today, lack of in-house EDA capability and flow intelligence has become a strategic execution risk, not just a cost problem.

The Silent Constraint Most Teams Live With

Many teams operate in this uncomfortable middle ground:

Open-source tools are accessible, but incomplete
Commercial tools are powerful, but only usable late
Early iterations happen with limited visibility
Failures repeat because context is lost

This creates a dangerous reality:

Teams design without feedback and only gain confidence when change is most expensive.

The problem isn’t talent or effort.
It’s the absence of internal flow ownership.

Tools Aren’t the Problem — Memory Is

Commercial EDA tools are extremely capable — but they are black boxes.

They don’t:

Remember why something failed last time
Capture design-specific patterns
Preserve decision context across projects
Learn from past verification cycles

Large EDA vendors have decades of internal flow intelligence.
Most startups have none.

As a result, every project starts from scratch.

What “Chip Flow Intelligence” Actually Means

Chip flow intelligence isn’t about replacing commercial EDA.

It’s about building awareness around your flow :

Tracking failures across runs
Capturing why fixes worked
Identifying recurring bottlenecks
Enabling cheap iteration early

When a team can answer:

“Have we seen this failure pattern before?”

Debug time collapses.

That single capability changes how fast teams move.

Why In-House EDA Capability Is Becoming Mandatory

External dependency is no longer just about licensing cost.

Teams now face:

Restricted tool access
Vendor-locked workflows
Limited customization
Zero visibility into internals

Building even partial in-house EDA capability allows teams to:

Iterate earlier
Reduce late-stage surprises
Use commercial tools more effectively
Accumulate long-term engineering memory

The smartest teams don’t reject commercial EDA.
They delay dependency until it truly matters.

What This Post Skips (On Purpose)
This dev.to post avoids:

Tool-by-tool comparisons
Flow architecture details
Real failure case studies
How intelligence is implemented

Those are covered in the canonical article.

👉 Read the full version here:
Why In-House EDA and Chip Flow Intelligence are no longer optional ?

The Takeaway

In-house EDA and chip flow intelligence aren’t about saving money.
They’re about owning iteration speed, confidence, and control.

In modern chip design, that’s no longer optional.

Canonical Source

This post is a summarized adaptation.
Original article: Why In-House EDA and Chip Flow Intelligence are no longer optional ?

Why Coverage Signoff Still Fails (Even with Better Tools)

WIOWIZ Technologies — Thu, 29 Jan 2026 17:19:18 +0000

Coverage signoff is supposed to answer one simple question:

Are we done verifying this design?

Yet in real projects, it rarely does.

Despite faster simulators, richer metrics, and more automation, coverage signoff still becomes one of the slowest and most painful phases before tapeout.

So what’s actually broken?

The Familiar Coverage Loop

Most verification teams recognize this cycle immediately:

Coverage plan defined
Regressions run
Coverage numbers improve
Review meetings start
Questions pile up
New tests are added
Regressions rerun
Numbers go up… but confidence doesn’t

Weeks pass. Sometimes months.

The tools are working — but signoff still doesn’t happen.

Metrics Aren’t the Same as Meaning

Modern tools generate plenty of data:

Code coverage
Functional coverage
Cross coverage
Feature matrices

What they don’t generate is interpretation.

A coverage report can tell you what was exercised — but not:

Whether it matches spec intent
Whether missing holes matter
Whether edge cases are acceptable
Whether reviewers will agree

That gap between measurement and meaning is where signoff stalls.

The Real Bottleneck Isn’t Simulation

On real projects, only a small fraction of verification time is spent running tools.

Most time is lost waiting on:

Reviews
Clarifications
Signoff discussions
Subjective judgment calls

Coverage becomes a negotiation, not a metric.

And no percentage threshold can resolve that on its own.

Why Better Tools Haven’t Fixed This

EDA tools are excellent at counting events — but poor at understanding intent.

They don’t:

Capture why coverage items exist
Remember past signoff decisions
Understand specification semantics
Prioritize what actually matters

As a result, every project restarts the same debate from scratch.

What This Post Skips (On Purpose)

This dev.to post avoids:

Real project examples

Time breakdowns from the field

How human judgment dominates signoff

Why “coverage closure” is often an illusion

Those details are explained in the canonical article.

👉 Read the full breakdown here:
The Loop Nobody Talks About : Why Coverage Signoff Is Still Broken After 20 Years

The Takeaway

Coverage signoff isn’t broken because tools are weak.
It’s broken because confidence can’t be reduced to a number.

Until verification flows account for intent, context, and interpretation — teams will keep looping, no matter how high coverage percentages climb.

Canonical Source

This post is a summarized adaptation.
Original article: The Loop Nobody Talks About : Why Coverage Signoff Is Still Broken After 20 Years

Real-Time Quality Monitoring in Food Processing: Why Manual Inspection No Longer Scales

WIOWIZ Technologies — Thu, 29 Jan 2026 14:37:36 +0000

In food processing, quality failures rarely happen all at once.
They start quietly — subtle texture changes, moisture imbalance, uneven heating — and by the time they’re visible, it’s often too late.

Yet many production lines still rely on manual visual inspection to decide when a batch is “good enough”.

That approach doesn’t scale anymore.

The Real Problem with Manual Quality Checks

Human inspection introduces unavoidable limitations:

Judgement varies between operators
Fatigue impacts consistency
Defects are detected after quality has already drifted
Continuous monitoring is practically impossible

As throughput increases and compliance tightens, this creates risk — not just inefficiency.

What Real-Time Quality Monitoring Changes

Real-time quality monitoring systems continuously observe production using:

Vision-based analysis (surface texture, color changes)
Environmental sensing (temperature, humidity)
On-device or edge AI inference for instant decisions

Instead of periodic checks, quality is evaluated continuously, allowing issues to be detected as they emerge, not after damage is done.

This enables:

Early intervention
Reduced waste and rework
Consistent product quality across shifts
Better traceability and audit readiness

Why Edge AI Matters Here

Sending all sensor and image data to the cloud isn’t practical for factory floors.

Edge-based systems:

Respond in milliseconds
Operate even with limited connectivity
Keep sensitive production data local
Scale across multiple lines without bandwidth bottlenecks

This makes real-time monitoring viable in high-throughput food processing environments.

From Monitoring to Prediction

Once continuous data is available, quality control evolves:

Patterns leading to defects become visible
Process drift can be predicted, not just detected
Operators shift from inspection to optimization

The system doesn’t just say something went wrong — it starts answering why and when it will happen again.

What This Post Doesn’t Cover (On Purpose)

This dev.to post skips:

System architecture diagrams
Sensor fusion strategies
AI model design and deployment details
Real production examples

Those are covered in detail in the canonical article.

👉 Read the full technical breakdown here:
Edge AI for Agriculture - Real-Time Quality Monitoring in Food Processing

Why This Matters Now

Food safety regulations are tightening
Waste reduction is a business imperative
Consistency across batches defines brand trust
Manual inspection can’t keep pace with modern production

Real-time quality monitoring is moving from innovation to infrastructure.

Canonical Source

This article is a summarized adaptation.
Original, full version:
Edge AI for Agriculture - Real-Time Quality Monitoring in Food Processing

VHE: Why Gate-Level Simulation Breaks at Scale (and What We Tried Instead)

WIOWIZ Technologies — Thu, 29 Jan 2026 12:55:09 +0000

Gate-level simulation is supposed to give confidence before tapeout.
In reality, once designs cross millions of gates, it becomes the bottleneck itself.

If you’ve tried verifying large designs with traditional open-source simulators, you’ve likely hit the same walls we did:

Simulations that run for days
Massive trace files
Memory exhaustion
Jobs that never finish

That experience forced us to ask a blunt question:

Is the problem really the design—or the way we simulate it?

That question led us to build VHE — Virtual Hardware Emulator.

Why Traditional Simulation Stops Scaling

CPU-based gate-level simulation evaluates gates sequentially. That works—until it doesn’t.

As designs grow:

Parallelism collapses
Runtime explodes
Debug cycles slow to a crawl

Commercial hardware emulators exist, but they come with six-figure licensing costs, making them inaccessible for startups, researchers, and open silicon teams.

There’s a clear gap:

Open tools scale well for small designs—and fall apart for large ones.

The Idea Behind VHE

Instead of trying to optimize CPU simulation further, we stepped back and asked:

What if gate-level simulation was mapped to massively parallel hardware instead?

VHE is a GPU-accelerated virtual hardware emulator that:

Converts synthesized netlists into a levelized structure
Evaluates large numbers of gates in parallel
Targets **million-gate designs **that CPU simulators struggle with

The goal wasn’t to replace commercial emulators—but to make large-scale verification practical in open flows.

Where Things Got Interesting

GPU acceleration sounds obvious—but it introduces its own constraints:

Memory layout matters
Scheduling matters
Netlist structure matters far more than expected

One design decision we made early on dramatically improved throughput—but also introduced a limitation we didn’t anticipate.

👉 That trade-off, and how it affected real NPU verification, is explained here: VHE — Virtual Hardware Emulator

Real Designs, Real Constraints

We tested VHE on a real multi-million-gate NPU design.

What changed wasn’t just runtime—it was feasibility:

Jobs that previously failed could complete
Results arrived within hours instead of days
Verification became iterative again

The exact numbers, scaling behavior, and limits are covered in the full article.

When VHE Actually Makes Sense

VHE is useful when:

Your design is too large for CPU simulation
FPGA prototyping is too slow or expensive
You need more fidelity than high-level models
Commercial emulators are not an option

It sits in the middle ground— between simulation and emulation.

Full Technical Deep Dive (Canonical)

This dev.to post intentionally skips:

Netlist parsing details
Levelization strategy
GPU scheduling model
Performance bottlenecks and limits

If you want the actual engineering details, benchmarks, and lessons learned, read the full article:

👉 VHE — Virtual Hardware Emulator

Takeaway

As designs scale, verification—not logic—becomes the real problem.
VHE explores one practical direction for making large-scale gate-level verification possible without enterprise tooling.

Chiplets, Made Practical: What Breaks When You Actually Try to Build One

WIOWIZ Technologies — Thu, 29 Jan 2026 12:30:55 +0000

Chiplets are everywhere in roadmaps—CPUs, accelerators, memory stacks, advanced packaging. Protocols like UCIe promise modular, interoperable multi-die systems.

But once you try to actually build a chiplet system, a different reality appears:

Chiplets are easy to talk about—and surprisingly hard to make practical.

At WIOWIZ, we set out to explore that gap by building a working, readable, SystemVerilog-based die-to-die (D2D) reference implementation — not production IP, but something engineers can study, simulate, and extend.

Why Chiplets Are Still Hard to Experiment With

Most chiplet resources fall into one of these buckets:

Academic implementations in unfamiliar languages
PHY-heavy designs that hide protocol behavior
Commercial IP that can’t be inspected or modified

What’s missing is a low-friction starting point — something that lets engineers see what really happens during link bring-up, negotiation, and data movement.

That’s the problem we focused on.

What We Built (And What We Didn’t)

We intentionally did not try to build a compliant or tapeout-ready UCIe IP.

Instead, we built:

A UCIe-inspired D2D link focused on behavior, not certification
A clean SystemVerilog RTL design, easy to read and modify
A minimal verification setup designed to expose—not hide—failures

This choice surfaced issues that rarely show up in high-level discussions.

One early simplification we made looked harmless—but it completely hid a class of integration bugs.

👉 That specific failure (and why it happened) is explained here:
Chiplets, Made Practical

Where Theory Meets Reality

The datapath itself wasn’t the hardest part.

The real challenges showed up in:

Link bring-up assumptions
Sideband coordination
Observability during partial failures

These are the kinds of problems you don’t see in protocol diagrams—but they dominate real chiplet integration work.

We deliberately left parts of the system “imperfect” so engineers can see where real-world designs tend to break first.

Why Verification Matters More Than Bandwidth

Most chiplet discussions focus on throughput numbers.

In practice, the harder question is:

How do you know both dies agree on what just happened?

Even a basic verification setup reveals surprising corner cases during early bring-up. That insight is one of the main motivations behind this reference design.

Why This Is Just the Beginning

This foundation enables practical experiments like:

CPU ↔ memory chiplets
CPU ↔ CPU communication
Multi-die meshes combining compute, memory, and accelerators

Each configuration exposes different system-level issues—none of which appear in single-die designs.

Full Engineering Details (Canonical)

This dev.to post intentionally skips:

Internal module breakdowns

Design trade-offs

What failed during early iterations

Why certain simplifications were reversed

If you want the actual engineering story, read the full article here:

👉 Chiplets, Made Practical

Takeaway

Chiplets won’t become mainstream through specs alone. They become practical when engineers can experiment, break things, and learn.

This work is about making that experimentation possible.

Parallel Region-Based Routing on OpenROAD: Scaling Beyond Multithreading

WIOWIZ Technologies — Thu, 29 Jan 2026 01:14:40 +0000

Detailed routing is one of the slowest stages in an ASIC physical design flow. Even with TritonRoute’s multithreading support, routing large designs still becomes a bottleneck as complexity grows.

At WIOWIZ, we explored a practical question:

Can OpenROAD detailed routing be parallelized at the process level—without modifying TritonRoute or OpenROAD itself?

The answer is yes, with careful region partitioning and orchestration.

Why Multithreading Isn’t Enough
TritonRoute uses multithreading inside a single routing process. While helpful, it still means:

One routing job
One shared routing state
Limited scalability on multi-core systems

True scalability requires multiple OpenROAD processes running in parallel, each routing a portion of the design.

Why Routing Is Hard to Parallelize
Routing is inherently global:

Nets span across regions
Power, ground, and clock networks are chip-wide
Routing complexity is unevenly distributed

Naive region splits fail because wall-time is dominated by the most complex region, eliminating parallel gains.

Our Approach: OpenROAD as a Black Box
Instead of modifying TritonRoute, we built an external orchestration flow:

Partition the design into routing regions
Generate region-specific DEF and guide data
Launch multiple OpenROAD processes in parallel
Route each region independently
Merge the routed outputs into a final DEF

Each OpenROAD process remains internally multithreaded, enabling process-level + thread-level parallelism.

The Key Insight: Balance by Complexity
Equal-area partitioning does not work. Routing difficulty does not correlate with geometry.

We achieved real speedups only after moving to complexity-aware region partitioning, ensuring that routing effort—not area—was balanced across regions.

Results
Using a RISC-V core in SkyWater 130nm:

Sequential routing: ~644 seconds
Parallel region-based routing: ~116 seconds
~5.6× speedup

All achieved without modifying OpenROAD or TritonRoute.

Why This Matters
This work demonstrates that:

OpenROAD can scale beyond its default execution model
Significant routing speedups are possible today
External orchestration can extend open-source EDA tools safely

Full Technical Details
This dev.to post is a concise summary.
For full implementation details, partitioning strategy, iterations, and limitations, read the original article:
Parallel Region-Based Routing on OpenROAD