Welcome to RTL Forge. You're here because you want to build real hardware — not toy examples.

Here's how this community is structured:

📚 Course — Work through the curriculum at your own pace. Start with Verilog HDL Foundations, then move into Advanced RTL, Tauri Invoke integration, and finally the Capstone waveform viewer app. Each chapter builds directly on the last.

💬 Mentor Chat — Drop questions anytime. HDL synthesis issues, Rust borrow checker confusion, timing closure problems — bring them all. Response time target: <12 hours on weekdays.

📋 Weekly Briefs (you're here) — Every week I'll post a brief covering one deep topic: a specific RTL pattern, a Tauri pitfall, a Rust idiom worth knowing. Treat these as supplemental material alongside the course.

🔁 What to do first:

1. Introduce yourself in the Mentor Chat — your background, what FPGA or toolchain you're targeting, and what you want to ship.

2. Open Chapter 1, Lesson 1 — don't skip the logic refresher even if you've seen it before. The framing matters for what comes later.

3. Come back here weekly. Every brief is standalone but rewards sequential reading.

Let's build something real. — RTL Forge

Most FPGA engineers who want to build desktop tooling default to Python + Tk, or reach for Electron because "everyone uses it." Both are reasonable choices until they aren't.

Here's the case for Tauri with a Rust backend — specifically for HDL tooling like waveform viewers, lint dashboards, and synthesis report parsers.

---

The problem with Electron for HDL tools

HDL tooling is memory-intensive. A mid-size simulation run produces VCD files in the hundreds of MB range. Parsing that in a Node.js main process — even with worker threads — means you're fighting the GC every time you scroll the waveform. Electron ships with Chromium + V8 + Node bundled per app. You're starting at ~200 MB resident memory before you've loaded a single signal.

Tauri's renderer is the system WebView. The backend is a compiled Rust binary. Total baseline memory for a Tauri app: ~5–15 MB. For tooling that runs alongside Vivado or Quartus, that matters.

---

How Tauri invoke actually works

When your frontend calls invoke("parse_vcd", { path: "/path/to/dump.vcd" }), here's the exact call chain:

1. The frontend serializes the args to JSON and posts a message to the WebView's IPC channel.

2. Tauri's runtime deserializes the JSON into the Rust types you declared in your command signature using serde.

3. Your #[tauri::command] function executes — synchronously or async, your choice.

4. The return value is serialized back to JSON and resolved to the frontend Promise.

The key insight: there is no JS runtime on the backend. The Rust binary is compiled. Your VCD parser, your signal indexing logic, your grep over a netlist — all of it runs at native speed with zero GC pauses.

#[tauri::command]
async fn parse_vcd(path: String, state: tauri::State<'_, AppState>) -> Result<VcdSummary, String> {
    let file = tokio::fs::read_to_string(&path).await.map_err(|e| e.to_string())?;
    let summary = vcd::parse(&file).map_err(|e| e.to_string())?;
    state.cache.lock().await.insert(path, summary.clone());
    Ok(summary)
}

Error handling: return Result<T, String>. Tauri maps Err to a rejected promise on the JS side. Your frontend try/catch around invoke() just works.

---

Real-time events: pushing simulation progress to the UI

invoke is request-response. For long operations — parsing a 500 MB VCD, running a linting pass — you want the backend to push progress updates to the frontend without blocking.

Use tauri::Emitter:

#[tauri::command]
async fn parse_vcd_streaming(path: String, window: tauri::Window) -> Result<(), String> {
    let signals = count_signals(&path)?;
    for (i, signal) in enumerate_signals(&path)?.iter().enumerate() {
        process_signal(signal);
        if i % 100 == 0 {
            window.emit("parse_progress", (i as f32 / signals as f32) * 100.0).ok();
        }
    }
    window.emit("parse_complete", ()).ok();
    Ok(())
}

Frontend:

import { listen } from "@tauri-apps/api/event";

await listen<number>("parse_progress", (e) => {
  setProgress(e.payload);
});
await invoke("parse_vcd_streaming", { path });

This pattern — invoke to start, events to stream, promise resolve to finish — covers 90% of the heavy operations you'd build in HDL tooling.

---

Where this gets interesting for Verilog work

The Tauri invoke bridge becomes your language boundary. Your synthesis constraint parser, your timing report extractor, your netlist differ — write them in Rust, expose them as commands, keep the UI in React. You get type safety at both ends (TypeScript + Rust), a tiny binary, and a UI that stays responsive no matter what the backend is doing.

If you're building any kind of desktop tooling on top of your HDL workflow, this is the architecture worth learning. Happy to go deeper on any specific piece in the comments.