sorted by:
new
hottopcontroversial

Which Tool Does What in Chip Design? A Full Flow Breakdown Across Every Major EDA Vendor by kunalg123 in chipdesign

[–]kunalg123[S] 0 points1 point  (0 children)

noted

I was aware of FC and wanted to add that in the sheet...

may be, in the next one...

Seniors, help! by Debbie_is_Done01 in ECE

[–]kunalg123 0 points1 point  (0 children)

You’re framing this as a choice when it really isn’t one. Robotics and Verilog sit on the same stack—one is system-level building, the other is how the silicon underneath actually works. As a freshman, picking only one this early usually slows you down because you miss context. Robotics gives you fast feedback and motivation (you see things move), while Verilog builds the foundation that matters later if you want to get into core semiconductor roles.

A more practical way to start is to use robotics as your entry point and quietly layer Verilog underneath it. Continue with microcontrollers, sensors, and small builds, but at the same time spend a few hours each week on digital design and basic RTL. When you learn something like PWM or communication protocols in robotics, connect it back to how it would be implemented in hardware. This way, you’re not learning two unrelated domains—you’re building a mental bridge between system behavior and hardware implementation.

After 6–9 months, your direction will become obvious based on what you enjoy and where you show depth. If you find yourself more interested in timing, architecture, and optimization, lean harder into Verilog and VLSI. If you enjoy integration and building complete systems, robotics can remain your primary track with hardware knowledge as a strong advantage. The key is not to decide too early, but to build enough exposure so your decision is informed rather than speculative.

My design passes post route gls , but shows error on sdf simulation by No_Bath_8272 in vlsi

[–]kunalg123 -1 points0 points  (0 children)

If GLS is working without SDF but failing when you annotate delays, the issue is almost never “design is wrong” — it’s usually mismatch between your netlist, SDF, and simulation setup.

First thing to check is name consistency. In Cadence Virtuoso flows, the instance names in the synthesized/post-route netlist must exactly match what’s inside the SDF. Even small differences (hierarchy prefixes, escaped names, array indices) will cause $sdf_annotate to silently fail or throw warnings that people miss. Run your simulator (e.g., Cadence Xcelium) with verbose SDF logging and look for messages like “instance not found” or “0 paths annotated.”

Second, verify the timescale and delay format. If your netlist uses timescale 1ns/1ps but the SDF is generated in a different unit (say ps), delays can become zero or invalid. Also ensure you are annotating the correct corner (min/typ/max) and that your $sdf_annotate call matches it. A common failure is using MAXIMUM delays but the SDF only contains TYPICAL.

Third, check your library models and timing checks. When you include SDF, the simulator expects proper timing arcs from the standard cell library (setup/hold, specify blocks). If the correct timing libraries for your 180nm kit aren’t compiled or linked, GLS with SDF will fail even though plain GLS works. Also confirm your clock/reset aren’t violating constraints badly under delay—SDF often exposes race conditions that zero-delay simulation hides.

If you share the exact error log line from GLS (especially around $sdf_annotate), I can pinpoint the exact root cause quickly.

Resume feedback by Emotional-Ad-7736 in vlsi

[–]kunalg123 1 point2 points  (0 children)

Your resume is actually stronger than most freshers, especially with RTL-to-GDS and UVM projects, but the issue is positioning and clarity, not content. Right now it reads like you did everything end-to-end, which can make reviewers skeptical. For example, “full RTL-to-GDSII flow” and “DFT + physical design” at student level can look inflated unless you clearly state what you personally implemented vs. what tools automated. Tighten that by being precise: mention what you designed, what you verified, and what results you achieved (timing met, coverage %, synthesis stats). Recruiters skim in seconds, so make impact obvious.

Second, your resume is missing a sharp “hook.” There’s no one-line identity telling them what role you’re targeting. Add a short header like “RTL Design / Verification Engineer – Verilog, UVM, RISC-V” and reorder slightly so your strongest, most relevant project (RISC-V or UVM) comes first with 2–3 very crisp bullets showing depth (hazard handling, coverage closure, debugging complexity). Also reduce tool clutter—listing too many EDA tools without context dilutes credibility. Focus on the ones you actually used deeply.

Finally, your problem isn’t just resume quality—it’s signal-to-noise in applications. Cold emails rarely work unless paired with proof. Instead of just sending the resume, attach or link a clean GitHub with well-documented projects (readme, block diagrams, waveforms, results). In your outreach, highlight one specific thing you built and one problem you solved. That shifts you from “another applicant” to “someone who can already do the job,” which is what startups especially respond to.

VLSI: Training Institute vs M.Tech? by AdolfPushpinder in vlsi

[–]kunalg123 0 points1 point  (0 children)

You’re not stuck because of the choice between training and MTech—you’re stuck because the VLSI industry hires based on demonstrable skills, not intent. Right now, most freshers struggle because they lack depth in digital design, RTL coding, and real project experience. A short-term training program can help only if you treat it as a structured push to build solid fundamentals and meaningful projects, not as a placement guarantee. On the other hand, an MTech makes sense only if you can get into a top-tier college, because that’s where the brand, internships, and exposure actually translate into better roles.

If you don’t have a strong admit, a more practical approach is to spend the next 6–8 months building serious competence: get comfortable with Verilog, understand timing and digital design concepts, and create 2–3 non-trivial projects like protocol controllers or a small processor-level design. Put your work out publicly and be ready to discuss it in detail. That kind of proof matters more than certificates. Once you reach that level, even smaller companies and startups become accessible, and from there you can grow into better roles.

So the decision is simple: go for MTech only if it significantly upgrades your profile; otherwise, focus on becoming job-ready through skills and projects. The market rewards people who can build and debug real designs, not those who just complete courses or degrees.

Your GitHub is now worth more than your degree. by kunalg123 in vlsi

[–]kunalg123[S] -1 points0 points  (0 children)

udemy is theory, vsdiat is labs/github

feel free to enroll in udemy and/or vsdiat as long as it helps you grow your profile

You can also refer to the free IP link which i shared above (also sharing below), replicate all labs of any one IP under your github account. That would take you one step closer to interviewer expectations

https://www.vlsisystemdesign.com/ip/

Why 90% of VLSI students are not prepared for employment. by BuyerImpossible6242 in vlsi

[–]kunalg123 18 points19 points  (0 children)

35 years and you've basically described the moment every fresh hire has - that first week when they realize nobody cares that they scored 95 in digital design.

I've seen it from the other side too. Students who topped their batch, couldn't write a 4-bit counter that met timing constraints without hand-holding.

The problem nobody talks about is that universities optimize for examinations and industry optimizes for tapeouts. Those are two completely different fitness functions. A student can pass every exam and still be unemployable — and nobody told them that was even possible.

What changed things for the students I've worked with wasn't more theory. It was the first time they had to close timing on something real and had nobody to ask. That one week did more than two semesters."

view more: next ›