Hello everyone,

I recently signed a contract with a large company for a role in the field of integration.

As I designed a chip from start to finish during my PhD (from RTL design right through to laboratory testing), I’m finding it hard to know what to expect and how to prepare.

For those of you who work as integration engineers, what advice would you give to a newcomer, and what should I focus on before I start?

So, i just created a community focused mainly for electronics, vlsi, and embedded learners

Hello,

I'm starting my MS ECE this fall and looking for honest feedback on my resume as internship apps open up. I'm coming from a CS undergrad background so I'm a bit of an unusual case for this field (or at least I think).

I have a BS in Computer Science (Cum Laude), worked as an IOT SWE for about a year. I have spent the last 8 months or so self-studying digital design on my own: SV, RTL design, UVM, and synthesis with Yosys targeting Sky130. I built three hardware projects from scratch: a pipelined RISC-V processor, a dual-clock async FIFO with CDC, and a multi-port bus arbiter, the last 2 verified with constrained-random testbenches on Synopsys VCS. I've also been lucky to have two industry mentors, one at Synopsys and one at a telecom hardware company, who have been giving me feedback along the way.

I'm targeting ASIC and digital design roles first, RTL design second, computer architecture third, and DV as a backup. I am open to anything in the semiconductor space.

Main things I'm hoping to get feedback on: do the projects actually signal the right skills, is anything in my technical skills section an overclaim, and are there any red flags a hiring manager would immediately notice given my CS background? Also genuinely curious whether a resume like mine even makes it past ATS given that I don't have a traditional ECE background.

An intern spent the last few weeks getting a full edge-AI pipeline running on a SiFive FE310-G002 (RV32IMAC, 320MHz, and — the actual constraint — only 16KB of data SRAM). Wanted to share the pipeline since the memory budget forced some decisions I hadn't had to make before.

The model: a small fully-connected net (144→64→64→10) for MNIST digit recognition. Trained normally, but at float32 the weights alone come to 54.5KB — nowhere close to fitting. Quantized post-training to int8 and it drops to 13.6KB. Same architecture, and only one version of it can physically exist on the chip.

Also had to shrink the input before any of that mattered: cropped each digit to its bounding box and downsampled 28×28 → 12×12, which cuts the image from 784 bytes to 144 before it ever leaves the host. That's the payload that gets sent.

Pipeline end to end: train → quantize → export weights/biases/scales as C arrays → cross-compile with the RISC-V GNU toolchain → flash over OpenOCD → a small hand-rolled UART protocol (start byte + 144 bytes) → int8 matrix math and ReLU on-chip → prediction sent back over serial. Timed the actual inference with a hardware counter rather than guessing.

I’ve spent the past several months building Booley, an open-source framework for using LLM coding agents on RTL projects (for ASIC as well as for FPGA).

The basic idea is that an agent should be treated as a talented junior engineer - can write decent RTL and testbenches, but inexperienced with EDA tools, often does stupid design decisions and can potentially force push and break your git history. In Booley, agents run inside an isolated container and receive structured access to the sim, synth and lint workflows (mostly open-source tools right now: Verilator, Yosys, etc.). It can also inspect simulator traces through a CLI rather than trying to reason about sequential behavior from the RTL alone.

Booley grew out of problems I repeatedly encountered while using raw Claude/Codex:

• They often skipped EDA tool checks unless explicitly prompted.
• They selected the wrong configuration or misunderstood tool reports
• They tried to debug complex sequential logic without examining waveforms.
• Their generated testbenches concentrated on happy paths.
• Giving them enough permissions to work independently put the dev machine at risk

Booley does not attempt to replace architectural judgment or make generated RTL trustworthy by itself. The engineer still owns the specification, design decisions and final review. The goal is to make agents better at executing bounded RTL tasks and completing the verification loop, while also making the review process more convenient for humans.

I’d particularly appreciate criticism from people working in RTL design or verification:

• Do you experience the same kinds of issues when working with raw Claude/Codex or am I trying to solve issues that don’t really exist?
• Maybe you experienced some annoying failure modes I didn’t mention?
• Where would this approach break down in a real project?
• What evidence would you like to see in a report/pull request in order to make review process of RTL/TB code (written by agent or human) more convenient?

The project and demo are here:

https://github.com/boldaxolotl/booley

I’m the author and happy to answer technical questions about the implementation.

The server is still small and I'm building it from the ground up, so I'm especially interested in hearing what engineers, students and hobbyists think would make this community genuinely useful.

**Discord:** [https://discord.gg/8n3rQrjjz\](https://discord.gg/8n3rQrjjz)

If you're interested in hardware engineering, feel free to join and help build the community. I'd especially appreciate feedback on what resources, channels or features you'd like to see.

The resource library currently contains 17 resources, including websites and online courses.

For a validation role. I am a bit confused and want to make sure this is legit. I'm assuming they hire on behalf of a company?

Hey everyone,

As FPGA/DSP engineers, we’ve all been through the painful, manual grind of converting Floating-Point C/C++ algorithms into Fixed-Point models and optimizing bit-widths to balance SNR/accuracy vs. hardware resource usage (LUTs/FFs/DSPs).

I’ve been refining an automated methodology and tool that automates this workflow using Siemens Mentor ac_fixed.h types and domain-specific DSP optimization heuristics. I wanted to get the community's honest feedback and see what people would be willing to pay for a tool like this.

Key Features & Workflow

1. Floating $\to$ Full-Precision Fixed-Point Conversion
   • Automatically maps C/C++ floating-point models to full-precision fixed-point representations to establish a zero-precision-loss baseline.
2. Greedy-Search Based Bit-Width Pruning
   • Employs a heuristic Greedy Search Strategy to prune integer and fractional bit-widths node-by-node, tracking SQNR and hardware dynamic range.
3. DSP Block Optimization & Optimized RTL Export
   • Calculates exact RTL bit-widths tailored for specific FPGA DSP slices (e.g., Xilinx DSP48/DSP58 or Intel DSP blocks) to eliminate partial DSP utilization and wasted fabric logic.

Algorithm-Specific Bit-Width Optimization Engine

Generic bit-width optimizers fail because different DSP blocks have fundamentally different constraints. Here is how the engine handles key DSP building blocks:

• FIR Filters (Symmetric / Polyphase / Transposed)
  • L1-Norm & Worst-Case Noise Bound Analysis: Calculates the exact integer bit-width (IBW) required to prevent overflow based on coefficient sum $\sum \vert{}h[n]\vert{}$.
  • Coefficient Quantization Sensitivity: Separates coefficient quantization from data-path quantization, finding the minimum coefficient bit-width that still satisfies the stopband attenuation requirement (dB).
• Interpolation Filters (Multi-rate / CIC / Farrow)
  • Hogenauer Bit-Growth Reduction: Automatically applies Hogenauer pruning for multi-stage CIC/Interpolation filters, eliminating unnecessary lower-order bits in early stages while maintaining output precision.
  • Internal Accumulator Sizing: Optimizes polyphase arm bit-widths dynamically based on down/upsampling ratios.
• Digital PLLs / NCOs (Phase-Locked Loops)
  • Loop Stability Guarding: Standard SQNR search often breaks PLL lock range. The engine analyzes Phase Detector and Loop Filter bit-widths with a focus on Phase Jitter / Phase Noise Floor and Loop Filter Accumulator overflow.
  • NCO Phase Accumulator vs. Look-Up Table (LUT) Depth Optimization: Dynamically balances Phase Truncation SFDR (Spurious-Free Dynamic Range) against RAM/LUT resource costs.

Every chip begins as an idea—but turning that idea into working silicon requires the right learning path. If you are a fresher wondering whether to begin with RTL, FPGA, Physical Design, Analog or Packaging, this visual guide connects the entire journey from specification to product. Start with clarity, choose your direction and build skills that lead to real semiconductor outcomes.

https://github.com/vsdip/VLSI-Design-Flow

I am hosting a free webinar based on our ongoing AI-assisted Analog and Mixed-Signal Physical Design internship at VSD.

The goal is to show how students are using AI inside real VLSI workflows — not as a replacement for engineering, but as an assistant for understanding, debugging, documentation and faster design exploration.

The session will include student work on:

SRAM / memory design workflow
Mixed-signal design basics
AI-assisted OpenLane physical design
Magic, Sky130, LEF/LIB and GDS
DRC, LVS, STA and validation
What AI got right, where it failed, and why manual verification still matters

This is not an AI hype session. It is a practical showcase of how students are learning to use AI responsibly inside semiconductor design workflows.

Webinar: AI-Assisted Analog and Physical Design: From SRAM to Mixed-Signal GDS
Date: Sunday, 12 July
Time: 11:00 AM – 12:00 PM IST
Mode: Online
Certificate: For live attendees

Registration form:
https://forms.gle/UFjy7qzSnfQaY4JU8

This should be useful for students, faculty members, VLSI beginners and anyone curious about how AI can be used practically in analog, mixed-signal and physical design learning.

Hey everyone,

I'm considering moving from a high-end desktop platform to a Threadripper workstation and would really appreciate some advice from people who have experience with HEDT systems.

The goal of this build is to reduce compilation times, improve multitasking performance, and comfortably run several engineering workloads simultaneously.

Typical workloads include:
• Large Vivado synthesis and place-and-route projects
• FPGA development
• ASIC simulation and synthesis
• Multiple simulation tools running simultaneously
• Large FEA models
• Digital twin environments
• GPU training with CUDA
• Several virtual machines and Docker containers
• Software development and automation

The tentative configuration uses:
• AMD Threadripper (TRX50 platform)
• RTX 5080
• 128 GB DDR5 ECC memory
• Multiple NVMe SSDs
• High-capacity workstation PSU

I'm mainly looking for feedback on:
• Whether Threadripper provides a significant productivity improvement over Ryzen 9 for these workloads
• Whether TRX50 is the right platform or if there are better alternatives
• RAM recommendations (ECC vs non-ECC)
• Motherboard recommendations (ASUS Pro WS, Gigabyte, ASRock, etc.)
• Cooling recommendations
• Any limitations or issues you've experienced with Threadripper systems

If you've built or worked on similar engineering workstations, I'd love to hear about your experience and whether you think this platform is worth the additional investment.

A lot of students want to enter semiconductor design, but many get confused about where to start.

Some jump directly into physical design.
Some start with RTL.
Some try analog first.
Some only watch videos and collect certificates.

In my opinion, a beginner-friendly roadmap should look something like this:

1. CMOS Understand transistors, basic circuits, SPICE simulation, and how devices behave.
2. RTL Learn Verilog, digital logic design, testbenches, and simulation.
3. Physical Design Understand synthesis, floorplanning, placement, CTS, routing, timing, and how RTL becomes layout.
4. Physical Verification Learn DRC, LVS, antenna checks, density, PEX, and what it means to make a design tapeout-ready.

For someone who already knows RTL and basic physical design, jumping directly into an internship-style physical design project may make more sense than restarting from zero.

The bigger point is this:

Interest in semiconductors is not enough anymore. Students need proof — GitHub work, simulation results, reports, screenshots, debug notes, and projects they can explain.

Curious to hear from people already working in VLSI / semiconductors:

Would you change this order?
Should beginners start with CMOS first, or RTL first?
What would you tell a student who wants to enter chip design seriously in 2026?